【Perl,PHP】LLバトルロワイヤル7【Ruby,Python】

【Perl,PHP】LLバトル ..

371:デフォルトの名無しさん
09/09/19 15:19:48
速報：グーグルが新言語「Noop」を公開。JavaVMで動作－ Blog on Publickey
URLﾘﾝｸ(www.publickey.jp)

372:デフォルトの名無しさん
09/09/19 15:36:40
今にはじまったことじゃないが、相変らずGoogleのプロダクトはいまいち感かもしだすなあ。

373:デフォルトの名無しさん
09/09/19 16:33:39
>>365
今すぐ自分の役にたつもの作りたいならHSP
時間がかかってもいいから人の役に立つもの作りたいならRuby

374:デフォルトの名無しさん
09/09/19 21:48:24
おまえらそんな糞なものすすめんなw

375:デフォルトの名無しさん
09/09/19 21:52:52
まぁ一生そこから出てこないってんならHSPやRubyもありかもな
でも他の言語もやるかもしれないならその２つは止めとけ
害にしかならん

376:デフォルトの名無しさん
09/09/19 22:01:15
>>362
論理演算はまだ？

377:デフォルトの名無しさん
09/09/19 22:02:05
>>362
bit演算はまだ？

間違えた
アホだorz

378:デフォルトの名無しさん
09/09/19 22:07:03
>>355 >>370
SQLで覆面算を解いてるケースがあるからあなどれんよ

379:デフォルトの名無しさん
09/09/19 22:20:27
Noop
Yeah, perhaps.. I personally find it more readable and I think there is good precedence for it in python
and ruby, but totally understand the other view... As far as xor, nand, etc, if we were to have "and"
and "or" and if we aren't afraid to add keywords, why not? :)

if foo and bar:
if not foo:

On an sort of related note, I always liked being able to give the conditional at the end:

foo = 2 if bar; // Ruby style
foo = 2 if bar else 0; // Python style where else is required, which I find super annoying sometimes
bar = 1 unless foo; // Ruby style unless, though I find if not easier to deal with than unless in my brain
bar = 1 if not foo;

This gets to ternary expressions, which can be more readable this way as well...

foo = 1 if bar else 2;
foo = 2 unless bar else 1; // Probably unnecessary

Otherwise I guess we would use (a ? b : c) ?

380:デフォルトの名無しさん
09/09/19 22:21:52
I like the gabrielh's vote to put the conditional at the end:

foo = 1 if bar;

I'd also like to suggest my favorite looping construct from Pick Basic (yes Basic):

loop {
　　x = doSomething();
} while (!x) {
　　doSomethingElse();
}

putting the test in the middle of the loop allows you to dispense with any setup code for the loop
that has to be repeated within the loop -- it all goes before the test and will be executed again
for each iteration.

381:デフォルトの名無しさん
09/09/19 22:23:31
An array is essentially a function that takes a numeric parameter and returns a value.
A Map can also be viewed as a function that takes an object (usually a String) argument
and returns an object. They are essentially parametrized objects. Why can't we unify the syntax?
A template (Generics) takes a parameter and behaves like a function also. Can we then move
toward a syntax similar to the following?

Array(Int) factorial = {1, 1, 2, 6, 24, 120};
Int fourth = factorial(3); // fourth == 6
Object myObj = myMap("myKey");

We can standardize this feature for all classes by using a special method:

class TableRow() {
　 String get(String name) { /* Return field name as a String */ }
　 String get(Int 　　i 　 ) { /* Return field i 　　as a String */ }
}

TableRow row = getNextTableRow();
String city 　　= row(5); 　　　　 // city == "Alexandria"
String country = row("Country"); // country == "Egypt"

This is especially useful if we can extend the syntax to set values and not only retrieve them.
The syntax might then look like this:

class TableRow() {
　 String get(Int i) { 　　　　　　　　 /* Return field i as a String */ }
　 void 　 set(String value, Int key) { /* The 　first parameter is the new value */ }
}
TableRow row = getNextTableRow();
String city = row(5); 　　　// city == "Alexandria"
row(5) 　　　= "Ankara"; 　　// row(5) is mutable of course
String town = row(5); 　　　// town == "Ankara"

382:デフォルトの名無しさん
09/09/19 23:33:52
>>380
これはPythonに欲しい。

>>381
array[index] と map[key] を関数のようにみせるために
array(index) と map(key) のように書くのか。
そのせいで代入が array(index) = value とか、きもいわ。

383:デフォルトの名無しさん
09/09/19 23:45:22
オブジェクトの参照を返す関数で
hoge(fuga) = hage
っていうのは他の言語でも有な気がする

pythonの
codecs.getreader('utf-8')(file('test.txt')).read()
みたいなのも当初はきもいと思ったけど慣れたらそうでもないし
Javaでも結構こんな書き方しなくね？

384:デフォルトの名無しさん
09/09/19 23:47:02
array(index)は今のPythonでも可能だろうけど（callの挙動を弄るだけ）
array(index) = value はかなり無茶なことになるな
BASICみたく配列の添字が括弧なのか、それ？

385:デフォルトの名無しさん
09/09/19 23:49:53
>>378
kwsk

386:デフォルトの名無しさん
09/09/19 23:50:08
>オブジェクトの参照を返す関数
この辺がキモなのかな
言語仕様によっては無理筋過ぎそうだけど
よくわからん

387:デフォルトの名無しさん
09/09/19 23:57:34
VBでも
hoge.item(n) = x
の場合
itemが配列なのか関数なのか
区別出来ないっていうか意識しなくて良いようになってるのでは

388:デフォルトの名無しさん
09/09/20 00:12:24
そのうちmutableかimutableかが判らなくなる気がする

389:デフォルトの名無しさん
09/09/20 00:24:01
>>383
やっぱ普通に hoge(fuga).Value = hage とかじゃないとキモく感じるわー

390:デフォルトの名無しさん
09/09/20 00:25:34
NoopはGAE/bigtable専用言語なのかと思った

391:デフォルトの名無しさん
09/09/20 00:51:57
Noop専用スレ立ってるからこっちで
ｽﾚﾘﾝｸ(tech板)

392:デフォルトの名無しさん
09/09/20 03:24:54
またおまえら新しいものに手出すのか。他にやることがあるだろうw

393:デフォルトの名無しさん
09/09/20 05:40:17
新しい言語がでてきて既存の言語と競争することで、既存の言語も改良されるのだったら歓迎だよな。
新しい言語万歳。

