pythonがこの先生きのこるには
■ このスレッドは過去ログ倉庫に格納されています
$python kinoko.py this_teacher >>82 ↓これと同じことだと思う。 >>> False==False True >>> (1==2)==False True >>> 1==2==False False >>> Pythonの比較演算子は複数つなげられる。その場合、 最初の比較演算子が False なら結果は False、そうでなければ 次の比較演算子が False なら結果は False、そうでければ その次の比較演算子が・・・・・と続けていって すべての比較演算子が True なら結果は True となる。 ある比較演算子で False になると、そのあとに比較演算子があっても評価されない。 1 in [] in [False] の場合、最初の in 演算子が False になるので 次の in は評価されないまま結果は False となる。 >>83 in演算子にもこの法則適用されるんだ…… >>84 そうねw >>> o='oOo' >>> O='ooOOoo' >>> def ooOOooOoOOoo(oO): print oO; return ooOOooOoOOoo ... >>> ooOOooOoOOoo(o)(o)(O)(O)(o)(o)(O)(o)(O)(O)(o)(o) oOo oOo ooOOoo ooOOoo oOo oOo ooOOoo oOo ooOOoo ooOOoo oOo oOo いまのOctalは危険な気がするので0o123で良いんだが (つーかどうせ使わん)、そんなことより2進表記を 用意して欲しいものよ・・ こういうことじゃないの? >>> 064 # base 8 52 >>> int('064') # base 10 64 2進表記って↓とは違う話? http://www.python.org/dev/peps/pep-3127/ あ〜まさにこのPEPで言い尽くされてます。 ちなみにハードウェア寄りの仕事してると ビット列扱うことが結構あるんですわ。 >>92 ハードウェア寄りの仕事でPython使うのん? そんなことは無い グッスミン、ララ〜、ララッラ、ラッラッラ〜 死にかけてるわけじゃ無いんだから、 このスレいらんがな。 このスレは本スレにはとても書けない様なかっこいいネタを見つけてしまった人専用の隔離スレです。 ちょっとしたうれしい発見 >>> def g():yield 1;yield 2;yield 3 ... >>> g() <generator object at 0x00BE5490> >>> a,b,c=g() >>> a 1 >>> b 2 >>> c 3 あ、ジェネレータでもできるんだ。 でもイテレータやジェネレータって個数わかんないことが多いから使う機会少なそう……。 a, b, c = 'abc' もっと使わなそうなのもあるぜ 左辺がリストの場合、 ・sequenceである式 ・yield式 のどちらか。 http://www.python.jp/doc/2.4/ref/indentation.html 小文字の "l" 一文字は使ってはいけませんと自分たちで言っておいて、ドキュメントの例の中で使ってる件 だから大人は嫌いなんだぁぁうわぁぁぁぁああああああ pythonって元々の哲学から逸脱してるような気がする。 Neal Norwitz: >Alpha 1 is a few *weeks* away. The release will hopefully come >shortly after the sprint at Google which is Aug 22-25. windows用installerとかもすぐ出るんだろうか・・・? http://www.python.org/dev/peps/pep-3124/ いつの間にかGeneric Functionが無期限延期に、・・・・ 正体不明で期待してたのに・・・・ なんか、相当根本的な難点にぶつかったらしい・・・ どこらへんが? PythonのBNFは専用に拡張されてたはずだけど そのこと? a_expr とか and_expr とか xor_expr とか augop とかで、 texから変換したときのミスで出てきたっぽい意味ない記号がポロポロ混じってる。 ひどいのがprint_stmtでこれは相当カンを働かせないと元が何だったか分からない。 (まあ、本文見れば正解が分かるけど、・・・ callもひどい、変な重複があるし、なぞのTab文字が混入してるし、 ソース見ればいいし 誰も必要としてないから きちんと保守されてないのかな。 確認 >>> class A(object):pass ... >>> isinstance(A,type) True >>> isinstance(A(),A) True α何とか出したけど、実際はまだまだ問題山積みっぽい感じだ、ML見てると・・・、 >>120 だからαなんでしょ。 Pythonのリリーススケジュールはかなり寝られてる。 安心して一年待てや。 会社のおっさんSE(昔の自慢話ばかりしてる)にPythonの説明してたら、 偉そうに「みんな同じようなソースになってつまらない」とか言ってた。 俺は教養主義者じゃないけど、こういうアホを見ると計算機科学の基礎くらいはやった方がいいと思った。 なんか自分が発明したアルゴリズムがいくつかもパクられてるとか言ってるし…。 つーか仕事の邪魔だよおっさんひっこんでろ! 同じことやるソースなら、同じになっていいんだよ。 だから、同じようなソースを書くのがいやなら、同じことをやらなければいい。 みんなで同じのを作って競うんでもない限り、やったことないことをやった方が楽しいじゃん。 同じ問題に対して、今までと違うやり方でやるのも含めてね。 同じ処理でもクラス作りたがる奴、ローカル関数作りたがる奴、 ワンライナーにしたがる奴…と色々特徴はあるぜ すまん、板違いだった…。 >126 λを知らないし、そもそも関数の意味とか分かってない。 だから、ジェネレータや高階関数の意義も理解できないし、思い浮かびもしないはず。 (それでアルゴリズムを作ったとか言っているあたりが…。) ただ、最近の若手はこのあたりを抑えてて、頼もしく感じる。 あと、お詫びにこのスレに沿った話題も。リスト内包はジェネレータ表現に統合されていくらしいね。 これはときどきリスト内包しか使えない場所にジェネレータ表現を使ってしまうことがあるので、個人的には助かる。 (書く内容はほとんど一緒なわけだし) C++のプロジェクトからPythonのモジュールを利用する方法教えて下さいでつ。 (1.0 + 2.0j).realのリアルは何で、methodじゃなくて属性なんだろう、・・・ conjugateはメソッドなのに、・・・なんかシンメトリーが崩れてる気がする。 複素数に対して共役は関数だが実数部は関数じゃないからでは ??? R を実数全体、C を複素数全体とすると real: C→R conjugate: C→C で両方とも関数だけど、そういうことじゃなくて? 確かに実数部を取り出す操作は関数で表せるが、この場合は実数部が 複素数の属性(項)だということを強調したんじゃないか、ということ。 どうせ属性値として持ってんだから、わざわざ関数作るまでもないだろ、みたいな不精 http://mail.python.org/pipermail/python-3000/2007-November/011103.html >Currently (in 3.0), "".join(<seq>) automatically applies str() to the >items of <seq>, いつのまにかきもい仕様が入りだしてる。 joinはstringの列以外が来たらエラーを吐くのがpythonらしくていいと思ってたのに・・ IOをハックしてた人(でも、contributeするほどには知識がなかった人)にGuidoがやさしい言葉をかけてるのが和んだ おいおいマジか・・・ def a(): p = yield 1 for i in a(): print i >p = yield 1 構文エラーにならないのかよってこと? そうそう、 文を式として使うなんて、・・・ こんなのなんで必要なんだろう・・・ ジェネレータ使う側との通信用だよ まあもっと良い書き方はないのかという気はするが 値を出力する言語要素は少ないからな。 importに倣って yield_stmt ::= "yield" expr ["receive" name] とか? しかしまぁ今のでもlambdaと同程度には穏当かと。 >>143 assignment_stmt ::= (target_list "=")+ (expression_list | yield_expression) yield_stmt ::= yield_expression なんだが? むしろyield文は、式文のように値を捨てている。 yield式は、常に値をスタックに積んで、 yield「文」なら(制御から戻った時に)要らないから捨てる。 単純な実装だとこうなる。 構文に合致していてスタックマシンで実装しやすい。 (expression_list | yield_expression) expression_listなんていうかなり一般的なものと、yield_expressionつう割と特殊な ものが並列で並んじゃうこと自体がおかしいと思う。 >>147 Python構文のBNFの構造(grammar.txt)は、 単純な実装コードへ自然に変換できるような書き方になってる。 優先順位を埋め込んだり。 特別な処理が必要なものは、 コンパイラ・コンパイラのアクション部に実装を書けるところまで、 特別なノンターミナルとして扱うとコード生成が簡単。 かなり構文/意味解析に手慣れた人たちが書いているなあと思う。 ただ、後から拡張した部分が、継接的に残っているところもあるみたい。 Pythonオワタ・・・orz 俺もう乗り換えるわ Running the snippets above, I got the following results: Python 2.5.1: 31.507s Ruby 1.9.0: 11.934s The Ruby code: def fib(n) if n == 0 || n == 1 n else fib(n-1) + fib(n-2) end end 36.times do |i| puts "n=#{i} => #{fib(i)}" end And the Python equivalent: def fib(n): if n == 0 or n == 1: return n else: return fib(n-1) + fib(n-2) for i in range(36): print "n=%d => %d" % (i, fib(i)) うちの環境だとpython2.5は37秒ぐらいで、ruby1.8は100秒前後だった、(まるっきり↑のコードまんまで ruby1.9ってほんとにそんなに早いの?(入れるのめんどくさくて試せない つうか、py3000は速度的な改善はないんだっけ? >>153 ありがとうございます。 自分でもやってみました。 python2.5.1: 49.147s python2.5.1+psyco: 2.958s ruby 1.8.6: 1m59.859s ruby 1.9: 36.132s python 2.5.1 0m49.463s jython 2.1 on java1.6.0 (JIT: null) 0m28.918s python 2.5.1 102.657s IronPython 2.0A6 54.043s IronPythonは起動に時間がかかるのがふにふに。 ruby1.9は何が変わったんでしょう? あと、ついでなのでF#もおいときますね。 let rec fib n = if n = 0 || n = 1 then n else fib(n-1) + fib(n-2) let _ = for i = 0 to 35 do printfn "n=%d=> %d" i (fib i) done;; Ruby 1.9の最大の変更点は。 RoRが動かなくなることだよ。 PyFinalizeでメモリ回収しきる前にGC終わらせる動作なんとかならないの? >>155 > python 2.5.1 > 0m49.463s > > jython 2.1 on java1.6.0 (JIT: null) > 0m28.918s つづき (全く同じ環境です) ruby 1.8.5 1m50.823s ruby 1.9.0 2m28.901s jruby 1.1.b1 on java1.6.0 0m30.278s やっぱJVM w/HotSpotはこういう単純なテストだと速いね。 俺の環境(Intel L2300 @ 1.50GHz)だとruby 1.9.0はかなり遅い。 あ、同じ1.9.0でも20060609→20070830としたら、 ruby 1.9.0 (20070830) 0m34.250s となりました。 うちの環境 @PentiumM 1.7GHz Python 2.5.1 40.00s user 0.32s system 98% cpu 41.066 total Python 2.5.1 + Cython 18.73s user 0.11s system 98% cpu 19.174 total Python 2.5.1 + psyco 2.13s user 0.04s system 91% cpu 2.371 total >>165 Cythonはもっと速度が出ると思うけど >>166 糞コードそのままだからね 書き換えたら100まででこんな感じ …略… n=98 => 135301852344706746049 n=99 => 218922995834555169026 python fibtest.py 0.03s user 0.01s system 13% cpu 0.295 total >>150 は計測専用だろ、 むしろこんなアルゴリズムでフィボナッチ数計算しようなんて逆に思いつかない haskellを優位に見せるためだけのコードでしょ、あれは インタープリタの Moscow ML でも Python の 10 倍くらい速かったよ。 3.0で 単に[0, 1, 2, 3, 4, 5, 6, 7, 8]が欲しいごときで list(range(9)) って書かなきゃいけないのって長くね? 対話実行時にストレス感じそう >>175 r=range list(r(9)) インタラクティブならこういうことしない? r=lambda x: list(range(x)) r(9) めちゃつかうならこうしちゃえばいいし。 def N(): i = 0 while 1: yield i i += 1 def enumerate(g): return zip(N(), g) 本家MLでmetaclassの話題振ってきたやつに対する海老ーの対応が いやな奴過ぎてドン引きした。 ttp://mail.python.org/pipermail/python-3000/2007-May/007107.html この辺? それは全然普通に議論してるように見えるけど・・・ それじゃなくて、ごく最近ので、初ポストですって言ってメタクラスの話題振ってた奴に対して の扱いがなんか異常だった。 で、その人の最後の捨て台詞が、「なんでpythonに貢献することが、楽しみというよりもむしろつまんねー作業なのかが 良く分かりました。本当にありがとうございました。」 >Python 3.0 compatibility >------------------------ >As it will be used for Python 3.0 too, the toolset should be kept in a state >where it is fully usable Python 3 code after one run of the ``2to3`` utility. > 3.0でも使えなきゃやだ。道具箱の手入れは怠るべからず。3.0でも使えるように。 >一連の2to3ユーティリティが登場したら。 2to3コンバータツールをかまして互換性を取るというのは本当? もしそうだとしたらコードを書く時どういう点に注意したら良いでしょうか。 Python 3000 FAQ http://www.artima.com/weblogs/viewpost.jsp?thread=211200 http://www.kt.rim.or.jp/ ~kbk/zakkicho/07/zakkicho0707.html#D20070730-4 >You can't use .iterkeys(), but .keys() works differently in 2.6 and 3.0. >You can't use xrange(), but range() works differently. >You can't use metaclasses, as the syntax for specifying a metaclass >is completely changed in 3.0. And so on. >あなたは2.6と同じ記法で.iterkeys(),xrange(),metaclassを扱うことはできません。 >.iterkeys(),xrange()は廃止 => keys(),range()に移行 >metaclassは定義の仕方が変更されます よく読んでみたら、あんま変わらないってことなのかな?英語ややこしい むぅ ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる