08/08/04 10:31:21
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
356:デフォルトの名無しさん
08/08/04 10:32:41
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
357:デフォルトの名無しさん
08/08/04 10:32:41
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
358:デフォルトの名無しさん
08/08/04 10:32:41
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
359:デフォルトの名無しさん
08/08/04 10:34:09
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
360:デフォルトの名無しさん
08/08/04 10:34:09
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
361:デフォルトの名無しさん
08/08/04 10:34:10
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
362:デフォルトの名無しさん
08/08/04 10:35:36
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
363:デフォルトの名無しさん
08/08/04 10:35:36
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
364:デフォルトの名無しさん
08/08/04 10:35:37
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
365:デフォルトの名無しさん
08/08/04 10:37:03
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
366:デフォルトの名無しさん
08/08/04 10:37:04
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
367:デフォルトの名無しさん
08/08/04 10:38:30
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
368:デフォルトの名無しさん
08/08/04 10:38:30
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
369:デフォルトの名無しさん
08/08/04 10:38:31
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
370:デフォルトの名無しさん
08/08/04 12:47:29
アンチ板への妨害って信者ってことですか。
といってみる。
371:デフォルトの名無しさん
08/08/05 15:04:22
Python恨まれすぎ
372:デフォルトの名無しさん
08/08/05 15:14:15
Ruby厨房の仕業ですか
373:デフォルトの名無しさん
08/08/05 15:38:04
Pythonスレの荒らし、俺の予想
2007年 6月 ２ちゃんねるを本格的に始める
6月 過去ログが見れないことに腹を立て●を購入
12月 VIP初体験
2008年 8月3日 IDが簡単に変更できることを知る
同日 東方シリーズ総合スレッドを荒らす
8月4日 マクロを使って本格的に荒らす
現在 ム板で個人的に気に入らないPythonをスレを潰しにかかる
374:デフォルトの名無しさん
08/08/07 15:52:40
ちょっと実践Python立ち読みしてくる
375:デフォルトの名無しさん
08/08/19 00:23:19
いまさらで良いので誰か
Pythonを256倍使いこなす本 ～愛多憎生編～
とか書いてよ。
376:デフォルトの名無しさん
08/08/19 00:51:01
256倍シリーズはどうもあの真ん中に大きな字で何度も強調するスタイルが嫌だ
377:デフォルトの名無しさん
08/08/20 12:57:35
あれがなかったら256本じゃないだろ
378:デフォルトの名無しさん
08/08/22 09:34:38
あれを抜いて2.56倍本を...
379:デフォルトの名無しさん
08/08/23 15:45:53
256倍シリーズはC以外おもしろくなかった
380:デフォルトの名無しさん
08/08/23 16:23:42
AWK本は名著
381:デフォルトの名無しさん
08/08/28 02:03:09
うむ
382:デフォルトの名無しさん
08/10/26 20:28:40
アンチスレ平和すぎだろ
383:デフォルトの名無しさん
08/12/08 19:13:47
Time flies like an arrow.
384:デフォルトの名無しさん
08/12/24 16:09:12
>>382
安置
385:デフォルトの名無しさん
08/12/24 20:46:38
３．０が思ったほど遊べなくてガックリ。
互換性をきるなら、もっとババーン、キャーみたいなのやってくれれば良いのに。
386:デフォルトの名無しさん
08/12/24 21:17:49
Python系でも後発Booとか見ると結構いい感じなんだよな
defで匿名関数定義できてPythonのlambdaみたいな制限もねーし
Lispのマクロみたいなノリでメタプログラミングっぽいことも出来るみてーだし
後、Pythonは常にselfとか書かせるぐらいなら、束縛と代入で
:=, =みたいに構文分けるかletとか書かせるようにして欲しかった
ミスに弱いし、global文とかnonlocal文とか場当たり的で醜いよ
387:デフォルトの名無しさん
08/12/25 19:58:12
そうだね
388:デフォルトの名無しさん
09/01/03 22:49:50
Booは名前がなあ
いくら中身が良くても名前だけでやる気が起こらないって恐ろしい
389:デフォルトの名無しさん
09/01/13 00:24:14
どういうやつ？
取り込み中なんで、あとでくわしく
390:デフォルトの名無しさん
09/02/05 17:35:28
取り込みは終わりましたか？
391:デフォルトの名無しさん
09/02/17 15:11:14
:=, =
392:デフォルトの名無しさん
09/03/20 16:57:05
アンチではないけど、
Python ドキュメント(Python ライブラリリファレンス等)が
どうも見難くてたまらん。
393:デフォルトの名無しさん
09/03/20 17:29:31
そうだね
あれじゃ目的のものにたどり着けないよね
394:デフォルトの名無しさん
09/03/20 17:33:56
Pythonのドキュメントは愛がたりない
Rubyみたいなドキュメントになってほしい
395:デフォルトの名無しさん
09/03/20 18:44:16
未完成な「Rubyリファレンスマニュアル刷新計画 chm版」というのを
ダウンロードしてみたけど、Rubyのほうがちゃんと気合い入ってそうだ。
396:デフォルトの名無しさん
09/03/20 18:51:11
>>392
URLﾘﾝｸ(docs.python.org)
2.6系からドキュメントシステムが変わりました…
Json のindexを構築して検索してるそうな…
sphinx + Pygments とかでぐぐると嬉しい
URLﾘﾝｸ(sphinx.pocoo.org)
397:デフォルトの名無しさん
09/03/20 19:46:37
左側の無駄なスペース無くして欲しいんだが
それにフォントもでかくなってて読みにくい
使い勝手は良くなったのかも知れないが
生理的に受け付けなくなりつつある
398:デフォルトの名無しさん
09/03/20 19:48:17
もっとサクサク動くようにするべきだと思う
399:デフォルトの名無しさん
09/03/20 23:12:49
オライリー本のヘビの絵がきもい。
400:デフォルトの名無しさん
09/03/20 23:23:39
Twisted本はさらにひどい。
しかしそれはオライリーに文句を言うべき
401:デフォルトの名無しさん
09/03/20 23:38:10
>>397
俺もそれはウザいと思っていたのでスタイルシート弄った
402:デフォルトの名無しさん
09/03/21 00:36:31
前は気軽にプリントアウト出来てたのに
403:デフォルトの名無しさん
09/03/25 05:04:28
>401
こういう時、ユーザスタイルシートって有難いな
404:デフォルトの名無しさん
09/04/10 08:27:17
>>397
>左側の無駄なスペース
目次用のエリアじゃないのか？
405:デフォルトの名無しさん
09/04/29 06:08:22
pythonは速いと聞いたので覚えようと思ったけど文法が訳ワカメで難しすぎて無理
もっと、こっからここまでをバシっと決めてくれないかなぁ
406:デフォルトの名無しさん
09/04/29 12:54:20
Cにしとけ
407:デフォルトの名無しさん
09/04/29 19:42:51
早いのがいいならFORTRANだろ
408:デフォルトの名無しさん
09/05/02 01:48:08
>>405
Pythonで文法がわかりにくいというのは初めて聞いた
具体的にどこがわかりにくいのだろうか
409:デフォルトの名無しさん
09/05/02 12:18:35
endがなくてキモい
410:デフォルトの名無しさん
09/05/02 12:49:56
Pascal信者乙
411:デフォルトの名無しさん
09/05/02 18:43:36
Pascal 信者であれば begin, end が無いという
Ruby 信者でしょ
412:デフォルトの名無しさん
09/05/05 22:06:13
行の開始位置が構造に関わるとか
COBOLかFORTRAN並みに古すぎとか
思ってたけど慣れるとなんでもない
endの方がきもい
漏れはRubyでも{}使う派なんだけど
Rubyは{}じゃだめでdo～endでしか書けないケースが結構ありすぎ
413:デフォルトの名無しさん
09/05/05 23:27:06
>>412
Python型の行頭位置の規則（オフサイドルール）は、
言語の系譜としては現代的なものだぞ。他にHaskellとか。
414:デフォルトの名無しさん
09/05/27 11:52:20
> Rubyは{}じゃだめでdo～endでしか書けないケースが結構ありすぎ
逆じゃないか？
Rubyの見栄え上do～endのほうが良いなぁと思うのに、{}じゃないと書けないケースが多いと思う
415:デフォルトの名無しさん
09/05/27 11:58:10
多分個人のコーディングの癖（好むメソッドの組み合わせパターン）で
違ってくると思う。
416:デフォルトの名無しさん
09/05/27 13:38:02
>>412 書いたの漏れなんだが
なんであんなこと書いたのか
もう思い出せない orz
417:デフォルトの名無しさん
09/05/27 17:06:12
>>409
end = Noneと書けばendが書けるよ
418:デフォルトの名無しさん
09/05/27 18:47:44
pass で閉じてる漏れは勝ち組み
419:デフォルトの名無しさん
09/05/28 10:06:56
>>414
foo hoge {
}
でfooにブロックをつけたいとかいうパターンだろう。
rake絡みなんかでよくある質問だな。
420:デフォルトの名無しさん
09/05/28 19:01:04
pythonはforが大杉。
421:デフォルトの名無しさん
09/05/28 19:29:27
安置というより無知を曝すスレだな
422:デフォルトの名無しさん
09/06/08 03:20:10
pythonスレはアforが大杉
423:デフォルトの名無しさん
09/06/08 03:21:36
自愛するべき
424:デフォルトの名無しさん
09/06/08 11:45:51
>>420
for で充分だから ブロック構文いらない。
Ruby厨はよく Pythonには○○が無いって叩くけど、大抵そういう機能は
Python-Idea ML で必要・不要が議論された結果不要と判断されている
ので、その機能が無くても同じ生産性をPythonは既に実現している。
425:デフォルトの名無しさん
09/06/08 13:22:44
for多すぎって[ ]の中じゃないの？
426:デフォルトの名無しさん
09/06/08 20:46:12
>>424
そうでもないだろ。
Pythonの配列操作がRubyと比べて面倒くさい
URLﾘﾝｸ(d.hatena.ne.jp)
それよりPythonはsuperのキモさをなんとかしてくれんかいのう。
なんでsuper()に親クラス名を指定しなきゃいかんの？ba
427:デフォルトの名無しさん
09/06/08 21:00:08
>>426
multi-inheritence dakara
428:デフォルトの名無しさん
09/06/08 21:06:58
>>427
多重継承はまったく関係ないよ。
つうかなんで多重継承が関係してくんの？
429:デフォルトの名無しさん
09/06/08 21:07:27
>>426
> Pythonの配列操作がRubyと比べて面倒くさい
> URLﾘﾝｸ(d.hatena.ne.jp)
つ '-'.join(["%s"%(x) for x in sorted(a, reverse=True)])
430:デフォルトの名無しさん
09/06/08 21:08:35
私Ruby厨だけどsuperに関しては
superとsuper()で引数が違ってくるRubyの方がキモイと思う
431:デフォルトの名無しさん
09/06/08 21:13:13
>>426
> なんでsuper()に親クラス名を指定しなきゃいかんの？ba
Smalltalk系のようにsuperがcaller側のmethodのbindに依存するほうが
よほど言語設計として汚ないと思うが？
432:デフォルトの名無しさん
09/06/08 22:07:31
>>431
なんで汚いん?
「親クラス」という抽象的な表現ができず、具体的なクラス名をいちいち書かないといけないことは汚くないの？
433:デフォルトの名無しさん
09/06/08 22:15:57
明示的なだけで汚くはないだろ
多重継承したらどの親クラスのメソッド呼ぶのかさえ曖昧になるし
Python3からは引数省略してsuper().methできるらしいけど
434:デフォルトの名無しさん
09/06/08 22:30:34
>>433
>明示的なだけで汚くはないだろ
明示しなきゃいけないんだから汚いだろー
なんで抽象化されてないのさ
>多重継承したらどの親クラスのメソッド呼ぶのかさえ曖昧になるし
は？そんなのふつうのメソッド呼び出しでも一緒じゃん
class A(object):
def f(self): print 'A'
class B(object):
def f(self): print 'B'
class X(A, B):
def g(self):
self.f() # どの親クラスのメソッド呼ぶのか曖昧なの？ねえPythonってそうなの？
ふつうのメソッド呼び出しで行なっているのと同じルールを使って、親クラスのメソッドを呼べばいいだけじゃん。
もしPythonが本当に『どの親クラスのメソッド呼ぶのかさえ曖昧になる』んだったら、
もうsuper関係なしに、オブジェクト指向言語として失格だろwwwww
>Python3からは引数省略してsuper().methできるらしいけど
やっぱり多重継承関係ないじゃないかwwwww
>>433は２行目で書いたことを３行目で忘れてるおばかさんーwwwww
435:デフォルトの名無しさん
09/06/09 00:19:05
ようやくアンチスレらしくなって妙にうれしい
436:デフォルトの名無しさん
09/06/09 01:58:52
>>434
そうだね、だから Python 3.0 では super() に self を明示しなくても良くなるよ。
今の Python は、 Python 2.2 までの古いクラスと新しいクラスが混在していて、
後方互換性の為には明示的にクラス名を書かないといけないの。
437:デフォルトの名無しさん
09/06/09 02:16:01
古いクラスと新しいクラスが混在って要・不要が議論されたあげくにそれか？
自慢げに語ることじゃないだろ。 よほど言語設計として汚ないと思うが？
438:デフォルトの名無しさん
09/06/09 02:22:03
2.xまで混在
3は新だけ
439:デフォルトの名無しさん
09/06/09 03:15:41
>>437
Rubyとちがって、過去の資産を大切にするからね。
後方互換性を切る Py3k も数年がかりのプロジェクトになる。
新クラスは、必要と判断されたから導入された。でも、後方互換性の為に
旧クラスは残されている。
ruby の メソッドチェーンやブロック構文は、Pythonに導入しても「一部の人が
気持ちいい」とか「ときどき数タイプ減らせる」程度の効果しか認められないから
Pythonには導入されない。
440:デフォルトの名無しさん
09/06/09 03:20:53
>>426
> Pythonの配列操作がRubyと比べて面倒くさい
> URLﾘﾝｸ(d.hatena.ne.jp)
メソッドチェーンになれたRubyistがメソッドチェーンを無いことを反射的に
批判しているだけだろ。
文を分けないで関数を無制限にゴチャゴチャ繋げるのはPythonicではない。
一息に書いて良いのは内包表記で簡潔に書ける範囲までで、それ以上は
文を分けるべき。文を分けたることによって数タイプ増えるが、その分可視性は
向上するので、トータルの生産性に大きな差は無い。それなら、すっきりした
書き方だけを使うのが Pythonic way.
441:デフォルトの名無しさん
09/06/09 04:00:06
久々に伸びてると思ったらなんじゃこりゃ
442:デフォルトの名無しさん
09/06/09 04:41:11
>>432
同じ表現式の意味がバインドされているクラスによって変化するのは美しくないだろ。
言語仕様上の透明性を求めるか、表現式としての簡便さを求めるかの言語仕様上のトレードオフでしょ。
443:デフォルトの名無しさん
09/06/09 04:43:34
>>426
> Pythonの配列操作がRubyと比べて面倒くさい
> URLﾘﾝｸ(d.hatena.ne.jp)
単に初学者が前に習った言語の作法にひきずられて
今学んでいる言語の流儀に逆らってるだけに見える。
444:デフォルトの名無しさん
09/06/09 05:03:16
rubyやJavaのメソッドチェーン使うときにいつも気になるのは
途中でメソッドの戻り値がぬるぽになるんじゃないかってところ
だからpythonで文を分けて毎回if not hogeしている漏れは勝ち組
445:デフォルトの名無しさん
09/06/09 05:13:49
>なんか今更この記事にコメントが付きだしたのですが、どこかで紹介されたのでしょうか?
笑える
>>426
> Pythonの配列操作がRubyと比べて面倒くさい
> URLﾘﾝｸ(d.hatena.ne.jp)
ruby
a.sort().reverse().map{|x| x.to_s}.join('-')
python
'-'.join(map(lambda x:str(x), reversed(sorted(a))))
'-'.join(str(x) for x in reveresed(sorted(a)))
'-'.join('%s'%(x) for x in sorted(a, reverse=True))
確かpythonって「やりかたはひとつ」を売りにしてなかったっけ？
446:デフォルトの名無しさん
09/06/09 07:12:26
>>436
なるほど、それが理由なのか。
じゃあ最初にオブジェクト指向機能を導入した時の設計が間違ってたんだな。
とりあえず「多重継承したらどの親クラスのメソッド呼ぶのかさえ曖昧になる」と言いはるバカは消えろwww
>>439
>Rubyとちがって、過去の資産を大切にするからね。
ちーがーうー、最初の設計が間違っていたから仕方なく過去を引きずっているだけwww
それを「過去の資産を大切に」とかバカまるだしwww
ほんとに大切にするなら3.0でも互換性をとっとけwww
>>442
>同じ表現式の意味がバインドされているクラスによって変化するのは美しくないだろ。
ほんとにそう思う？ほんとにそう思うなら、親クラス名が省略できるようになった3.0は美しくないの？
442にとっては3.0の仕様が美しくないそうだよwwww またバカ丸出しwwwwww
Pythonistaは442みたいなのをだまらせとけやwww 身内の恥さらしだぞwwwwww
447:デフォルトの名無しさん
09/06/09 07:45:28
雑草が増えたな
448:デフォルトの名無しさん
09/06/09 08:14:19
>>445
>python
>'-'.join(map(lambda x:str(x), reversed(sorted(a))))
>'-'.join(str(x) for x in reveresed(sorted(a)))
>'-'.join('%s'%(x) for x in sorted(a, reverse=True))
>
>確かpythonって「やりかたはひとつ」を売りにしてなかったっけ？
厳密にひとつ、というわけじゃなくて、だいたい一つ、ぐらいの意味でいいんじゃない？
これくらいだったら十分許容範囲だろ。許してやれよ。
> ruby
> a.sort().reverse().map{|x| x.to_s}.join('-')
これは各々の処理が左から右にきれいに流れるから読みやすいんだよね。
Pythonのは関数呼び出しが入れ子になっているからわかりずらい。
Python狂信者はこの事実を認めようとしないだろうけど。
>>440
>一息に書いて良いのは内包表記で簡潔に書ける範囲までで、それ以上は
>文を分けるべき。
それはPython限定の話だよね? 一息に書きにくい言語はそうすべきだけど、
一息にかける言語だったらそんなことに縛られる必要はまるでない。
>> 443
> 単に初学者が前に習った言語の作法にひきずられて
> 今学んでいる言語の流儀に逆らってるだけに見える。
こういうやつがいるかぎりは、争いはいつまでたっても終わんないだろうね。
449:デフォルトの名無しさん
09/06/09 08:15:08
ある種の若い男の子にありがちな語り口だよね。
わかるまいわかるまいと頑張りつつ、わからせる気も無い、のっけからの平行線狙いって。
場を味方につけつつ展開しないと、単に「こいつ一人が理解力無いだけ」って判断されて
オシマイなんだけど。
450:デフォルトの名無しさん
09/06/09 08:17:25
one liner書きにくすぎ
インデント氏ね
451:デフォルトの名無しさん
09/06/09 08:47:16
>>448
> > ruby
> > a.sort().reverse().map{|x| x.to_s}.join('-')
>
> これは各々の処理が左から右にきれいに流れるから読みやすいんだよね。
> Pythonのは関数呼び出しが入れ子になっているからわかりずらい。
> Python狂信者はこの事実を認めようとしないだろうけど。
python
'-'.join(["%s"%(x) for x in sorted(a, reverse=True)])
これは全体の処理がトップダウンにきれいに流れるから読みやすいんだよね。
rubyのように処理順にすると最後にならないと全体の仕事がわからずに読み進めなきゃならない。
俺はruby狂信者なんてレッテルを貼ったりしないけど。
452:デフォルトの名無しさん
09/06/09 09:15:13
>>445
その例だと、一番目は lambda が不要で
'-'.join(map(str, sorted(a, reverse=True))) # もしくは itertools.imap
二番目は reversed が一つ余計で
'-'.join(str(x) for x in sorted(a, reverse=True))
三番目の % 記法を無理やり使うのは無いな。少なくとも (x,) としないと、 x 自体がタプル
だったときに問題が起こる。
453:デフォルトの名無しさん
09/06/09 09:16:30
>>444
確かに、Pythonの一行 = 1文 = 一つの事 という文化は、
例外発生時にスタックトレースを見るとすぐにどこが例外を
出したか特定できるという副次的な効果もあるねw
454:デフォルトの名無しさん
09/06/09 09:24:33
>>448
> > ruby
> > a.sort().reverse().map{|x| x.to_s}.join('-')
>
> これは各々の処理が左から右にきれいに流れるから読みやすいんだよね。
> Pythonのは関数呼び出しが入れ子になっているからわかりずらい。
> Python狂信者はこの事実を認めようとしないだろうけど。
「左から右に」っていうのは Ruby厨がよく言うけど、メソッドチェーンのとき「だけ」
左から右なんだよね。なんで代入は右から左のままなの?代入演算子を => に
すれば、
s = a.sort.reverse
s.map{|x| x.to_s}.join('-')
という風に代入が混じっていても、
a.sort.reverse=>s.map{|x| x.to_s}.join('-')
って書けるのにさ。
結局、Matzの「あ、こう書けるとおもしろいんじゃね?」というのに後付けで読みやすい
とか言っちゃってる気がしてならない。
あと、リストの要素を「*文字列として* 連結する」というメソッドがリストのメソッドなのは
どうなんだ? Python の ''.join() の方が、文字列に関する機能は文字列のメソッドという
方が分かり易いし正しいと思うぞ。
455:デフォルトの名無しさん
09/06/09 12:21:12
末尾に!を付けると代入になるとかいいんじゃね
456:デフォルトの名無しさん
09/06/09 12:31:38
>>454
「左から右」が好きなのは最近の人っつかRails厨に多い気がする
(s = a.sort.reverse).map{|x| x.to_s}.join('-')で別に気にならないな
理屈は後付けで結局Matzの思いつきが多いのは然りごもっとも
> あと、リストの要素を「*文字列として* 連結する」というメソッドがリストのメソッドなのは
num.to_sとかの延長で考えると、別にいいんじゃねと思ってる
機能よりは主体がどっちなのかで分けてる感じかな、よくわからんが
457:デフォルトの名無しさん
09/06/09 12:40:48
*リスト*を連結するのがstrのメソッドなのはいいのか？
458:デフォルトの名無しさん
09/06/09 13:06:10
リストの連結（リストをいくつか受け取って連結したリストを返す）メソッドがstrに定義されてる
言語なんてあるのか？
459:デフォルトの名無しさん
09/06/09 14:29:46
>>444
がっ!
460:デフォルトの名無しさん
09/06/09 14:37:02
>>453
それはたまたま副次的な効果が出たんじゃなくて
効果を期待してそのために文を分けてると思ってたｗ
461:デフォルトの名無しさん
09/06/09 14:38:58
> ruby
> a.sort().reverse().map{|x| x.to_s}.join('-')
これ成城に動いてるときはいいんだけど
バグが出たら何が原因か分かりづらいぜ？
462:デフォルトの名無しさん
09/06/09 14:41:05
>>454
>結局、Matzの「あ、こう書けるとおもしろいんじゃね?」というのに後付けで読みやすい
>とか言っちゃってる気がしてならない。
そういう理由だったの？
Smalltalk から影響受けたんだと思ってたお
463:デフォルトの名無しさん
09/06/09 14:42:34
>>457
リスト以外でも、イテレートできればなんでも連結できるよ?
464:デフォルトの名無しさん
09/06/09 14:43:05
>>454
>「左から右に」っていうのは Ruby厨がよく言うけど、メソッドチェーンのとき「だけ」左から右なんだよね。
なんですべてを左から右にしようとしてんの？別に右から左でもいいけどさ、個々の処理がきれいに流れていることが重要なんじゃん。
unixのコマンドラインでパイプを使って処理を連結する感覚と一緒。Pythonとかだとそれがないってだけ。
>なんで代入は右から左のままなの?代入演算子を => にすれば、
>s = a.sort.reverse
>s.map{|x| x.to_s}.join('-')
>という風に代入が混じっていても、
>a.sort.reverse=>s.map{|x| x.to_s}.join('-')
>って書けるのにさ。
そんなふうに書くわけないじゃん。
(s = a.sort.reverse).map{|x| x.to_s}.join('-')
でいいだろ。自分で書いてて気づかないのか？
>結局、Matzの「あ、こう書けるとおもしろいんじゃね?」というのに後付けで読みやすい
>とか言っちゃってる気がしてならない。
いや実際読みやすいだろ。
>あと、リストの要素を「*文字列として* 連結する」というメソッドがリストのメソッドなのはどうなんだ?
連結した結果として文字列以外になんかあるか？joinは*要素を連結して*文字列として返すメソッドなんだから、リストのメソッドで何にもおかしくない。
> Python の ''.join() の方が、文字列に関する機能は文字列のメソッドという方が分かり易いし正しいと思うぞ。
戻り値が文字列だからといって、要素を連結する機能を文字列に関する機能と考えるほうがどうかしてる。
joinはあくまで「要素を連結する」ためのメソッド。リストのメソッドで何が悪い。
>>452
おれもlambda x: str(x) とか書いてた！これはいらないのか！ちょー参考になった。さんくす。
465:デフォルトの名無しさん
09/06/09 14:44:06
>>458
Java
466:デフォルトの名無しさん
09/06/09 14:47:34
python は lisp と謂われる所以ですな
467:デフォルトの名無しさん
09/06/09 14:48:38
>>452
今回はたまたまそれで良かった訳だが
str() 以上に複雑なことさせようとしたら lambda 必要になるよね？
468:デフォルトの名無しさん
09/06/09 14:49:24
理想ばっか語ってても仕方ないよ
469:デフォルトの名無しさん
09/06/09 14:51:33
>>464
例えば、xhtml を動的に生成する場合、
data = [tag.P(t) for t in "foo bar baz".split()]
contents = tag.HR.join(data)
print str(contents)
で、
<p>foo</p>
<hr/>
<p>bar</p>
<hr/>
<p>baz</p>
とか。シーケンシャルな構造で要素をセパレータを挟みながら並べたいってのは
文字列処理にしか出てこないとは限らないだろ。
470:デフォルトの名無しさん
09/06/09 14:53:58
>>467
それ以上に複雑になったら、mapではなくてリスト内包を使う。
リスト内包でもすっきり書けないくらい複雑になったら、ローカルで関数を定義して
それを map する。
Pythonの関数は普通の変数と同じ名前空間に存在しているので扱いが楽。
471:デフォルトの名無しさん
09/06/09 15:01:41
>>464
> (s = a.sort.reverse).map{|x| x.to_s}.join('-')
これ、動作を追おうとすると、 a.sort.reverse までは左から右によんで、
そっからいきなり一番左に行って、代入結果に対してさらに右にとんで
処理しているんだよね?
俺は「左から右」のメソッドチェーンがPythonicな書き方に比べて特に
読みやすいとは思わないけど、もし「左から右に流れるように処理が連結
できる」のが本当に読みやすいのであれば、代入式も代入結果が式の値
なんだから代入結果を右に持っていくべきだよね。
Ruby厨ってRubyこそ正義って思って思考停止してない?
472:デフォルトの名無しさん
09/06/09 15:12:20
pythonのlist.sort(), list.reverse()が処理後のリストを返さない理由を2文字で教えてください。
473:デフォルトの名無しさん
09/06/09 15:15:00
>>471
464ではないし、Ruby触ったことないけど・・・
それは「コンピュータが処理をする順序の話」に寄りすぎちゃってない？
これって、「人間が動作の流れを目で追う話」だよね？
俺が「一人の人間として」コードがやっていることを目で追うとき、
代入というのは「○○に××を代入する」行為であると捉えているから、
このコードは十分「左から右」になってるなぁ。
sにaをソートしてひっくり返したものを代入して、mapしてjoinする、って読む。
474:デフォルトの名無しさん
09/06/09 15:18:08
>>470
mapとリスト内包ってどっちが速いん？
メモリ使用効率は？
475:デフォルトの名無しさん
09/06/09 15:21:14
代入を右から左に「読む」という主張の人は、当然ながら
a = b = c = 10
みたいなコードは、「10をcに代入し、その値をbに代入し・・・」って読み方なんだよね。
俺はそうじゃなくて、「aとbとcに10を代入する」って読む。
この認識が「コンピュータの動き」と異なっていることはわかっているけど、
でも自分が「プログラムの動き」からも離れて強引に左から右に読んでる、とも思わない。
476:デフォルトの名無しさん
09/06/09 15:21:47
>>471
>> (s = a.sort.reverse).map{|x| x.to_s}.join('-')
>これ、動作を追おうとすると、 a.sort.reverse までは左から右によんで、
>そっからいきなり一番左に行って、代入結果に対してさらに右にとんで
>処理しているんだよね?
いや、最初に「(s=」が目に入るからその時点で
脳内スタックに s の代入と s に対する次の
「).map」の準備が出来るから大丈夫
477:デフォルトの名無しさん
09/06/09 15:29:55
Pythonのjoinが文字列のメソッドとなっているのは、単にリストだけでなくタプルや文字列やジェネレータのように
繰り返し可能なものすべてを扱えるようにしているからだよね。
だからほんとは
join(iteratable, separator='')
という関数でよかったんじゃないの？
joinが文字列のメソッドだからすごく違和感があるけど、単なる組み込み関数として存在するなら、別に違和感なし。
join(['a', 'b', 'c'])
join(('a', 'b', 'c'))
join(x for x in 'abc')
478:デフォルトの名無しさん
09/06/09 15:34:17
>>465
Javaのどのメソッド? Stringクラスにはないけど。
479:デフォルトの名無しさん
09/06/09 15:36:29
(s = a.sort.reverse).map{|x| x.to_s}.join('-')
これを代入部分も含めたメソッドチェーン的に書き直すなら
s.assign(a.sort.reverse).map{|x| x.to_s}.join('-')
だろうね
480:デフォルトの名無しさん
09/06/09 15:38:11
>>472
ヒントください
481:デフォルトの名無しさん
09/06/09 16:08:40
>>469
>シーケンシャルな構造で要素をセパレータを挟みながら並べたいってのは
>文字列処理にしか出てこないとは限らないだろ。
だったらなおさら文字列のメソッドにするべきじゃないだろ。
セパレータは文字列と限んないんだろ？joinを文字列のメソッドにしたら、セパレータは文字列限定じゃないか。
join(seq, sep='') のような組み込み関数にしとくべきだろ。
''.join()が文字列しか対象としてないのを忘れて「文字列処理にしか出てこないとは限らない」とかバカじゃねーの
482:デフォルトの名無しさん
09/06/09 16:26:14
map が map(func, list) の構造をしてるから
join(sep='', seq=[])
になってた方がいいかな
483:デフォルトの名無しさん
09/06/09 16:27:37
それどこのreduce
484:デフォルトの名無しさん
09/06/09 18:41:59
join = lambda x, y: y.join(map(str, x))
485:デフォルトの名無しさん
09/06/09 20:06:44
すべてS式にすれば争いは起きないのに
486:デフォルトの名無しさん
09/06/09 20:38:36
>>485
すべてS式にしたらしたでCLOSになって、
どれがマルチメソッドの第一引数になるかで揉める予感。
487:デフォルトの名無しさん
09/06/09 21:17:56
>>472
in-place なメソッドだから。
488:デフォルトの名無しさん
09/06/09 21:21:16
>>477
文字列に限定しないメソッドにする場合、まず 「つなぐ」 が何かを
定義しないと行けない。join を処理前の iteratable と切り離すのは
全く問題ないが、つないだ後の形と切り離して扱うのは効率が悪い。
489:デフォルトの名無しさん
09/06/09 21:22:22
>>481
セパレータの型によってjoinの実装が変わるんだから、
文字列以外でjoinするときにはその型が自分でjoinを実装するべき。
490:デフォルトの名無しさん
09/06/09 22:26:46
>>469
Python標準では str 以外で join() を実装しているのってあるの?
hogehoge.join(['a','b','c']) # hogehoge は何か
文字列以外の join() が用意されてないなら、469のは説得力を感じないなあ。
491:デフォルトの名無しさん
09/06/09 22:58:11
>>490
少なくともUserStringは同型のjoinを持っているし、意味が違う "join" という
名前はスレッドの join であったり db の join であったりたくさんあるよ。
逆に、 str.join だと何か問題があるの？グローバルという特別な空間を
犯したり、リスト・タプル・その他すべてのイテレート可能型の名前空間に
文字列のための "join" メソッドをねじ込まないといけない理由は何？
492:デフォルトの名無しさん
09/06/09 23:51:10
>>491
>少なくともUserStringは同型のjoinを持っているし、意味が違う "join" という
>名前はスレッドの join であったり db の join であったりたくさんあるよ。
意味の違うjoinをもってきてどうすんの？
今は hogehoge.join(seq) の形でリストやタプルを引数にとるものの話にきまってるだろ。
だれがスレッドのjoinの話をしてるの? Threadのjoinはlistに実装すべきだとかだれかいったの？
話をすりかえんなよ。元の話は "".join(list) より list.join("") のほうが自然かどうかという話だろうが。
listの要素を連結するメソッドが、listじゃなくてstrのメソッドになっているのがおかしいんじゃないかという話だ。
そこをおまえがセパレータが文字列じゃないjoin()もあるとか言い出したんだろ。
だからセパレータで文字列を使わないjoin()や、文字列以外での連結を行うjoin()は実際にあるのかと聞いたら、スレッドのjoinを挙げるなんて、バカすぎるわ。
リストやタプルの要素を連結する話なのに、スレッドやDBが関係あるわけないだろ。
「文字列以外の場合も考えられる」といっているけど、結局は具体例挙げられなくて、苦し紛れにjoinがつくものを挙げただけじゃんか。
おまえ反論したいだけだろ。「多重継承があるからsuperにはクラス名が必要」とか、いちいち理由をねつ造すんなよ。
つうかPythonistaはこんなやつほっとくなよ。Python界の恥さらしだろ。身内の恥は身内でなんとかしてくれ。
493:デフォルトの名無しさん
09/06/10 00:04:54
>>492
お前こそ反論したいだけだろ。
>>491 は UserString という「同じ意味の」 join の反例を出している。
その上で、文字列以外にも join という名前はよくでてくるから文字列と
直接の関係がないリストに join という名前で文字列用のメソッドを
持ち込むことが名前空間の視点で間違っていると言ってるだけだろ。
494:デフォルトの名無しさん
09/06/10 00:11:35
RTFM
URLﾘﾝｸ(www.python.org)
495:デフォルトの名無しさん
09/06/10 00:18:58
>>492
> listの要素を連結するメソッドが、listじゃなくてstrのメソッドになっているのがおかしいんじゃないかという話だ。
joinはlistの要素を連結するんじゃないぞ。iterable であれば tuple でも generator でも
なんでも使える。listのメソッドにしたらリストにしか使えない。これだけでもリストに join を
実装すべきでない明確な理由になるな。
496:デフォルトの名無しさん
09/06/10 00:19:00
>>490
> Python標準では str 以外で join() を実装しているのってあるの?
unicode.join()
bytes.join()
497:デフォルトの名無しさん
09/06/10 00:19:46
>>496
bytearray.join もだねw
498:デフォルトの名無しさん
09/06/10 00:47:47
Python FAQにjoinのこと載ってあった。
4.8 Why is join() a string method instead of a list or tuple method?
(なんでjoin()はlistやtupleのメソッドじゃなくてstringのメソッドなの?)
URLﾘﾝｸ(www.python.org)
やっぱりみんな疑問に思うよな。思わないやつもいるけど。
FAQの答え
This method can be used with any argument which obeys the rules for sequence objects, including any new classes you might define yourself.
(このメソッドは、シーケンスオブジェクトのルールに則った引数なら何でも使うことができます。あなた自身が定義した新しいクラスでも構いません。)
つまりlistやtuple以外でも、sequenceのように振る舞うものなら何でもjoinできるようにするために、joinをlistではなくstrのメソッドにしているわけだ。
>>477の通りだな。
Rubyだとmix-inがあるから、任意のクラスでEnumerableをincludeしてやればArrayじゃないものでもjoinが使えるようになるけど、
Pythonではそうするかわりに引数を抽象化することで、繰り返し可能であればなんでもjoinで使えるようになるということか。
これならjoinがstrのメソッドである理由として納得できるな。
Pythonでは多重継承できるんだからMix-inも使える。だからEnumerableを導入することは技術的には可能だけど、iteratableを引数にするという方法も悪くないね。
これでスッキリした。Pythonいいね!
あとは多重継承が～、joinは文字列を対象にしたメソッドだから～、と、間違った理由をねつ造するバカを排除してくれ。
ほんとの理由を知らないくせに、分かったふりして語るなよな。答えしらないんなら出てくんな。
おまえリアルでも知ったかぶってるだろ。ほんと迷惑。
499:デフォルトの名無しさん
09/06/10 00:56:53
なんでここIDでないんだろ
500:デフォルトの名無しさん
09/06/10 00:59:11
迷惑な香具師に絡んで空気汚す香具師も迷惑
501:デフォルトの名無しさん
09/06/10 01:07:41
>>493
>>>491 は UserString という「同じ意味の」 join の反例を出している。
なんでこれが反例なんだ？要素を連結して文字列を返しているんだからstr.joinとかわらない。
反例というなら、文字列じゃないセパレータを使って、要素の連結結果として文字列じゃないのを返すものをだせよ。
>その上で、文字列以外にも join という名前はよくでてくるから文字列と
>直接の関係がないリストに join という名前で文字列用のメソッドを
>持ち込むことが名前空間の視点で間違っていると言ってるだけだろ。
だから、「joinが文字列用のメソッド」といいきれるのかという質問の答えになってないだろ。
おまえの話は、「joinは文字列用のメソッドであるのが自然」という前提から始まってるだろ。
その前提がおかしいんじゃないかって話をしているのに、名前空間なんか関係ないだろ。
はなっから質問が理解できてねーwww
>>495
そういう納得できる回答がほしいわけよ。バカのねつ造にゲンナリしたから、もう自力で探したけど。
バカが理由もなく「joinは文字列用のメソッド」とかぬかしてるから、Rubyistごときに反論されるんじゃん。
ついでにいうと、それはjoinがlistやtupleのメソッドではない理由としては十分だけど、strのメソッドである理由としては不十分だけどな。
あとsuperでクラス名を指定しなきゃいけないのは、多重継承が原因じゃないからな。試験にでても間違えるなよ！
502:デフォルトの名無しさん
09/06/10 01:13:40
>>498
一つの理由を見つけただけですべてを判った気になるな。
ちゃんとそのFAQの最後に、
Because this is a string method it can work for Unicode strings as
well as plain ASCII strings. If join() were a method of the sequence
types then the sequence types would have to decide which type of
string to return depending on the type of the separator.
って書いてあるだろーが。
>>477,495 が正解であると同時に、「strのjoinだからstr.join」というのも
正解だ。
Rubyは自分で文字列と同じ振る舞いをする型を追加したら、
join_to_mystr なんてメソッドを Enumerable に追加するのか?
似たものを追加するときに同じ方法を一貫して使えるのが
正しい方法だ。
503:デフォルトの名無しさん
09/06/10 01:13:45
>>461
>> ruby
>> a.sort().reverse().map{|x| x.to_s}.join('-')
>
>これ成城に動いてるときはいいんだけど
>バグが出たら何が原因か分かりづらいぜ？
Python:
'-'.join(str(x) for x in sorted(a, reverse=True))
Pythonだって、バグが出たら同じようなもんじゃん。
504:デフォルトの名無しさん
09/06/10 01:18:58
>>501
> なんでこれが反例なんだ？
> 要素を連結して文字列を返しているんだからstr.joinとかわらない。
strを拡張した型を作って join() したら元の str に戻ってしまうのが
正しい動作だと言うのか?
Unicodeをjoin()した結果がstrになるのが正しい動作か?
505:デフォルトの名無しさん
09/06/10 01:29:17
同じFAQに、
"1, 2, 4, 8, 16".split(", ")
が
", ".join([1,2,4,8,16])
と対称性が取れているという理由も載ってるね。
他の二つの理由と合わせて考えると、joinがstrのメソッドである事は
とても合理的だと思える。
506:デフォルトの名無しさん
09/06/10 01:41:41
目的のものが作れればいいんじゃない？
507:デフォルトの名無しさん
09/06/10 02:14:12
>>481
要素の型が str, unicode, bytes 以外のシーケンスに対する join は、使う場面が
少ないとはいえ一般化して考えれば存在しうるんだから、実際に出てきたときに
対応できないのはまずいね。
検索してみたら、trac の html まわりでちょうど >>469 の言っていたような事を
してる。
URLﾘﾝｸ(www.google.co.jp)
まぁ、一貫性を重視するなら文字列が入るとは限らないリストのメソッドに文字列の
連結メソッドを使うという解になるし、文字列は非常によく使う型だから一貫性から
飛び出した特別扱いにするというのも間違いではない。
あとは、「それがしっくりくる(気がする)」だけで特別扱いを許す緩いRubyと、
「明確なメリット無しに一貫性は壊さない」Python の違いでしかない。
結局どちらにしても生産性に違いはないし、読みやすさもなれたらそっちが読みやすい
程度の問題。
508:デフォルトの名無しさん
09/06/10 02:18:33
>>505
それだ!!
509:デフォルトの名無しさん
09/06/10 06:43:49
>>507
> 結局どちらにしても生産性に違いはないし、読みやすさもなれたらそっちが読みやすい
> 程度の問題。
つまり結論は>>443ってことかよ。
510:507
09/06/10 11:05:32
> 一貫性を重視するなら文字列が入るとは限らないリストのメソッドに文字列の
> 連結メソッドを使うという解になるし、
typo
一貫性を重視するなら文字列が入るとは限らないリストのメソッドに文字列の
連結メソッドを入れるなという解になるし、
511:デフォルトの名無しさん
09/06/10 13:52:20
>>502
それはダウトだろう。
今のjoinは単に u'a' + '' + u'b' + '' + u'c' のようなものだろ。
>>> ''.join([u'a',u'b',u'c'])
u'abc'
「strのjoinだからstr」なんてことはない。
もしそうなら
''.join([1,2,3]) だって要素をすべてstr()にしてからjoinしてくれてもいいけど、ぜんぜんそうなってない。
どうせ要素のすべてが文字列である場合じゃないとjoinできないんだから、listのメソッドだったとしても別におかしくはない。
Pythonの仕様上、joinをstrのメソッドにする理由はわかるけど、それが自然かどうかというのはまた別の話。
512:デフォルトの名無しさん
09/06/10 13:55:14
>>502
>Rubyは自分で文字列と同じ振る舞いをする型を追加したら、
>join_to_mystr なんてメソッドを Enumerable に追加するのか?
そうなったらjoinの引数として渡してやるだけでいいじゃん。
str.join(list) が list.join(str) となるだけ。
513:デフォルトの名無しさん
09/06/10 14:08:22
>>502
>一つの理由を見つけただけですべてを判った気になるな。
その理由すらみつけられなかったやつがえらそうに。
最初からFAQを紹介しとけばよかったものを、シッタカブリのせいでぐちゃぐちゃ。
こいつリアルでもおんなじことしてんだろうな。だれもおまえの言葉、ありがたがってないから。
514:デフォルトの名無しさん
09/06/10 15:05:56
日本人はすぐ個人攻撃に走る
515:デフォルトの名無しさん
09/06/10 16:12:54
論理的に反論できないんですねわかります
516:デフォルトの名無しさん
09/06/10 17:01:21
まぁ、論理的に反論できないやつが人格攻撃なんてよくあることだ罠
517:デフォルトの名無しさん
09/06/10 17:04:49
偉そうにはとても見えないけど、仮に偉そうだったとして、
実際この子よりは偉いだろうから仕方ないと思う。
相対的にこの子と対等かそれ以下になるのは、常人には逆に難しそう。
518:デフォルトの名無しさん
09/06/10 17:10:07
>>511
> どうせ要素のすべてが文字列である場合じゃないとjoinできないんだから、listのメソッドだったとしても別におかしくはない。
だから、どうしてstringのjoinしか見ないんだって何度もツッコミ入れられてるだろ。
joinがstringに定義されているから、引数はstringのiterableを取り、結果として連結されたstringを返す。
同様に、bytearrayのjoinは引数としてbytearrayのiterableを取り、結果として連結されたbytearrayを返す。
全部listのjoinが何とかするよりも、連結されるクラスが定義するpython式のほうがずっと自然だ。
519:デフォルトの名無しさん
09/06/10 17:11:18
>>512
> そうなったらjoinの引数として渡してやるだけでいいじゃん。
> str.join(list) が list.join(str) となるだけ。
そのlistはstrのこともbytearrayのことも何でも知ってなきゃならないわけだ。
ユーザ定義のクラスを連結したい時にはどうするの？
520:デフォルトの名無しさん
09/06/10 17:26:40
その場合はlist.join内部を+とかconcatとかで実装しておいて
その実装に使われたメソッドを各クラスで定義するのが自然ではなかろうか
一手間余計にかかるが
521:デフォルトの名無しさん
09/06/10 17:28:47
_________
／ ＼
／ ⌒ ⌒＼
／ （ ⌒） （⌒）＼
i ::::::⌒ （__人__） ⌒:: i
ヽ、 `ー ' ／
/ ┌─┐
i 丶 ヽ{ .茶 }ヽ
ｒ ヽ、__)一(_丿
ヽ、___ ヽ ヽ
と_＿＿_＿ノ＿ノ
522:デフォルトの名無しさん
09/06/10 17:33:39
>>520
つまり連結演算子/連結関数を決め打ちするということね。
そんなことするぐらいならPythonのように連結されるクラスが提供するほうが
柔軟性があって、かつ、確実だと思うが。
523:デフォルトの名無しさん
09/06/10 17:35:48
>>520
> その場合はlist.join内部を+とかconcatとかで実装しておいて
それこそjoinのありがたみが台無しじゃん。
1つ1つ連結していたら計算量が大きくなるぞ。
524:デフォルトの名無しさん
09/06/10 17:47:46
＿＿
￣￣￣二二ニ＝-
'''''"""￣￣
-=ﾆﾆﾆﾆ=-
／⌒ヽ _,,-''"
_ ,（＾ω＾ ） ,-''"; ;,
/ ,_O_,,-''"'; ', :' ;; ;,'
(.ﾞｰ'''", ;,; ' ; ;; ': ,'
_,,-','", ;: ' ; :, ': ,: :' ┼ヽ -|r‐､. ﾚ |
_,,-','", ;: ' ; :, ': ,: :' ｄ⌒) ./| _ﾉ __ﾉ
525:デフォルトの名無しさん
09/06/10 19:56:04
Rubyの方が「(Matzの)気持ちよさ」のために汎用性や効率を
犠牲にしている所が多いので、RubyとPythonの仕様の違いで
「Pythonが間違っている！」と指摘するRuby厨はたいてい
視野が狭い。
526:デフォルトの名無しさん
09/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はインスタンスメソッドではなくスタティックメソッドだから、まさに関数的な考え方。
URLﾘﾝｸ(www.atmarkit.co.jp)
joinは、オブジェクト指向が強い言語では当然のようにArrayやListのメソッドだけど、関数が主体の言語では文字列のメソッドになることがある。
少なくとも、joinが文字列のメソッドである*べき*なんてのはただのねつ造だし、言語でいえば実は少数派。
まあいいじゃん、joinが文字列のメソッドでも。PHPと同じだと思えば。
525の視野が広くなることを願いながら、この話題はここで終了。
527:デフォルトの名無しさん
09/06/10 22:00:10
>>526が言語とライブラリの区別もつかない土方な件
528:デフォルトの名無しさん
09/06/10 22:04:40
> まあオブジェクト指向的に、"連結せよ" というメッセージをどこに送信するかを考えると、そりゃArrayやListに送るわな。
ぷ
オブジェクト指向的には"連結せよ"というメッセージは連結子になるオブジェクト(string)に送るのが自然だろ。
ArrayやListに送るという発想はSmalltalkの古いCollectionの設計に縛られているだけ。
529:デフォルトの名無しさん
09/06/10 22:08:45
>>526
オブジェクト指向的かどうかではなくて、型に対する態度の問題だと思うぞ。
型を強く意識する言語では、文字列以外も入るリストに要素を文字列として
連結するなんてメソッドを追加するのはあり得ない。
C#のstaticmethod の join は、 Python にも string モジュールに join
という関数がある。文字列に関連したメソッドなんだから str の
インスタンスメソッドにした方が便利だから、インスタンスメソッドに
なっただけ。
530:デフォルトの名無しさん
09/06/10 22:13:24
「オブジェクト指向的に自然」って、自分で思いこんでるのが
すべての人にとっても自然だと考えるのはなんでなんだろうね。
少なくとも文字列の連結処理を効率的に行うには文字列の
実装を知らないといけなくて、Arrayが文字列の内部実装を
直接弄って効率的な連結をするのは気持ち悪いな。
531:デフォルトの名無しさん
09/06/11 00:45:49
理想の世界で生きていきたくても、
蛇にそそのかされてリンゴを食べたからな。
現実と向き合わないとならないのだよ。
532:デフォルトの名無しさん
09/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
533:デフォルトの名無しさん
09/06/11 09:03:24
>>511
>どうせ要素のすべてが文字列である場合じゃないとjoinできないんだから、listのメソッドだったとしても別におかしくはない。
要素のすべてが文字列である場合じゃないとjoinできないんだから
str/unicode/byteのメソッドなのでは？
534:494=502
09/06/11 13:03:13
>>513
俺は >>498 よりも先に >>494 を書いて、ちゃんと最後まで読んだ上で
RTFM と言ったんだが?
535:デフォルトの名無しさん
09/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')
536:535
09/06/11 13:23:36
>>502 じゃなくて >>511 だった
537:デフォルトの名無しさん
09/06/11 14:57:21
reduce(lambda x,y: str(x) + ',' + str(y), [1,2,3])
これ reduce 使う前提でもっと効率良く書けますか？
538:デフォルトの名無しさん
09/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
539:デフォルトの名無しさん
09/06/11 15:00:15
','.join(map(str,[1,2,3]))
540:デフォルトの名無しさん
09/06/11 15:34:13
>>539
＞reduce使う前提で
まあその前提条件はどうよという点はさておく
541:デフォルトの名無しさん
09/06/11 16:06:04
仮にreduceでどんだけがんばってもjoinよりは速くならないだろう
542:デフォルトの名無しさん
09/06/11 16:08:15
reduce(lambda x, y: '%s,%s' % (x, y), [1,2,3])
スマートさを求めるならこのあたりが限界かな
543:デフォルトの名無しさん
09/06/11 21:48:41
生成される一時オブジェクトの数のオーダが違うから無理だと思う
544:デフォルトの名無しさん
09/06/12 08:08:33
joinは？
545:デフォルトの名無しさん
09/06/12 08:17:15
joinを使うと一時オブジェクトなしで計算量O(N)。
reduceを使うと一時オブジェクトがO(N)必要で計算量O(N^2)。
どっちが良いかは明白だな。
546:デフォルトの名無しさん
09/06/12 10:16:59
Ruby の join って Enumerable のメソッドでは無くてリストのメソッドなんだな。
Pythonよりよっぽど気持ち悪い。
547:デフォルトの名無しさん
09/06/15 06:27:55
123
548:デフォルトの名無しさん
09/06/17 12:12:18
daa
549:デフォルトの名無しさん
09/06/21 06:52:49
なんかすげーあちこちに飛び火したな、joinネタ
URLﾘﾝｸ(d.hatena.ne.jp)
URLﾘﾝｸ(blog.livedoor.jp)
URLﾘﾝｸ(d.hatena.ne.jp)
550:デフォルトの名無しさん
09/06/21 12:29:31
>>549
二行目
だんこがい
ってばかだな
class List(list):
def join(self, j = ''):
return j.join(map(lambda x: '%s' % x, self))
551:デフォルトの名無しさん
09/06/21 12:38:06
return j.join(map(repr, self))
552:デフォルトの名無しさん
09/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 は違う
553:デフォルトの名無しさん
09/07/03 05:29:13
┌─┐
│●│
└─┤
_ ∩
( ﾟ∀ﾟ)彡
┌─┬⊂彡
│●│ おっぱい！おっぱい！
└─┘ おっぱい！おっぱい！
554:デフォルトの名無しさん
09/07/22 14:57:08
test
555:デフォルトの名無しさん
09/07/24 19:32:27
pythonをはじめて使った時に ''.join()みたいな書き方は
あり得ないと思ったけど、慣れてしまえば使いやすいね。
556:デフォルトの名無しさん
09/07/24 19:37:07
┌─┐
│●│
└─┤
_ ∩
( ﾟ∀ﾟ)彡
┌─┬⊂彡
│●│ おっぱい！おっぱい！
└─┘ おっぱい！おっぱい！
557:デフォルトの名無しさん
09/07/25 03:36:26
JavaScriptもjoin使うの知って
まぁそうゆうもんかと思った。
558:デフォルトの名無しさん
09/07/25 17:15:15
キャメルケースでも、アンダースコア区切りでもないのが、個人的に違和感がある。
559:デフォルトの名無しさん
09/10/03 22:56:53
アンチ少ないお
560:デフォルトの名無しさん
09/10/03 23:01:16
┌─┐
│●│
└─┤
_ ∩
( ﾟ∀ﾟ)彡
┌─┬⊂彡
│●│ おっぱい！おっぱい！
└─┘ おっぱい！おっぱい！
561:TiZCCqJpUPBkUeQHx
09/10/23 03:16:56
Black community in a town of 96% whites. ,
562:デフォルトの名無しさん
09/11/03 20:47:51
インデント記法は慣れれば気にならないし、
xx.lenghがなくてlen(xx)に統一されてるのも
個人的には嫌いだけど一理あるとは認めざる得ない。
でもスライスのx[n:m]の範囲指定は気持ち悪い。
なんか合理的な理由でもあるの？
563:デフォルトの名無しさん
09/11/03 20:52:51
他にどんな方法があるの？
564:デフォルトの名無しさん
09/11/03 21:37:23
>>562
日本語の勉強してから出直せ
565:デフォルトの名無しさん
09/11/03 21:38:46
>>563
[n:m] が n～(m-1) が気持ち悪いっていう意味だろうと E.S.P.
漏れは合理的だと思うけどね
566:デフォルトの名無しさん
09/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
となってここも計算が少なくて済む
小学生でも判るレベルの話
567:デフォルトの名無しさん
09/11/03 21:58:48
x文字目からy文字目まで取り出すとき
s[x:y+1]と計算が多くて済むから合理的
568:デフォルトの名無しさん
09/11/03 22:31:58
x文字目から最後の文字からn文字前まで取り出すとき
s[x:-n]と計算が少なくて済むから合理的
>>> 'abcde'[2:]
'cde'
>>> 'abcde'[2:-1]
'cd'
>>> 'abcde'[2:-2]
'c'
569:デフォルトの名無しさん
09/11/03 22:33:52
s = 'abcde'
s[2:len(s)]
s[2:len(s)-1]
s[2:len(s)-2]
570:デフォルトの名無しさん
09/11/04 17:09:36
Fortranに倣った
571:sage
09/11/05 01:57:16
>571
a(:)みたいな配列を1-n, n-にわけたいとき、
Fortran a(:n), a(n+1:)
python a[:n] a[n:]
と、pythonの方がすっきりだ。これに気づいてからpythonのスライシングを許せるようになったw
572:デフォルトの名無しさん
09/11/05 19:04:13
0-origin の index の場合、 [begin, end) で範囲を表現するのが一般的
大きさ0の範囲を [x,x) で表現できる。
573:デフォルトの名無しさん
09/11/06 01:00:35
>>572
その表記ってC++勉強して初めて知ったけど一般的なん？
574:デフォルトの名無しさん
09/11/06 01:12:29
数学表記でしょ
閉区間とか開区間とか
575:デフォルトの名無しさん
09/11/06 01:36:39
ああそうか、思いっきり一般的だｗ
>>573で初めてとか言ったけど学校で習った覚えもあるわ
576:デフォルトの名無しさん
09/11/06 23:36:11
ヨーロッパとかだと半開区間を [a, b[ とか書いたりする
きもい
577:デフォルトの名無しさん
09/11/10 17:42:00
URLﾘﾝｸ(groups.google.com)
googleは新規のプロジェクトではpythonを使わないように勧めてるらしい
578:デフォルトの名無しさん
09/11/10 22:34:32
GAEもう使ってないから関係ないわw
579:デフォルトの名無しさん
09/11/11 00:31:02
だからといってRubyやPerlやPHPが代わりに使われることはないわけだが。
580:デフォルトの名無しさん
09/11/11 00:33:31
するとGuile？
名前も似てるしな
名前も似てるしな
581:デフォルトの名無しさん
09/11/11 01:16:24
Google のいちおしは Noop on Scala だろ
582:デフォルトの名無しさん
09/11/11 01:49:35
Javaってことじゃん
やっぱ時代はじゃばだよな！
583:デフォルトの名無しさん
09/11/11 12:50:13
Goって囲碁のプログラムかと思ったよ
シンプルで高速、Googleの新プログラミング言語「Go」
URLﾘﾝｸ(journal.mycom.co.jp)
584:デフォルトの名無しさん
09/11/11 15:23:00
Google の中の人、言語作るの好きだな
585:デフォルトの名無しさん
09/11/11 18:21:08
Noopが当て馬、Goが本命？
586:デフォルトの名無しさん
09/11/11 22:10:10
また中途半端なものを出してきたなw
587:デフォルトの名無しさん
09/11/11 22:46:39
単に Google の中の人は飽きっぽいだけだと思
588:デフォルトの名無しさん
09/12/25 20:18:30
test
589:デフォルトの名無しさん
10/01/10 22:59:29
なんでlist.rindexがないのか、理解できない
590:デフォルトの名無しさん
10/01/10 23:03:05
双方向リンクになってないから？
reverseかけてからやるしかないね
591:デフォルトの名無しさん
10/04/10 18:43:33
なんでPythonスレはあんなに荒れているのに、このスレはこんなに平和なのか。
592:デフォルトの名無しさん
10/04/11 16:53:40
このスレが機能してないからでは
593:デフォルトの名無しさん
10/04/11 17:28:44
ここはスレタイがネガティブだから平和なのでは。
本スレに"人生の敗北者でも使える"を付けてみるとか。
594:デフォルトの名無しさん
10/04/11 18:38:07
そういえば昔は付いてたな
595:デフォルトの名無しさん
10/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
こちらは動きます
バッファオーバーランとかの突っ込みはなしでおながいします
596:デフォルトの名無しさん
10/04/14 14:16:47
ImmGetCompositionString(himc, GCS_COMPSTR, byref(buf), 0) は？
597:デフォルトの名無しさん
10/04/14 14:54:02
ImmGetCompositionStringの第4引数を0 => len(buf)あるいは1024
598:デフォルトの名無しさん
10/04/14 14:55:20
ImmGetCompositionStringの
3つ目の引数はLPVOIDだけど
char*として扱っていいのか？
599:デフォルトの名無しさん
10/04/14 15:01:11
>>596-598
ありがとうございます
ImmGetCompositionString(himc, GCS_COMPSTR, buf, len(buf.raw))
で取得出来ました
600:デフォルトの名無しさん
10/04/14 15:10:26
なんでPythonスレはあんなに荒れているのに、このスレはこんなに平和なのか。
601:デフォルトの名無しさん
10/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 になるみたいです
ありがとうございました
602:デフォルトの名無しさん
10/04/14 23:25:34
>>600
本スレだったら
len(buf)ってなにそれ？ 普通はbuf.len()だろww
ってなってるな。
603:デフォルトの名無しさん
10/04/15 00:41:12
>>602
こっちくんな
604:デフォルトの名無しさん
10/04/15 17:50:47
ﾍ⌒ヽﾌ
（ ・ω・） ㌧㌧
/ ~つと）
605:デフォルトの名無しさん
10/05/02 19:20:41
C++アプリにPythonを組み込んでみたいんだけど、
BlenderってアプリはPCにPythonをインストールしてないとPython動かせないじゃないですか。
アプリからPythonスクリプトを実行するにはPython環境を必要とするものなんですか？
あとマルチコアCPUだと実行が遅くなるって本当ですか？
606:デフォルトの名無しさん
10/05/02 21:37:41
Ruby使うと良いよ
607:デフォルトの名無しさん
10/05/02 22:17:28
>>606
ありがとうございます
Rubyの方が組み込み言語として枯れてるんですか？
PythonやJavaScriptに比べるとユーザ少そうだし一番トラブりそうと思い込んでました
608:デフォルトの名無しさん
10/05/03 12:46:46
cython
609:デフォルトの名無しさん
10/05/05 10:14:49
┌─┐
│●│
└─┤
_ ∩
( ﾟ∀ﾟ)彡
┌─┬⊂彡
│●│ おっぱい！おっぱい！
└─┘ おっぱい！おっぱい！
610:デフォルトの名無しさん
10/05/28 09:39:44
保守age
611:デフォルトの名無しさん
10/05/29 12:08:14
ﾘﾊﾞｰｽｴﾝｼﾞﾆｱﾘﾝｸﾞ ―Pythonによるﾊﾞｲﾅﾘ解析技法が欲しい
612:デフォルトの名無しさん
10/06/11 19:47:46
LLでバイナリってのも今ひとつ何をねらってるのかよくわからんな
613:デフォルトの名無しさん
10/06/11 19:58:26
C言語でsegvしながらガリガリ切り貼りするよりだいぶ楽なことが多いと思う
614:デフォルトの名無しさん
10/06/11 21:08:02
>>612
解析なら別にいいんじゃね？
615:デフォルトの名無しさん
10/06/19 18:35:21
ここだけまったりした雰囲気だな。
∧＿∧
( ´･ω･) みなさん、お茶が入りましたよ・・・・。
( つ旦O
と＿)＿) 旦旦旦旦旦旦旦旦旦旦旦旦旦旦旦旦旦旦旦旦
616:デフォルトの名無しさん
10/10/24 17:22:06
本スレ荒れてるなぁ...
617:デフォルトの名無しさん
10/10/24 21:09:59
本スレが荒れてるんじゃない
君の心が荒れているんだ！
618:デフォルトの名無しさん
10/10/24 22:43:02
┌─┐
│●│
└─┤
_ ∩
( ﾟ∀ﾟ)彡
┌─┬⊂彡
│●│ おっぱい！おっぱい！
└─┘
619:デフォルトの名無しさん
10/10/27 01:57:33
何でNoneオブジェクトまでINCREF,DECREFしてるん？
620:デフォルトの名無しさん
10/10/27 02:20:57
よくわかんないけど、毎回Noneかどうか比較するよりもINCREF, DECREFしてGCの対象から外した方が軽かったんじゃない？
621:デフォルトの名無しさん
10/10/28 01:39:44
pyscripterのバージョンがいつの間にか上がってる
開発に波あるみたい
622:デフォルトの名無しさん
10/10/30 03:51:24
from BaseHTTPServer import HTTPServer
from SimpleHTTPServer import SimpleHTTPRequestHandler
httpd = HTTPServer(('', 8080), SimpleHTTPRequestHandler)
httpd.serve_forever()
623:デフォルトの名無しさん
10/11/01 15:01:38
URLﾘﾝｸ(twitter.com)
yukihiro_matz: 英語圏でRubyとPythonを比較する記事を見ることが少なくなってきた
のは、RubyとPythonでクラスタが分離してきたからか。逆に日本語でRubyとPythonを
比較 する記事を見かけるのは国内でのPythonの地位が向上したからか。
∩＿
〈〈〈 ヽ
＿＿＿_ 〈⊃ }
／⌒ ⌒＼ | |
／（ ●） （●）＼ ! !
／ :::::⌒（__人__）⌒:::::＼| l
| |r┬-| | ／ ＜こいつ最高にアホだお
＼ ｀ ー'´ ／／
/ ＿＿ /
(＿＿＿） /
624:デフォルトの名無しさん
10/11/01 15:04:29
∩＿
〈〈〈 ヽ
＿＿＿_ 〈⊃ }
／⌒ ⌒＼ | |
／（ ●） （●）＼ ! !
／ :::::⌒（__人__）⌒:::::＼| l
| |r┬-| | ／ ＜こいつ最高にアホだお
＼ ｀ ー'´ ／／
/ ＿＿ /
(＿＿＿） /
625:デフォルトの名無しさん
10/11/02 01:04:22
まつもと君。まだそんなこと言ってるのか・・・・
626:デフォルトの名無しさん
10/11/02 16:27:18
アップルに捨てられたからでしょうに・・・
627:デフォルトの名無しさん
10/11/02 16:43:35
AppleはMacRuby開発してんじゃん
628:デフォルトの名無しさん
10/12/27 04:00:12
age
629:デフォルトの名無しさん
11/01/16 14:25:59
Python って、インデントでブロックを表現する変態言語だけど、
実は Ruby 並には機能が詰まった言語らしいくらいのイメージしかないんだけど。
正直触ったことがほぼないからよくわからん。
そもそも、あまり書籍を見かけないし、web のフレームワークの話もみかけない。
Google にはよくしてもらっている程度しか優位性をしらないんだけど。
630:デフォルトの名無しさん
11/01/16 14:39:12
>>629
まあ、まずはざっとこれ読んでくれ。
URLﾘﾝｸ(stackoverflow.com)
631:デフォルトの名無しさん
11/01/16 14:49:41
>>630
ざっとみたが、英語は不得意なので『インデントでブロックを表現する変態言語』くらいしか伝わらなかった。
632:デフォルトの名無しさん
11/01/16 17:14:30
どうせコード書くときにはpythonに限らず適宜インデントすんだろ。
むしろ余計な{}なんかがないだけよっぽど読みやすい。
633:デフォルトの名無しさん
11/01/16 20:44:21
大学のときまったくインデントを使わずにJavaを書く教授がいた
634:デフォルトの名無しさん
11/01/16 20:50:07
>>632
はげ
635:デフォルトの名無しさん
11/01/16 20:51:24
おまいらスレ違い
あっちいけ
ｽﾚﾘﾝｸ(tech板)
636: 忍法帖【Lv=1,xxxP】
11/05/31 22:41:13.51
test
637:デフォルトの名無しさん
11/06/01 21:45:06.41
てすてす
638:デフォルトの名無しさん
11/06/01 21:54:40.40
改行
テスト
639:デフォルトの名無しさん
11/06/01 22:52:12.69
quit()
640:デフォルトの名無しさん
11/06/02 05:14:30.59
test
641:デフォルトの名無しさん
11/06/02 18:13:46.44
hogehuga
642: 忍法帖【Lv=2,xxxP】
11/06/02 20:35:34.45
test
643: 忍法帖【Lv=3,xxxP】
11/06/02 20:46:14.23
あり～ん
644:デフォルトの名無しさん
11/06/03 21:13:57.44
test
645:デフォルトの名無しさん
11/06/04 00:00:48.90
ウンチ
646:デフォルトの名無しさん
11/06/04 07:49:51.69
お！これは。
てすと
647:デフォルトの名無しさん
11/06/04 14:07:03.65
ここのtestってpythonのスクリプトで書き込みのテストをしていると考えていいでしょうか？
648:デフォルトの名無しさん
11/06/04 19:50:39.90
Python 3.2.1 のリリースがまた延期されちゃったね。
649:デフォルトの名無しさん
11/06/05 01:22:46.74
○ンチ専用
650:デフォルトの名無しさん
11/06/10 21:09:52.09
6月19日にFinal出るのかね？本当に。
651:デフォルトの名無しさん
11/06/11 00:44:15.80
Yes, I do.
652:デフォルトの名無しさん
11/06/18 05:10:42.38
出るかな出るかな～？
653:デフォルトの名無しさん
11/06/19 06:52:54.02
いよいよ今日だね。
654:デフォルトの名無しさん
11/06/20 21:07:26.68
出たのかな？
655:デフォルトの名無しさん
11/06/20 21:51:47.26
勉強スレの方にアンチが沸いてるのに、こっちはまったり。