394:デフォルトの名無しさん
09/09/20 09:44:52
プログラマー的発想だな。。作業員の覚える作業内容が増えるだけ。
経営者的にも、今の開発環境は各種技術が乱立してて、設計も人員リソースも
計画がたてづらい。
プログラマーにしてもスキルセットとかキャリアプランをたてづらいし、
転職の際の壁になることが多いし。
なんでも言語できますって奴は、器用貧乏な奴が多いよ。数理処理とかレンダリング
とかネットワークとか専門的なことできなくって、結局WebとかDBとか誰でもできるとこ
やることになる。

395:デフォルトの名無しさん
09/09/20 10:06:14
>>394
しむら、スレタイ！スレタイ！

396:デフォルトの名無しさん
09/09/20 10:11:21
だな。
393みたいに他の言語を迎合してたらバトルロワイヤルになってないな。
けしからん。

397:デフォルトの名無しさん
09/09/20 11:36:25
>>394
ウチの会社のメインは汎用機で金融系なトコなんだけど、そういう考えが強く、
結果オープン系の技術力が他の会社に比べて著しく劣っている。
で、世の流れで営業がオープン系をねじ込んできて、導入したら障害が大量発生。
エンジニアは老害と偽装派遣ばっか。
地獄だよ。

まあ研究職と人身売買業種とは別に考えろよ。

それにここはプログラム板でプログラマーが多いのは当たり前。

398:デフォルトの名無しさん
09/09/20 12:34:30
>>347
俺は真偽と0、nil系は別もの派だからオケー

399:デフォルトの名無しさん
09/09/20 12:48:02
Webは新しいこととか、他より見劣りしないようとか営業的圧力が強いからなあ。
なんとかしようと開発は、流行りのその辺に転がってるOSS使って、
はりぼてにノリを塗りたくってる感じ。

400:デフォルトの名無しさん
09/09/20 19:48:00
問題はその営業が顧客の押しに弱かったりすることだな
Perlで案件取りにいったのに帰ってきたらJavaになってたときは怒鳴り散らした

401:デフォルトの名無しさん
09/09/20 19:51:45
Javaがいいなんて言う顧客なんているんだ
PHPがどうしても嫌だという顧客は多いが

402:デフォルトの名無しさん
09/09/20 19:57:50
ディスプレイタッチパネルでやる予定が、いつの間にか別の小型端末からの入力まで入ってたからな
その頃はJavaやってなかったから、最初の見積もりから3倍ぐらになるかな、といっただけで青ざめてた

403:デフォルトの名無しさん
09/09/20 21:23:23
>とかネットワークとか専門的なことできなくって、結局WebとかDBとか誰でもできるとこ
>やることになる。

Webはドカタな現場が多いとは思うが、案件の規模がでかい（億を越えるケース）
とかだとDB部分は相当なエンジニアでないと参加できないけど。

DBが誰でもって発言が出てくる辺り相当に底辺しか知らん印象があるが。

404:デフォルトの名無しさん
09/09/20 21:29:17
誰でも最低のことは出来るが、最高のことが出来るまでには相応のスキルが必要ってのと
誰でも要件を満せて、天井もすぐ、っていうのとの区別がつかない奴って絶対いるよな。
「ウェブなんて小学生でも出来るんでしょ？」とかほざく頭の悪いおっさんとか。

405:デフォルトの名無しさん
09/09/20 22:19:40
そもそも、全く新しいアルゴリズムの開発なんて仕事はめったにないしな。
五十歩百歩だよ。

406:デフォルトの名無しさん
09/09/20 22:43:18
>>403
前に流体とか応力計算とかやったけど、理系で大卒のそれなりの人じゃないと無理。
DBとかは短大文系でもやらせりゃ1年でできるようになるからね。

407:デフォルトの名無しさん
09/09/20 22:55:25
>>406
>DBとかは短大文系でもやらせりゃ1年でできるようになるからね。
この発言が>>404のほんといい実例だよな

408:デフォルトの名無しさん
09/09/20 23:12:06
※ExcelDBを含む

409:デフォルトの名無しさん
09/09/20 23:21:34
DBを「使ったことある人」と「使いこなせてる人」の差は広すぎる。

410:デフォルトの名無しさん
09/09/20 23:41:47
DB設計のためにはモデルを作り上げる能力が必要だが、
流体にしろ応力計算にしろ、先人の作り上げたモデルを利用できれば十分だからな。

411:デフォルトの名無しさん
09/09/21 00:06:14
＞DBとかは短大文系でもやらせりゃ1年でできるようになるからね。

Accessの話でもしているのか？
このニートは。

412:デフォルトの名無しさん
09/09/21 01:20:39
410は406へのカウンターなんだろうと思いつつ
そんなことはないと言ってみる

413:デフォルトの名無しさん
09/09/21 01:43:48
1年はかかり過ぎだろどうみても

414:デフォルトの名無しさん
09/09/21 06:49:41
ExcelとかAccessなら１年で出来なきゃアフォだろうな。

415:デフォルトの名無しさん
09/09/21 09:52:55
DBってもともとデータ処理を簡単に扱えるようにしたアプリだからな。
誰でも使えないとそれはそれでおかしい。

416:デフォルトの名無しさん
09/09/21 11:05:25
ExcelやAccessはマクロ言語を内蔵していて、GUIパーツも使えるわけで、ウェブアプリより応用範囲が広い。

417:デフォルトの名無しさん
09/09/21 12:10:41
サクサク作れるのは良いけど
いまだにソースやオブジェクトの管理が改善されないので大規模化するとカオスになるよ

418:デフォルトの名無しさん
09/09/21 13:52:09
ソース埋め込みだからね

419:デフォルトの名無しさん
09/09/21 13:53:03
どのくらいの規模からカオスになる？
大規模っていうのは人によって全然違うから、いちおう聞いてみる。

420:デフォルトの名無しさん
09/09/21 14:16:03
カオスになるのは規模関係ない。

421:デフォルトの名無しさん
09/09/21 14:38:16
機能が増えて、メンテナンス性を上げようとクエリやら関数を共通化しようとしたあたりからカオスだな

422:デフォルトの名無しさん
09/09/21 15:10:39
自分で作ったフォームと良く似た機能のフォームを
ソースをちょっとだけ変えて２つ目を作るとき
それなりのプロジェクトでは共通部分を親クラスにして
それぞれが継承したりするもんなんだが
Access/Excelでは良く似たフォームを
もう一度最初から作るしかないのか

