Pythonについて（アンチ専用）

**デフォルトの名無しさん** · 2008/02/21(木) 10:24:06

Pythonが嫌いな人のためのスレッドです。

■関連スレ
Rubyについて（アンチ専用） Part002
http://pc11.2ch.net/test/read.cgi/tech/1200210768/

**デフォルトの名無しさん** · 2009/06/10(水) 15:05:56

日本人はすぐ個人攻撃に走る

**デフォルトの名無しさん** · 2009/06/10(水) 16:12:54

論理的に反論できないんですねわかります

**デフォルトの名無しさん** · 2009/06/10(水) 17:01:21

まぁ、論理的に反論できないやつが人格攻撃なんてよくあることだ罠

**デフォルトの名無しさん** · 2009/06/10(水) 17:04:49

偉そうにはとても見えないけど、仮に偉そうだったとして、
実際この子よりは偉いだろうから仕方ないと思う。
相対的にこの子と対等かそれ以下になるのは、常人には逆に難しそう。

**デフォルトの名無しさん** · 2009/06/10(水) 17:10:07

>>511
> どうせ要素のすべてが文字列である場合じゃないとjoinできないんだから、listのメソッドだったとしても別におかしくはない。

だから、どうしてstringのjoinしか見ないんだって何度もツッコミ入れられてるだろ。
joinがstringに定義されているから、引数はstringのiterableを取り、結果として連結されたstringを返す。
同様に、bytearrayのjoinは引数としてbytearrayのiterableを取り、結果として連結されたbytearrayを返す。
全部listのjoinが何とかするよりも、連結されるクラスが定義するpython式のほうがずっと自然だ。

**デフォルトの名無しさん** · 2009/06/10(水) 17:11:18

>>512
> そうなったらjoinの引数として渡してやるだけでいいじゃん。
> str.join(list) が list.join(str) となるだけ。

そのlistはstrのこともbytearrayのことも何でも知ってなきゃならないわけだ。
ユーザ定義のクラスを連結したい時にはどうするの？

**デフォルトの名無しさん** · 2009/06/10(水) 17:26:40

その場合はlist.join内部を+とかconcatとかで実装しておいて
その実装に使われたメソッドを各クラスで定義するのが自然ではなかろうか
一手間余計にかかるが

**デフォルトの名無しさん** · 2009/06/10(水) 17:28:47