423:デフォルトの名無しさん
09/09/21 16:14:34
いや、コピペするからそんなことないよ

424:デフォルトの名無しさん
09/09/21 16:27:48
そして後日修正漏れが発生するのですね、わかります。

425:デフォルトの名無しさん
09/09/21 16:50:42
最近はdiffを使いこなしてるから修正漏れはなくなったよ。
diff -rbw
これの意味分かるかい？へへへ

426:デフォルトの名無しさん
09/09/21 17:09:02
-uは付けないの?

427:デフォルトの名無しさん
09/09/21 18:40:59
<>の方が好きだからつけないよ
patchとか使わないし

428:デフォルトの名無しさん
09/09/21 20:55:09
フォームの継承はマジで出来ませんか？

429:デフォルトの名無しさん
09/09/21 21:07:28
Excel VBAとかって使ったことあるけど、バージョン管理ソフトで差分管理できなくて大変だった。
ソースをdiffれねえｗ

430:デフォルトの名無しさん
09/09/21 21:22:38
俺もDB定義書をSQLにするようなのを書いて使ってるんだが、その辺が不満
コピペで無理矢理SVNに突っ込むって以外に、何か方法はないのかな

431:デフォルトの名無しさん
09/09/21 21:25:56
Flashもソース管理できないから大変。プロジェクトファイルのバイナリ1個しかはかねえし
Flex？だとファイルがバラになるからいいんだけど

432:デフォルトの名無しさん
09/09/21 21:34:03
Office2007でxml形式で保存したらsvn/diffに合いますかね

433:デフォルトの名無しさん
09/09/21 21:35:58
>>431
Flashはソースをテキストからincludeする方法があるからまだましかと
ちょっとめんどいけど

434:デフォルトの名無しさん
09/09/21 21:43:53
>>432
ODFにしてもそうだけど、最終的にはzipでまとめてるから
既存のバージョン管理システムとは相性悪いんじゃないかな

435:デフォルトの名無しさん
09/09/21 22:50:18
>>432 >>434
圧縮されてるんだよな。

しかもデータがでかいとロードが時間掛かりすぎるから、バイナリ形式で保存したりするし。

436:デフォルトの名無しさん
09/09/22 00:51:37
RubyをVisualBasicの代わりとして使えないかなと考えている。
VisualBasicは進化の方向性を致命的に誤ったと思うのだよね。
旧VB6のポジションが空いている。
VB.NETに代替に成りきれていないでしょ？
そこにRubyが入れないかと、そう思った次第。

437:デフォルトの名無しさん
09/09/22 02:13:07
Pythonでもいいや

438:デフォルトの名無しさん
09/09/22 02:33:48
>>436
Rubyはよいのだが、GUI付くんのどうする？オススメライブラリ教えて欲しい。
web系ならRailsでも使ってwebインターフェスにすればいいかもしれんが。
GUIなら、VB.net、というかC#でいいしな・・・

439:デフォルトの名無しさん
09/09/22 02:58:46
>>438
大抵の人の言う「GUI」は「(見慣れたWindowsの)GUI」なんで
とりあえずVisualuRubyじゃない？

440:デフォルトの名無しさん
09/09/22 05:16:14
VisualuRuby昔使ったけど
イベントやらなんやら色々書き足さなきゃいけなくて
結局自分でAPIゴリゴリ読んだ方が速いってことで
VisualuRuby使うのやめちゃったな

WIN32API/WIN32OLEだけで殆ど問題ないし

ところでRubyから.NET呼べたっけ？

441:デフォルトの名無しさん
09/09/22 08:45:24
IronPythonを思い出してあげてください…。

442:デフォルトの名無しさん
09/09/22 10:07:01
VisualuRubyかサンクス、試してみるワー

>>441
俺はIronRubyに期待

443:デフォルトの名無しさん
09/09/22 13:29:04
言語の機能もあるけど、ＧＵＩアプリ作るなら、VisualStudioを超えないとな。まあ、C#は凄くいいと思うけど。

444:デフォルトの名無しさん
09/09/22 13:41:35
そうすると最終的にTcl/Tkが候補に挙がってくるわけだ

445:デフォルトの名無しさん
09/09/22 13:43:21
そういえば動的VBというかVBxの話はどうなったんだろね

446:デフォルトの名無しさん
09/09/22 13:54:56
Win/UNIX問わずGUIが充実したスクリプト作ったらそうとううけるね。

447:デフォルトの名無しさん
09/09/22 14:38:49
つPython

実際、海外だとそういう用途に使われてるしな・・・

448:デフォルトの名無しさん
09/09/22 14:38:52
現状で GUI アプリを作りやすい LL は何なの？

449:デフォルトの名無しさん
09/09/22 14:42:48
>>447
いや、やっぱ結局Win32呼ばんとできんこといっぱいあんのよ

450:デフォルトの名無しさん
09/09/22 14:47:45
つTcl

451:デフォルトの名無しさん
09/09/22 15:21:05
>>449
例えばどんな事？
今wxPythonをやってるんで気になる

452:デフォルトの名無しさん
09/09/22 17:14:47
>>451
今Dockableウィンドウとか使ってるけどたぶん無理でしょ。
つかオーナードローもできないのがほとんどじゃない？
あとIEコンポーネントもイベントシンクとか上手く使えなさそう。
まあ膨大なWindowsの機能をすべてラップするってのも無理な
話だと思うから、CとかDllを簡単に呼べるスクリプトがあったら
使いたい。

453:デフォルトの名無しさん
09/09/22 18:03:30
ctypes

454:デフォルトの名無しさん
09/09/22 19:52:45
Pythonは標準ライブラリにctypesがあるのが強いよね。
if sys.platform == 'win32' とかして WinAPI 呼ぶコードを混ぜた
クロスプラットフォームアプリが書ける。

455:デフォルトの名無しさん
09/09/23 02:23:40
wxPython 使いやすいね
GUI を XRCed で作って
ほぼ完全にコード部分と切り離せるのが素敵

456:デフォルトの名無しさん
09/09/23 02:27:58
>>451
URLﾘﾝｸ(kansai2channeler.hp.infoseek.co.jp)

457:デフォルトの名無しさん
09/09/23 09:11:14
>>456
昔VBで書いてたら、結局こんな感じのAPI呼び出しばっかになって
C++で書けばいいじゃんってなったよ。defineとか自分で書くのばからしいし。

458:デフォルトの名無しさん
09/09/23 17:54:31
Python3の普及度はどんなもんかね。

459:デフォルトの名無しさん
09/09/29 00:07:15
この間落としたWindows版はなんか2.5だった
何故だったんだろ

460:デフォルトの名無しさん
09/09/29 20:00:07
Snow Leopard にしたら 2.6.1 だ

461:デフォルトの名無しさん
09/09/30 22:34:19
sed,awkってLLにはいるん？

462:デフォルトの名無しさん
09/10/01 03:28:29
sedはプログラミング言語とは言えず微妙な気がする
awkは初期のLLと言えるんじゃね

463:デフォルトの名無しさん
09/10/01 10:35:37
awkはいまだにワンライナーで使うなあ。

464:デフォルトの名無しさん
09/10/01 10:50:19
俺はハードなCUI使いじゃないので、
ipythonをshellにしてipipeとか使うよ

465:デフォルトの名無しさん
09/10/01 13:06:37
で、LLってなにwに戻ると

466:デフォルトの名無しさん
09/10/06 22:19:28
最近思う。
「やっぱ、perlでいいや」

467:デフォルトの名無しさん
09/10/06 22:59:04
perlはなんか昔は良かったみたいな気分になるなｗ

468:デフォルトの名無しさん
09/10/06 23:04:08
perlはなんか昔は酷かったみたいな気分になるなｗ

469:デフォルトの名無しさん
09/10/07 00:11:53
LLでがっつりしたもの書く気しないし、汎用作業はperlでいいや
ガワが必要になったらtcl/tkでいいや

470:デフォルトの名無しさん
09/10/07 02:07:50
WEBプログラミングでの利用を前提に考えた場合Pythonってどうだろう。

471:デフォルトの名無しさん
09/10/07 03:30:29
標準で
cgi
wsgi
フレームワークでは
django
TurboGears
pylons
plone
zope
テンプレも
ORも
いっぱいある

472:デフォルトの名無しさん
09/10/07 04:20:53
なせかPではじまるのが3つ
Rではじまる天の邪鬼がひとつ

473:デフォルトの名無しさん
09/10/07 04:37:14
＞なせかPではじまるのが3つ
Prolog、Pascal、PL/Iですね、わかります。

474:デフォルトの名無しさん
09/10/07 07:21:24
スレタイ1000000回読んで出直せ

475:デフォルトの名無しさん
09/10/07 07:51:06
>>470
Webアプリに関して言えば、PHPやRubyの方がいい気が

476:デフォルトの名無しさん
09/10/07 07:54:59
根拠を述べろよ禿

477:デフォルトの名無しさん
09/10/07 08:36:51
サンプル多いもん
土台からして、PHPはサーバ屋さん任せにできるところは多いしもともとフレームワークみたいなもんだし、
Rubyなら、Railsの情報の豊富さも、CGIとしての利用例もそれなりに。チュートリアルもあるし。

間違いなくPythonの取っつきにくさは一段階上だよ
Windowsサーバでならちょっとは状況は違うのかな？

478:デフォルトの名無しさん
09/10/07 09:08:35
cgiとしての利用例ならPythonにでもいくらでもある。
あとは、Railsに情報が集中しているRuby vs Django/Pylons/TurboGears/etc... に
情報が分散しているPythonの違いになるけど、ぶっちゃけたいした差じゃないな。

479:デフォルトの名無しさん
09/10/07 09:19:37
CGIとフレームワークって、viとEmacsみたいなものなの？

480:デフォルトの名無しさん
09/10/07 10:33:21
違う。
なぜならCGIとframeworkでは聖戦にならない。

481:デフォルトの名無しさん
09/10/07 10:42:43
>間違いなくPythonの取っつきにくさは一段階上だよ
W

482:デフォルトの名無しさん
09/10/07 12:05:34
俺はPerlが一番取っ付きにくかったなあ

483:デフォルトの名無しさん
09/10/07 12:30:52
WEB業界ではPython浸透してると思うよ。
今日本でPythonが注目されてるのはGoogleAppEngineの成果も大きいし。

484:デフォルトの名無しさん
09/10/07 12:32:50
プログラミングはCGIの改造から入ったから、Perlが一番できるなー
その後、Rubyを勉強したけど、Rubyのほうがよさそうな感じ。

485:デフォルトの名無しさん
09/10/07 13:13:38
CGI ≒ perl

486:デフォルトの名無しさん
09/10/07 13:44:09
PerlやらPHPでWEBアプリが作りやすいってのは、みんな最初そこから入るからだろ？
パーミッションの設定やらなんだかんだ、フリーのアプリをなんとか動くように頑張って、
その後いろいろ改造して・・・ってな段階を踏んでるから。
大抵、基礎の筈のHTTPプロトコルの詳細やApache等Webサーバの仕事・設定を知るのは
それなりになんか書ける様になってから。そういう人がかなり多いという。

だから、全くの一からの取っつきやすさの議論ってのは、あんまり意味が無いと思う。
取っつきやすさって要は、どれくらいそれを触り、動かそうとする動機があるかってだけじゃん。

何がいいたいかというとPerl難いよめんどいよってことだ。なんだあのデリファレンスって。

487:デフォルトの名無しさん
09/10/07 14:05:16
>>485
そう認識してる馬鹿が多いという点は同意

488:デフォルトの名無しさん
09/10/07 14:09:11
webアプリしか書いたことのない人
あるいはwebアプリからプログラミングに入ったひとに
質問なんだけどデスクトップアプリって書ける？
or書きたいと思う？
or書けるようになるまでに違和感なかった？

489:デフォルトの名無しさん
09/10/07 14:40:34
>>488
画面を作るのが楽（簡単、ではなく）なら書けるだろうし書きたいだろうな。
JavaのSwing使って掲示板もどきなら書けた。
デスクトップアプリってのが何を指すのかよくわからんが、CUIで例えばncursesで
オセロとかなら、入力やら表示やらの段階で簡単に挫折出来る自身がある。

あと、やたら数を数えたり足し算引き算しまくるような記述が必要ないなら。
とにかく数を数える、数を指定する、数を覚える、という作業が面倒くさいイメージ。

って、隣の隣の兄ちゃんが言ってた。俺だけど。

490:デフォルトの名無しさん
09/10/07 15:06:06
>>488
>>484だけど、C#で挫折したわ。
趣味でPerlやRubyでCGIプログラミングするのがやっと。