　　　　　　　_________
　　　　　／　　　　＼
　　　　／　　 ⌒　　⌒＼
　　／　　（ ⌒）　（⌒）＼
　　 i 　::::::⌒ （__人__） ⌒:: i 　　
　　　ヽ、　　　 `ー '　　／
　　　　/　　　　　┌─┐
　　　　i　　丶　ヽ{ .茶 }ヽ
　　　　ｒ　　ヽ、__)一(_丿
　　　　ヽ、___　　　ヽ　ヽ　
　　　　と_＿＿_＿ノ＿ノ

**デフォルトの名無しさん** · 2009/06/10(水) 17:33:39

>>520
つまり連結演算子/連結関数を決め打ちするということね。
そんなことするぐらいならPythonのように連結されるクラスが提供するほうが
柔軟性があって、かつ、確実だと思うが。

**デフォルトの名無しさん** · 2009/06/10(水) 17:35:48

>>520
> その場合はlist.join内部を+とかconcatとかで実装しておいて

それこそjoinのありがたみが台無しじゃん。
1つ1つ連結していたら計算量が大きくなるぞ。

**デフォルトの名無しさん** · 2009/06/10(水) 17:47:46

＿＿
　　　￣￣￣二二ニ＝-
'''''"""￣￣
　　　　　　　　　　　-=ﾆﾆﾆﾆ=-

　　　　　　　　　　　　　　　　　　　　　　　　　／⌒ヽ　　　_,,-''"
　　　　　　　　　　　　　　　　　　　　　　 _　 ,（＾ω＾）　,-''";　　;,
　　　　　　　　　　　　　　　　　　　　　 /　,_O_,,-''"';　',　:'　;;　;,'
　　　　　　　　　　　　　　　　　　　　　(.ﾞｰ'''",　;,;　'　;　;;　　':　　,'
　　　　　　　　　　　　　　　　　　_,,-','",　;:　'　;　:,　':　,:　　　　:'　　┼ヽ　 -|r‐､.　ﾚ　|
　　　　　　　　　　　　　　　_,,-','",　;:　'　;　:,　':　,:　　　　:'　　　　　ｄ⌒)　./|　_ﾉ　 __ﾉ

**デフォルトの名無しさん** · 2009/06/10(水) 19:56:04

Rubyの方が「(Matzの)気持ちよさ」のために汎用性や効率を
犠牲にしている所が多いので、RubyとPythonの仕様の違いで
「Pythonが間違っている！」と指摘するRuby厨はたいてい
視野が狭い。

**デフォルトの名無しさん** · 2009/06/10(水) 21:15:35

>>525
おまえこそ視野を広く持てよ。

join()がArrayやListのメソッドである言語：
Ruby, JavaScript, Smalltalk(GNU), Perl(List用の関数に分類される)

join()が文字列のメソッドである言語：
Python, C#, PHP(文字列用の関数に分類される)

まあオブジェクト指向的に、"連結せよ" というメッセージをどこに送信するかを考えると、そりゃArrayやListに送るわな。
Pythonの場合はオブジェクト指向として考えたわけじゃなくて、シーケンスを引数にしたいという都合からそうなっているだけ。
joinを関数のようにとらえているとそれでもいいけど、オブジェクト指向的に考えると不自然ってだけ。
C#も、joinはインスタンスメソッドではなくスタティックメソッドだから、まさに関数的な考え方。
ttp://www.atmarkit.co.jp/fdotnet/dotnettips/366join/join.html

joinは、オブジェクト指向が強い言語では当然のようにArrayやListのメソッドだけど、関数が主体の言語では文字列のメソッドになることがある。
少なくとも、joinが文字列のメソッドである*べき*なんてのはただのねつ造だし、言語でいえば実は少数派。

まあいいじゃん、joinが文字列のメソッドでも。PHPと同じだと思えば。
525の視野が広くなることを願いながら、この話題はここで終了。

**デフォルトの名無しさん** · 2009/06/10(水) 22:00:10

>>526が言語とライブラリの区別もつかない土方な件

**デフォルトの名無しさん** · 2009/06/10(水) 22:04:40

> まあオブジェクト指向的に、"連結せよ" というメッセージをどこに送信するかを考えると、そりゃArrayやListに送るわな。

ぷ
オブジェクト指向的には"連結せよ"というメッセージは連結子になるオブジェクト(string)に送るのが自然だろ。
ArrayやListに送るという発想はSmalltalkの古いCollectionの設計に縛られているだけ。

**デフォルトの名無しさん** · 2009/06/10(水) 22:08:45

>>526
オブジェクト指向的かどうかではなくて、型に対する態度の問題だと思うぞ。
型を強く意識する言語では、文字列以外も入るリストに要素を文字列として
連結するなんてメソッドを追加するのはあり得ない。

C#のstaticmethod の join は、 Python にも string モジュールに join
という関数がある。文字列に関連したメソッドなんだから str の
インスタンスメソッドにした方が便利だから、インスタンスメソッドに
なっただけ。

**デフォルトの名無しさん** · 2009/06/10(水) 22:13:24

「オブジェクト指向的に自然」って、自分で思いこんでるのが
すべての人にとっても自然だと考えるのはなんでなんだろうね。

少なくとも文字列の連結処理を効率的に行うには文字列の
実装を知らないといけなくて、Arrayが文字列の内部実装を
直接弄って効率的な連結をするのは気持ち悪いな。

**デフォルトの名無しさん** · 2009/06/11(木) 00:45:49

理想の世界で生きていきたくても、
蛇にそそのかされてリンゴを食べたからな。
現実と向き合わないとならないのだよ。

**デフォルトの名無しさん** · 2009/06/11(木) 01:13:38

　　　　　　＿＿＿＿＿_.＿＿＿＿＿_.__
　　　　, '"――――‐, '"――――― ヽ`i1
　　　./ ∧＿∧　　 //'~￣￣|.|.|￣￣~|.||::||
　　 .i　（・∀・ .）　　i !　　_,.＿|.|.| 　. 　 |.l|::||
　[;].!_っ⌒'と　_0[;],l | 　f　_..┘|:.￣￣~ .|| ||.＿＿＿＿＿＿＿＿_,
　 ~l!=;:,...二二....,:;=iﾖ.'ｰ''"~ . __ !　　　 __.|| ||i リンゴジュース　￣i1
　　li..,._. ￣｡￣. _.,..!.|　　 ........~ﾉ..............~ || !|i,,＿__,,＿__,,＿__,,＿_,,!|
　　il＿｀}≡≡{´＿E|..::' /⌒ヽ'ヽ＿＿___/l|!=ｲ二/＿/ ⌒ヽヽ(ﾆ(]
.　 {=i:::::::[二]:::::::i=i::｣　 |i.（*）.i;;;;|i□□ー‐! ::::::::::|;;;;;;|ii.（*） i;;;|二l]
　　￣￣ゞ三ノ￣￣￣ゞ＿ノ￣　　ゞゞ三ノ　　￣ゞゞ＿ノ~　　　　≡3

**デフォルトの名無しさん** · 2009/06/11(木) 09:03:24

>>511
>どうせ要素のすべてが文字列である場合じゃないとjoinできないんだから、listのメソッドだったとしても別におかしくはない。

要素のすべてが文字列である場合じゃないとjoinできないんだから
str/unicode/byteのメソッドなのでは？

**494=502** · 2009/06/11(木) 13:03:13

>>513
俺は >>498 よりも先に >>494 を書いて、ちゃんと最後まで読んだ上で
RTFM と言ったんだが?

**デフォルトの名無しさん** · 2009/06/11(木) 13:22:39

>>502
違う、全然違う。
str.join は、自動的に unicode へ格上げするような仕様になっている
だけで、実装は + (__add__) よりも効率的なものを使っている。
結果がたまたま等しいだけであって、sep.join([u'a', u'b']) と
u'a' + sep + u'b' は違う意味だ。

「strのjoinだからstr」というのは、逆に言えば「str以外のjoin」は違う動作を
するという意味でもある。

In [3]: k = bytearray('k')
In [4]: k.join([u'a', u'b'])
TypeError: can only join an iterable of bytes (item 0 has type 'unicode')

**535** · 2009/06/11(木) 13:23:36

>>502 じゃなくて >>511 だった

**デフォルトの名無しさん** · 2009/06/11(木) 14:57:21

reduce(lambda x,y: str(x) + ',' + str(y), [1,2,3])
これ reduce 使う前提でもっと効率良く書けますか？

**デフォルトの名無しさん** · 2009/06/11(木) 14:58:21

>>> reduce(lambda x,y: x + ',' + str(y), [1,2,3], '')
',1,2,3'
>>> reduce(lambda x,y: x + ',' + y, [1,2,3], '')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<stdin>", line 1, in <lambda>
TypeError: cannot concatenate 'str' and 'int' objects

ダメぽ orz

**デフォルトの名無しさん** · 2009/06/11(木) 15:00:15

','.join(map(str,[1,2,3]))

**デフォルトの名無しさん** · 2009/06/11(木) 15:34:13

>>539
＞reduce使う前提で

まあその前提条件はどうよという点はさておく

**デフォルトの名無しさん** · 2009/06/11(木) 16:06:04

仮にreduceでどんだけがんばってもjoinよりは速くならないだろう

**デフォルトの名無しさん** · 2009/06/11(木) 16:08:15

reduce(lambda x, y: '%s,%s' % (x, y), [1,2,3])
スマートさを求めるならこのあたりが限界かな

**デフォルトの名無しさん** · 2009/06/11(木) 21:48:41

生成される一時オブジェクトの数のオーダが違うから無理だと思う

**デフォルトの名無しさん** · 2009/06/12(金) 08:08:33

joinは？

**デフォルトの名無しさん** · 2009/06/12(金) 08:17:15

joinを使うと一時オブジェクトなしで計算量O(N)。
reduceを使うと一時オブジェクトがO(N)必要で計算量O(N^2)。
どっちが良いかは明白だな。

**デフォルトの名無しさん** · 2009/06/12(金) 10:16:59

Ruby の join って Enumerable のメソッドでは無くてリストのメソッドなんだな。
Pythonよりよっぽど気持ち悪い。

**デフォルトの名無しさん** · 2009/06/15(月) 06:27:55

123

**デフォルトの名無しさん** · 2009/06/17(水) 12:12:18

daa

**デフォルトの名無しさん** · 2009/06/21(日) 06:52:49

なんかすげーあちこちに飛び火したな、joinネタ
ttp://d.hatena.ne.jp/methane/20090615/1245025996
ttp://blog.livedoor.jp/dankogai/archives/51226075.html
ttp://d.hatena.ne.jp/methane/20090621/1245532793

**デフォルトの名無しさん** · 2009/06/21(日) 12:29:31

>>549
二行目
だんこがい
ってばかだな

class List(list):
def join(self, j = ''):
return j.join(map(lambda x: '%s' % x, self))

**デフォルトの名無しさん** · 2009/06/21(日) 12:38:06

return j.join(map(repr, self))

**デフォルトの名無しさん** · 2009/06/21(日) 13:53:50

>>550
>>> t = 'foo',
>>> t
('foo',)
>>> "%s" % t
'foo'
>>> str(t)
"('foo',)"
3行目のmethaneの方がスマート。
でも、 sep.join(x if isinstance(x, basestring) else str(x) for x in iterable) と
一行で書いた方が多分速いな。

>>551
repr と str は違う

**デフォルトの名無しさん** · 2009/07/03(金) 05:29:13

　　　 ┌─┐
　　　 │●│
　　　 └─┤
　　　_ 　 ∩
　　( ﾟ∀ﾟ)彡
┌─┬⊂彡
│●│　おっぱい！おっぱい！
└─┘　　　　　おっぱい！おっぱい！

**デフォルトの名無しさん** · 2009/07/22(水) 14:57:08

test

**デフォルトの名無しさん** · 2009/07/24(金) 19:32:27

pythonをはじめて使った時に ''.join()みたいな書き方は
あり得ないと思ったけど、慣れてしまえば使いやすいね。

**デフォルトの名無しさん** · 2009/07/24(金) 19:37:07

　　　 ┌─┐
　　　 │●│
　　　 └─┤
　　　_ 　 ∩
　　( ﾟ∀ﾟ)彡
┌─┬⊂彡
│●│　おっぱい！おっぱい！
└─┘　　　　　おっぱい！おっぱい！

**デフォルトの名無しさん** · 2009/07/25(土) 03:36:26

JavaScriptもjoin使うの知って
まぁそうゆうもんかと思った。

**デフォルトの名無しさん** · 2009/07/25(土) 17:15:15

キャメルケースでも、アンダースコア区切りでもないのが、個人的に違和感がある。

**デフォルトの名無しさん** · 2009/10/03(土) 22:56:53

アンチ少ないお

**デフォルトの名無しさん** · 2009/10/03(土) 23:01:16

　　　 ┌─┐
　　　 │●│
　　　 └─┤
　　　_ 　 ∩
　　( ﾟ∀ﾟ)彡
┌─┬⊂彡
│●│　おっぱい！おっぱい！
└─┘　　　　　おっぱい！おっぱい！

**TiZCCqJpUPBkUeQHx** · 2009/10/23(金) 03:16:56

Black community in a town of 96% whites. ,

**デフォルトの名無しさん** · 2009/11/03(火) 20:47:51

インデント記法は慣れれば気にならないし、
xx.lenghがなくてlen(xx)に統一されてるのも
個人的には嫌いだけど一理あるとは認めざる得ない。

でもスライスのx[n:m]の範囲指定は気持ち悪い。
なんか合理的な理由でもあるの？

**デフォルトの名無しさん** · 2009/11/03(火) 20:52:51

他にどんな方法があるの？

**デフォルトの名無しさん** · 2009/11/03(火) 21:37:23

>>562
日本語の勉強してから出直せ

**デフォルトの名無しさん** · 2009/11/03(火) 21:38:46

>>563
[n:m] が n～(m-1) が気持ち悪いっていう意味だろうと E.S.P.

漏れは合理的だと思うけどね

**デフォルトの名無しさん** · 2009/11/03(火) 21:47:04

>>565
ああそういう意味か
漏れも>>562が何言ってるのか判らんかった

例えばx文字目からy文字（文字数）取り出すとき
s[x:x+y-1]
とするよりも
s[x:x+y]
の方が計算が少なくて済むし

逆にpythonの中の人も
s[x:y]
が与えられたときに長さが
y-x+1
じゃなくて
y-x
となってここも計算が少なくて済む

小学生でも判るレベルの話

**デフォルトの名無しさん** · 2009/11/03(火) 21:58:48

x文字目からy文字目まで取り出すとき
s[x:y+1]と計算が多くて済むから合理的

**デフォルトの名無しさん** · 2009/11/03(火) 22:31:58

x文字目から最後の文字からn文字前まで取り出すとき
s[x:-n]と計算が少なくて済むから合理的

>>> 'abcde'[2:]
'cde'
>>> 'abcde'[2:-1]
'cd'
>>> 'abcde'[2:-2]
'c'

**デフォルトの名無しさん** · 2009/11/03(火) 22:33:52

s = 'abcde'
s[2:len(s)]
s[2:len(s)-1]
s[2:len(s)-2]

**デフォルトの名無しさん** · 2009/11/04(水) 17:09:36

Fortranに倣った

**sage** · 2009/11/05(木) 01:57:16

>571
a(:)みたいな配列を1-n, n-にわけたいとき、
Fortran a(:n), a(n+1:)
python a[:n] a[n:]
と、pythonの方がすっきりだ。これに気づいてからpythonのスライシングを許せるようになったw

**デフォルトの名無しさん** · 2009/11/05(木) 19:04:13

0-origin の index の場合、 [begin, end) で範囲を表現するのが一般的
大きさ0の範囲を [x,x) で表現できる。

**デフォルトの名無しさん** · 2009/11/06(金) 01:00:35

>>572
その表記ってC++勉強して初めて知ったけど一般的なん？

**デフォルトの名無しさん** · 2009/11/06(金) 01:12:29

数学表記でしょ
閉区間とか開区間とか

**デフォルトの名無しさん** · 2009/11/06(金) 01:36:39

ああそうか、思いっきり一般的だｗ
>>573で初めてとか言ったけど学校で習った覚えもあるわ

**デフォルトの名無しさん** · 2009/11/06(金) 23:36:11

ヨーロッパとかだと半開区間を [a, b[ とか書いたりする

きもい

**デフォルトの名無しさん** · 2009/11/10(火) 17:42:00

http://groups.google.com/group/unladen-swallow/browse_thread/thread/4edbc406f544643e
googleは新規のプロジェクトではpythonを使わないように勧めてるらしい

**デフォルトの名無しさん** · 2009/11/10(火) 22:34:32

GAEもう使ってないから関係ないわw

**デフォルトの名無しさん** · 2009/11/11(水) 00:31:02

だからといってRubyやPerlやPHPが代わりに使われることはないわけだが。

**デフォルトの名無しさん** · 2009/11/11(水) 00:33:31

するとGuile？
名前も似てるしな
名前も似てるしな

**デフォルトの名無しさん** · 2009/11/11(水) 01:16:24

Google のいちおしは Noop on Scala だろ

**デフォルトの名無しさん** · 2009/11/11(水) 01:49:35

Javaってことじゃん
やっぱ時代はじゃばだよな！

**デフォルトの名無しさん** · 2009/11/11(水) 12:50:13

Goって囲碁のプログラムかと思ったよ

シンプルで高速、Googleの新プログラミング言語「Go」
ttp://journal.mycom.co.jp/news/2009/11/11/025/?rt=na

**デフォルトの名無しさん** · 2009/11/11(水) 15:23:00

Google の中の人、言語作るの好きだな

**デフォルトの名無しさん** · 2009/11/11(水) 18:21:08

Noopが当て馬、Goが本命？

**デフォルトの名無しさん** · 2009/11/11(水) 22:10:10

また中途半端なものを出してきたなw

**デフォルトの名無しさん** · 2009/11/11(水) 22:46:39

単に Google の中の人は飽きっぽいだけだと思

**デフォルトの名無しさん** · 2009/12/25(金) 20:18:30

test

**デフォルトの名無しさん** · 2010/01/10(日) 22:59:29

なんでlist.rindexがないのか、理解できない

**デフォルトの名無しさん** · 2010/01/10(日) 23:03:05

双方向リンクになってないから？
reverseかけてからやるしかないね

**デフォルトの名無しさん** · 2010/04/10(土) 18:43:33

なんでPythonスレはあんなに荒れているのに、このスレはこんなに平和なのか。

**デフォルトの名無しさん** · 2010/04/11(日) 16:53:40

このスレが機能してないからでは

**デフォルトの名無しさん** · 2010/04/11(日) 17:28:44

ここはスレタイがネガティブだから平和なのでは。
本スレに"人生の敗北者でも使える"を付けてみるとか。

**デフォルトの名無しさん** · 2010/04/11(日) 18:38:07

そういえば昔は付いてたな

**デフォルトの名無しさん** · 2010/04/14(水) 13:15:53

とあるエディットボックスの日本語入力中にIMEの変換中の文字列を取得したいのですが
from ctypes import *
from ctypes.wintypes import *
ImmGetContext = windll.imm32.ImmGetContext
ImmGetContext.argtypes = [c_int]
ImmGetContext.restypes = c_int
ImmGetCompositionString = windll.imm32.ImmGetCompositionStringA
ImmGetCompositionString.argtypes = [c_int, c_int, c_char_p, c_int]
ImmGetCompositionString.restypes = c_int
GCS_COMPSTR = 0x0008
hwnd = エディットボックスのウインドウハンドル
himc = ImmGetContext(hwnd) # 入力コンテキスト取得
buf = create_string_buffer('dummy', 1024) # バッファ作成
print ImmGetCompositionString(himc, GCS_COMPSTR, buf, 0) # IME変換中の文字列の長さに応じた値が返ってくる
print ' '.join(('%02x' % ord(c)) for c in buf.raw) # 常にバッファ作成時の初期化文字列「'dummy'」しか返ってこない
…となってしまいます
ctypes のポインタ渡しの説明を見ると c_char_p ではなく
create_string_buffer で作ったものを渡せとあるので
そうしたつもりなのですが期待通りに動きません
どなたか上手く取得する方法を教えてください
ちなみに
buf = create_string_buffer('dummy', 1024)
print '>',
# libc.scanf('%s', buf)
cdll.msvcrt.scanf('%s', buf)
print ' '.join(('%02x' % ord(c)) for c in buf.raw)
print buf.value
こちらは動きます
バッファオーバーランとかの突っ込みはなしでおながいします

**デフォルトの名無しさん** · 2010/04/14(水) 14:16:47

ImmGetCompositionString(himc, GCS_COMPSTR, byref(buf), 0) は？

**デフォルトの名無しさん** · 2010/04/14(水) 14:54:02

ImmGetCompositionStringの第4引数を0 => len(buf)あるいは1024

**デフォルトの名無しさん** · 2010/04/14(水) 14:55:20

ImmGetCompositionStringの
3つ目の引数はLPVOIDだけど
char*として扱っていいのか？

**デフォルトの名無しさん** · 2010/04/14(水) 15:01:11

>>596-598
ありがとうございます

ImmGetCompositionString(himc, GCS_COMPSTR, buf, len(buf.raw))

で取得出来ました

**デフォルトの名無しさん** · 2010/04/14(水) 15:10:26

なんでPythonスレはあんなに荒れているのに、このスレはこんなに平和なのか。

**デフォルトの名無しさん** · 2010/04/14(水) 15:14:50

>>597
print ImmGetCompositionString(himc, GCS_COMPSTR, buf, len(buf))
print ' '.join(('%02x' % ord(c)) for c in buf)
print buf.value

で大丈夫でした

あと
変換中の文字列が len(buf) の長さよりも長いとき
ImmGetCompositionString の戻り値は 0 になるみたいです

ありがとうございました

**デフォルトの名無しさん** · 2010/04/14(水) 23:25:34

>>600
本スレだったら
len(buf)ってなにそれ？普通はbuf.len()だろww
ってなってるな。

**デフォルトの名無しさん** · 2010/04/15(木) 00:41:12

>>602
こっちくんな

**デフォルトの名無しさん** · 2010/04/15(木) 17:50:47

　　　　ﾍ⌒ヽﾌ
　　　（　・ω・）　㌧㌧
　　　/ ~つと）

**デフォルトの名無しさん** · 2010/05/02(日) 19:20:41

C++アプリにPythonを組み込んでみたいんだけど、
BlenderってアプリはPCにPythonをインストールしてないとPython動かせないじゃないですか。
アプリからPythonスクリプトを実行するにはPython環境を必要とするものなんですか？

あとマルチコアCPUだと実行が遅くなるって本当ですか？

**デフォルトの名無しさん** · 2010/05/02(日) 21:37:41

Ruby使うと良いよ

**デフォルトの名無しさん** · 2010/05/02(日) 22:17:28

>>606
ありがとうございます
Rubyの方が組み込み言語として枯れてるんですか？
PythonやJavaScriptに比べるとユーザ少そうだし一番トラブりそうと思い込んでました

**デフォルトの名無しさん** · 2010/05/03(月) 12:46:46

cython

**デフォルトの名無しさん** · 2010/05/05(水) 10:14:49

　　　 ┌─┐
　　　 │●│
　　　 └─┤
　　　_ 　 ∩
　　( ﾟ∀ﾟ)彡
┌─┬⊂彡
│●│　おっぱい！おっぱい！
└─┘　　　　　おっぱい！おっぱい！

**デフォルトの名無しさん** · 2010/05/28(金) 09:39:44

保守age

**デフォルトの名無しさん** · 2010/05/29(土) 12:08:14

ﾘﾊﾞｰｽｴﾝｼﾞﾆｱﾘﾝｸﾞ ―Pythonによるﾊﾞｲﾅﾘ解析技法が欲しい

**デフォルトの名無しさん** · 2010/06/11(金) 19:47:46

LLでバイナリってのも今ひとつ何をねらってるのかよくわからんな

**デフォルトの名無しさん** · 2010/06/11(金) 19:58:26

C言語でsegvしながらガリガリ切り貼りするよりだいぶ楽なことが多いと思う