491:デフォルトの名無しさん
09/10/07 15:06:13
>>485
やってた頃はcronでたたくscriptが多かったな
後は mail受信->DB登録を書いたりとか
＃PerlでCGI書くのはあまり好きじゃなかったよ

>>488
今どんなOS/言語使っているか、どのOS/言語を対象に考えているかが
無いと、なんとも言えないと思う
Postでパラメータ拾ってくるのとは違うけど、それ以降は同じだよ
＃画面出力は色々はコンポーネント使うことになると思うけどね

492:デフォルトの名無しさん
09/10/07 15:47:07
>>486
@{$hash->{key}} …つまり $hash->{key} （もしくは $list->[idx] ）と @{array_ref} の2つさえ判れば
デリファレンスは意外と何とかなる…気がする、逆に $$hash{key} とか考えると混乱する

493:デフォルトの名無しさん
09/10/07 16:55:21
>>490
簡単な本を１冊こなして、オライリーのプログラミングC#やれば
そこそこ、いけると思うのだが
＃後者のみでも可。ある程度の大枠つかまないと、使えないと思うよ
c#の構文そのものと.Net Framework 使いこなすのとは違うから

494:デフォルトの名無しさん
09/10/07 17:40:45
>>493
アドバイス、㌧
また挑戦してみるわ。

495:デフォルトの名無しさん
09/10/07 19:21:40
メインがウェブで、たまに頼まれてWindowsフォームのアプリ作るけど、HTMLに慣れてるとGUIを組み立てるのが面倒だな。その分、操作性が高いもの作れるけど。
後はウェブの場合、RDBMSに頼りすぎるっていうか。

496:デフォルトの名無しさん
09/10/07 19:25:55
っXAML

497:デフォルトの名無しさん
09/10/08 22:06:39
また、perl本買っちゃったよ。。

498:デフォルトの名無しさん
09/10/08 22:09:32
>>497
何買ったの？

499:デフォルトの名無しさん
09/10/08 22:12:46
続・はじめてのperl
ずっと初心者卒業できないんだ

500:デフォルトの名無しさん
09/10/09 00:21:21
お前らもっと異宗教どもを口汚くののしらないとだめなんだぜ。じゃないとバトルでロワイヤルじゃないんだぜ。

501:デフォルトの名無しさん
09/10/09 00:42:02
>>500
この豚野郎！

502:デフォルトの名無しさん
09/10/09 00:45:33
ケンカはやめて（＞＜）

503:デフォルトの名無しさん
09/10/09 01:19:40
バトルロワイヤルと言うよりは、暖を囲んで愚痴を吐いて励ましあってるよな。。。

504:デフォルトの名無しさん
09/10/09 02:00:05
う、うん……

505:デフォルトの名無しさん
09/10/09 05:10:30
>>501
お前、俺に・・そんな・・ﾊｱ・・・言葉浴びせる・・ﾊｱﾊｱ・・ないで；ください、お願いします。

506:デフォルトの名無しさん
09/10/09 17:28:49
RubyとPythonを足して2で割ったような言語を教えてほしいな…っと

507:デフォルトの名無しさん
09/10/09 17:45:44
>>499
RubyとかPythonのほうがいいんじゃない？

508:デフォルトの名無しさん
09/10/09 18:18:42
Schemeだろｊｋ

509:デフォルトの名無しさん
09/10/09 18:41:32
とりあえずPythonやっとけば仕事でも趣味でも困らない。

510:デフォルトの名無しさん
09/10/09 19:23:11
PythonとSchemeとJavaScriptをやってる。LL界隈では無敵だじぇ

511:デフォルトの名無しさん
09/10/09 20:18:53
>>506
perl

512:デフォルトの名無しさん
09/10/09 22:29:54
pythonが使われてるところってあるの？
少なくとも日本ではほとんどないんじゃないかな。

513:デフォルトの名無しさん
09/10/09 23:08:39
>>512
Windows では DropboxやBitTorrent が有名だけど、いろんなゲームで
組み込まれててたり、縁の下で力持ってる。
LinuxはもうPython無しが苦行なレベル。

514:デフォルトの名無しさん
09/10/09 23:28:19
LinuxはPerlとPythonがほぼ標準で入ってるよね

515:デフォルトの名無しさん
09/10/09 23:47:27
Perlなら大分前から商用含めてUnix系OSにはデフォで入ってる気がする
Pythonはさすがにそこまででもない

516:デフォルトの名無しさん
09/10/10 00:33:09
>>506
tcl

517:デフォルトの名無しさん
09/10/10 01:10:38
メジャーなディストリで、Python無しでもインストールできるのってDebianくらいじゃね？

518:デフォルトの名無しさん
09/10/10 01:13:22
う、うん……(´・ω・｀)

519:デフォルトの名無しさん
09/10/10 02:42:36
windowsに標準搭載されれば爆発的にヒットする？

520:デフォルトの名無しさん
09/10/10 03:12:15
WSHが爆発的ヒットしてないのを考慮するとおそらくヒットしないだろうな。。

521:デフォルトの名無しさん
09/10/10 03:19:20
PowerShell!!

522:デフォルトの名無しさん
09/10/10 03:45:06
会社で買ったHPのWindows PCにこっそり入ってた＞Python
なにに使ってるんだ？

523:デフォルトの名無しさん
09/10/10 03:49:10
Thinkpad X200 にも入ってるぞ
C:\Program Files\Common Files\Lenovo\Python24

ほんと、OSに標準搭載にしたらいいのにな。
でも、WinXPみたいに長寿命なWindowsが出ると、ずっと古いPythonに対応しないと
いけないのが面倒そうだ。

524:デフォルトの名無しさん
09/10/10 03:59:08
MSが搭載したらIronPython

525:デフォルトの名無しさん
09/10/10 16:40:53
Macが標準でインストールされているのはRubyだっけか？確か

526:デフォルトの名無しさん
09/10/10 17:08:34
>>525
日本語大丈夫か・・・？
Macにも標準でPython入ってるよ。wxPythonとかまで入ってたはず。

527:デフォルトの名無しさん
09/10/10 17:57:15
すのうれぱーどにて

$ /usr/bin/python --version
Python 2.6.1
$ /usr/bin/php -v
PHP 5.3.0 (cli) (built: Jul 19 2009 00:34:29)
<略>
$ /usr/bin/ruby -v
ruby 1.8.7 (2008-08-11 patchlevel 72) [universal-darwin10.0]
$ /usr/bin/perl -v

This is perl, v5.10.0 built for darwin-thread-multi-2level
<略>

$ which wxPerl wxPython wxRuby
/usr/bin/wxPerl
wxPython not found
wxRuby not found

528:デフォルトの名無しさん
09/10/10 18:38:41
>>514-515
うに系でPython使うのはGUIの小物ツールに多い気がする
設定ファイル弄るツールとかに多くね？
んだから玄人向けの環境ほど見ないが、簡単に使える系の環境だと多そうだ

529:デフォルトの名無しさん
09/10/10 18:41:10
>>528
yumとか、iotopとか、コマンドラインツールもPython系大量

530:デフォルトの名無しさん
09/10/10 19:39:14
　 |￣￣￣￣￣￣￣|
　 |　次でボケて！　|
　 |＿＿＿＿＿＿＿|
　.. 　. ﾊ,,ﾊ ||　　　　.　　　　　　 .
　　　( ﾟωﾟ)||　　　　　.
　　　/　づΦ

531:デフォルトの名無しさん
09/10/10 20:26:11
>>1
> 最強のＬＬ＝軽量プログラム言語は、どれよ？
>
> エントリーは、Perl、PHP、Python、Ruby、JavaScript・・・
> さあ、死ぬまで語りやがれ！！！

コンパイルして EXE ファイル作れるのは、どれですか？

532:デフォルトの名無しさん
09/10/10 20:28:49
>>531
貴方がコンパイラさえ書いてしまえばどの言語でも可能です。

533:デフォルトの名無しさん
09/10/10 20:34:37
>>532
スミマセン
いまからどれ学ぼうか考えてる初心者なんですが、直ぐにEXEファイル作れるのは、どれですか？

534:デフォルトの名無しさん
09/10/10 20:43:56
>>533
exeファイルを作るのにコンパイラが必要だと思っているようだが、
hspみたいにインタープリタとスクリプトをセットにしてexeを生成できるパターンもある。
pythonとか。

535:デフォルトの名無しさん
09/10/10 20:47:10
hspって何だか意味もわからない厨房ですが、pythonならオケってことですね

536:デフォルトの名無しさん
09/10/10 20:52:39
perlでもrubyでもできるよ

537:デフォルトの名無しさん
09/10/10 20:54:29
なんか気になってググってたらどの言語でもexeに変換できそうな気がしてきたｗ

538:デフォルトの名無しさん
09/10/10 20:56:39
>>537
Perlで昔からできてたんだから、後発の言語のコミュニティが似たようなものを作らないはずがない

539:デフォルトの名無しさん
09/10/10 20:59:37
目的はパスワード含んだソースの隠匿です
ダンプしたら中身が見えちゃうニセモノのＥＸＥじゃダメです

540:デフォルトの名無しさん
09/10/10 21:04:06
EXEにしても中身が見えるモノなんだが。

541:デフォルトの名無しさん
09/10/10 21:06:42
>>539
実際にEXEの中身見たことないだろ?

542:デフォルトの名無しさん
09/10/10 21:13:08
Zend Guard でも買え。

543:デフォルトの名無しさん
09/10/10 21:14:33
なでしこのＥＸＥは、中身見るとそのままスクリプト見えます！
始めはVBSでスクリプトをエンコードしたら、簡単にデコード出来てしまいました、容易に見られちゃう

いま色々と調べてみたら、アイロンpythonでEXE作れそうなので、それを試してみます

544:デフォルトの名無しさん
09/10/10 21:19:41
なんかちょっと勉強になったわ

545:デフォルトの名無しさん
09/10/10 21:53:51
ソースの隠蔽が可能な言語ってC/C++以前の年代の言語だけなのかな。

546:デフォルトの名無しさん
09/10/10 22:21:09
パスワード含んだソース
というのを何とかしたほうがいいかも

547:デフォルトの名無しさん
09/10/10 22:23:49
インタプリタ言語から実行可能ファイルを作り出す簡単な方法として
対象スクリプトを起動するためのインタプリタと一体化したファイル
にする、という方法を選んだだけで、VMコードやネイティブコードを
吐くようになってればCと同程度の隠蔽は可能。単にそういう方法を
採用しなかったというだけ。

実行時に決まる部分が多い言語だとなかなか難しいところもあるがな。

548:デフォルトの名無しさん
09/10/10 22:32:29
C/C++の年代ってまだ終わってないぜ

549:デフォルトの名無しさん
09/10/10 22:33:25
Access で作ったパスワード掛けた業務データベースのフォーム入力を従業員にさせたいのですが
パスワード解ると、DAOで接続してテーブルデータ全て見られちゃいますので
パスワード知らせずに、パスワード掛かったAccessアプリをスクリプトで起動させたいのです

始めはVBSで起動スクリプト組んでエンコードしましたが、簡単にデコードされちゃう事が解りました
次にVBでEXE作って一応解決しました

今風なスクリプト言語を新たに学ぼうと思い、どうせなら同じ用途にも使えるもの選ぼうと考えました
先日RCがリリースされたPowerShell2.0を色々と弄って見ましたが、ソースの隠匿は無理のようでした

550:デフォルトの名無しさん
09/10/10 22:49:10
悪い事は言わんから素人がそういうヘンテコな実装をするのはヤめといた方がいい。

マトモなエンジニアにそういうシステム全体から設計してもらえ。

551:デフォルトの名無しさん
09/10/10 23:07:57
Accessねえ…

552:デフォルトの名無しさん
09/10/11 09:18:28
Access自体が隠蔽を前提にしてないからなあ…

553:デフォルトの名無しさん
09/10/11 11:31:12
>>549
パスワードによる情報保護や複数人でのデータアクセスの場合、普通はRDBMSを用いて実装する。

Accessはフロントエンドしては優秀なツールだと思うが>>549の利用方法はヘンテコと言うか
パスワードをアプリに埋め込んだ場合、パスワードがデコードされる可能性は常に０ではない。

バカにするワケではないが、Accessで済む程度の業務データなんざ、ゴミみたいなモノだろうから
妙な小技使わない方がマシだな。

つか、そういうのはOSのアクセス権でやっとけば済む話じゃないのか？
根本的な物事の解決方法がイカれている印象。

554:デフォルトの名無しさん
09/10/11 11:54:19
つか、んなもん使ってる業務あるんだｗ

555:デフォルトの名無しさん
09/10/11 12:34:03
AccessのVBA部分にパスワード掛けるってのはダメなの？

556:デフォルトの名無しさん
09/10/11 12:34:31
Accessでももう少しマシなアクセス権管理できなかったか

557:デフォルトの名無しさん
09/10/11 12:40:40
アクセスできるからAccessなのにアクセスできないAccessなんかNon-Accessだろ。

558:デフォルトの名無しさん
09/10/11 12:57:28
いやそういうのはいい。

559:デフォルトの名無しさん
09/10/11 14:02:26
mde

560:デフォルトの名無しさん
09/10/11 16:34:35
どうしてこうなった

561:デフォルトの名無しさん
09/10/11 19:38:20
>>557
俺は評価する

562:デフォルトの名無しさん
09/10/11 22:10:49
>>527

wxPython は独立したコマンドじゃくてスクリプトに取り込むモジュールだ。今のOSXには最初から入ってる。
wxRuby も似たような感じだろう。
Perlの場合は wxPerlっていう別コマンドでないと実行できないんだな。

563:デフォルトの名無しさん
09/10/12 20:11:45
だからperlで十分だっての

564:デフォルトの名無しさん
09/10/12 21:39:29
PHP、割りと嫌いじゃない

565:デフォルトの名無しさん
09/10/12 23:09:59
俺も。

というかC使いとかの人は一番慣れやすい。
PHP使いはウェブPHPで、他はC/C++でとか両刀的な人が多いけど
Ruby/Python使いは割となんでもこれ一つでやる、って人が多いな。

566:デフォルトの名無しさん
09/10/12 23:26:20
Ruby、Python、どっちが日本語対応が良いの？

567:デフォルトの名無しさん
09/10/12 23:36:16
>>565
それはPHPがWeb以外にむいていないから。
まあ真のPHP厨はなんでもPHPでやろうとするけど。

568:デフォルトの名無しさん
09/10/12 23:37:17
>>563
十分って言い方だと、Perlは劣っている前提みたいにならないか？

569:デフォルトの名無しさん
09/10/12 23:38:18
>>566
Python

570:デフォルトの名無しさん
09/10/12 23:39:17
Perlは劣ってるっての

571:デフォルトの名無しさん
09/10/12 23:43:06
そういうことにしたいのですね。

572:デフォルトの名無しさん
09/10/12 23:59:44
そういうこと

573:デフォルトの名無しさん
09/10/13 08:00:41
>>566
Ruby

Pythonのソフトはいつもマルチバイトがらみでトラブル起こす。

574:デフォルトの名無しさん
09/10/13 08:05:21
そうでもない。
Pythonでトラブルが起きるのはプログラマが正しい使い方を分かってないから。
（日本では少ないが欧米だとそれなりに経験のあるプログラマでもバイト列と文字列の区別のついていない人が結構いる）

少し前だったが、俺が各言語でのファイルシステム関連の多言語対応状況を調べたときはPyhtonが一番よくできていたと思う。
次点でrubyだったがUnicodeのファイル名の扱いに若干難があった。PHPとPerlはもはや論外。

575:デフォルトの名無しさん
09/10/13 08:11:34
欧米というか特にアメリカ人な。
本当にZの後に文字がないと思ってるんじゃないかって連中が存在する

576:デフォルトの名無しさん
09/10/13 08:17:21
Pythonの「暗黙に失敗するよりも明示的にエラーになるほうがいい」というルールが
結果的に >>573 みたいな印象を受けている。
UnicodeEncodeError, UnicodeDecodeError はPythonで頻繁に見る
ことになるエラーだけど、文字コードに関する設計ポリシーを持ったときにこのエラーは
ポリシー違反している箇所を報告してくれる頼もしい見方になる。

中途半端にうまく動いていくれる代わりに、ShiftJISのファイルの中にUTF-8が混じる
ことがあるのに比べるとPythonの方が安心できる。

577:デフォルトの名無しさん
09/10/13 09:18:33
>>574
なんでPerl論外なん？

578:デフォルトの名無しさん
09/10/13 10:30:26
>>577
(少なくとも)ActivePerlがファイルを開く際にCreateFileAをうちぎめで使ってるので移植性を考えると避けたい。
ファイル名として与える文字列にUTF-8フラグ立てても変わらない。カスすぎる

ちなみに、PHPはファイル名を文字列と見なしていないので、
自分でファイル名をShifit_JISとかにエンコードする必要がある。
もはやウンコのレベル

579:デフォルトの名無しさん
09/10/13 12:33:10
>>566
Rubyい一票

580:デフォルトの名無しさん
09/10/13 13:21:09
>>578
Windows限定で、日本語ファイル名限定かよ。

581:デフォルトの名無しさん
09/10/13 14:04:04
>>579
RubyはPythonみたいにCreateFileWを使ってくれるん？
>>580
日本語というか、Unicodeファイル名だな。
W系APIを使っている=Windowsでの動作がきちんと考えられていると
判断されても仕方ない。

582:デフォルトの名無しさん
09/10/13 15:41:36
>>573
>Pythonのソフトはいつもマルチバイトがらみでトラブル起こす。

それは誤解

漏れもpython初心者の頃はなんだこりゃと思っていたが
理由がわかるとちゃんと使えるしよくできてる

583:デフォルトの名無しさん
09/10/13 15:45:37
windows のコマンドプロンプト
はやく UTF-8 に対応してくれないかなぁ

584:デフォルトの名無しさん
09/10/13 15:47:55
>>583
一応 chcp 65001 したら utf-8 になるけど、問題が多すぎて使い物にならないね。
WriteConsoleW を使って utf-16 を出力できるようにするのが一番いいんだろうけど、
あまりにも標準入出力の概念からずれるから、sys.stdout.write()を置き換えるのは
難しい。結局、 pywin32 の console を使うのが正解だと思う。

585:デフォルトの名無しさん
09/10/13 18:48:59
>>584
標準入出力にUTF16はよくないのでは。
ASCII互換じゃないし、表現できない
文字があるでしょ。

586:デフォルトの名無しさん
09/10/13 19:08:47
>>585
WindowsのW系APIが受け取る文字列がUTF-16だから、UTF-16で表現できない
文字列はそもそもWindowsが表示したりファイル名に使ったりできない文字列だよ？

587:デフォルトの名無しさん
09/10/13 21:10:08
perlは、windowsで使わない！！
それでよし！

588:デフォルトの名無しさん
09/10/13 21:43:11
そーだ。perl以外は、いらん！
マルチバイト処理もEncode覚えれば不自由ないし。

589:デフォルトの名無しさん
09/10/13 22:24:16
>>583
PowerShell標準で付くんだから、必要ないだろ
ISEもあるんだし

590:デフォルトの名無しさん
09/10/13 22:24:43
使いたいの使えばいいじゃないか

じゃ話が終わるので、

負荷を心配しないである程度大きめなものを、急いで作りたいなら、Railsが使えるRuby
負荷を気にしたり、高速に作りたいなら、Perl
「俺Python使い」と、かっこつけたいなら、Python
外注に安く作らせたいなら、PHP

591:デフォルトの名無しさん
09/10/13 22:26:47
外注に安く作らせるならPHP。
それ以外は全部PythonとC。

592:デフォルトの名無しさん
09/10/13 22:48:33
>>582
誤解じゃねーよｗ

俺がいいたいのは問題起こすPython製アプリの話と、それが原因となっている言語の問題。
プログラマの心遣いとかの話じゃない。

逆に、.NETアプリはマルチバイトで問題起こすの見たことない。
UNICODE前提のせいかしらんが・・・（.NETの仕様はあまり知らんので俺に突っ込みされても困るけど）

>>584
あー、そういや、>>573でRubyって書いたけど、コマンドプロンプトと文字コードの相性最悪なの忘れてたわｗ
UTF-8でRSpecとautotest(autospec)でまともにテストもできないｗｗｗ
俺は出力時にSJISに変換してるｗ

>>589
PowerShellだと文字コード周り解決するのか？ちょっと入れてみるか

593:デフォルトの名無しさん
09/10/13 22:59:21
>>592
> プログラマの心遣いとかの話じゃない。
プログラマの心遣いの問題ですね
CでUnicode対応アプリも書ければ、いわゆる「駄目文字」で問題を起こすアプリも書けるのと同じ
ただ、Javaや.NETのようにテキスト＝Unicodeと割り切ったほうが
心がけの悪いプログラマでも問題を起こしにくいのは確かで
Pythonも3.xからはそうなりました

594:デフォルトの名無しさん
09/10/14 01:11:57
Java/C#
　　内部エンコーディングUTF16で固定。入出力時に外部エンコーディング指定して必ず変換。
Python
　　uを付けた文字列はUTF16固定。付けないと任意？設定だっけ？内部的に混在するので扱い注意。
Perl
　　Cと同じで任意だっけ？wideはなしだっけ？

こんなんだっけ？もう面倒だし、Java/C#式の内部固定がぐちゃぐちゃにならなくて一番いい気がするけどどうなん？

595:デフォルトの名無しさん
09/10/14 02:03:55
>Python
>　　uを付けた文字列はUTF16固定。付けないと任意？設定だっけ？内部的に混在するので扱い注意。

>付けないと任意？設定だっけ？
ソースの先頭2行目に
# -*- coding: utf-8 -*-
などと書くと
そのコードでエンコードされたバイト列になる

>内部的に混在するので扱い注意
混在っつっても明示的にuが付いてる訳でそこは平気
どっちかというとprintでuの付いている文字列を出力すると
暗黙にデフォルトのエンコードに変換されてコンソールに出力されるが
pythonに慣れずに(perlとかと同じ感覚で)ごっちゃにしたバイト列の方をprintすると
よくここでエンコードエラー/デコードエラーになる
つまり文字列とバイト列の違いは意識する必要がある

あとpython3で改善されてるはず

596:デフォルトの名無しさん
09/10/14 02:07:00
>>595
>あとpython3で改善されてるはず

だからといって 2.4.x - 2.6.x が劣ってる訳じゃないけどね

2.3.x 以下は糞

597:デフォルトの名無しさん
09/10/14 03:58:10
>>593
もしかして、プログラマ性善説主義者か？お前ｗ

そんなのは言語仕様のレベルで都合のいい方向に傾けておくべきこと。

プログラマーなんて信用しちゃいけないよ。
あのリーナス・トーバルズすら、エンコーディングに無関心なのか git がマルチバイトを考慮しない仕様(バイナリとして扱う)

心遣いの問題とか言いいながら、永遠にマルチバイト対応がクソなC言語製やPythonアプリでも使ってろや

598:デフォルトの名無しさん
09/10/14 04:01:39
>永遠にマルチバイト対応がクソな

kwsk

599:デフォルトの名無しさん
09/10/14 08:45:26
597は言語がサポートしてないとなにもできない厨。

600:デフォルトの名無しさん
09/10/14 09:19:42
いや、gitは確かにウンコ。
これはリーナスのおっさんが新しい方式について行けない老害だったから。

hgもウニコードの扱いが糞で、これもプログラマのセンスがなさ過ぎる。
Python3の文字列にバイナリとしてアクセスする方法をよこせなどと言っていた。

一方bzrは同じPythonだが上二つと比べて格段にエンコーディング周りのポリシーが優れてる。

601:デフォルトの名無しさん
09/10/14 09:29:19
>>594
uがついたのが文字列で、ついてないのはバイト列。
世の中には、どうしてかこれを区別できない連中が多すぎる。

602:デフォルトの名無しさん
09/10/14 09:38:09
uがついてるのはリテラルのときじゃね？
str = u"ahoaho"
ってしたらstrがなにかわかんなくね？

603:デフォルトの名無しさん
09/10/14 09:41:41
正直スクリプトはこの辺がごちゃごちゃしすぎてて全然LLじゃねー
Javaのがはるかに楽

604:デフォルトの名無しさん
09/10/14 09:47:00
>>602
その場合strの値はunicode型で、uをつけなかったときはstr型になる。
型が違うと当然、相互の演算に制約を受ける。

605:デフォルトの名無しさん
09/10/14 09:50:15
Pythonの型付けは強い方だから、perlやPHPに慣れてる人だと引っかかるのかもしれないね

606:デフォルトの名無しさん
09/10/14 10:09:01
JavaはcharがUCS2だと割り切っただけだろ。
サロゲートペアで泣きを入れることになっても知らんぞ。

607:デフォルトの名無しさん
09/10/14 10:11:23
>>606
ユニコード操作するときってサロゲートペアはあんまり気にならないものだよ。
UTF32でも結局のところ合成文字を考えないといけなくてコード単位ごとに処理できない

608:デフォルトの名無しさん
09/10/14 10:17:29
Pythonは2.6でも from __future__ import unicode_literals したら、
"foo" が unicode になって、代わりにバイト列は b"foo" しないといけないようになるよ。

次ページ