アカウント名:
パスワード:
Pythonはライブラリというかモジュールがたくさんあるし、コンパイルしなくていいので手軽だし、最近はCPUも十分早くなってるし、メモリもたくさんあるので、処理速度も巨大データを扱わない限りは問題になりにくい。言語仕様もわかりやすいし、なんといっても辞書型が強力なので、データ処理もやりやすい。「(習得と)開発にかかる時間と処理にかかる時間」の合計では一番短時間で課題解決できると思うのである意味納得。
かつてはCPUは遅く、メモリも今ほど潤沢でなかったので、Cで書かないと処理時間が・・・なんてこともあったけど、今はCで書く気は起きない。組み込みでない限り・・・。
#Javaはそのうち手を出すかなぁ、と思ってるうちに、ださないまま終わりそう。
Python 3を使うべきでない場合(なんてない) [postd.cc]
私の経験では、プログラマの90%はUnicodeについて考える必要はありません。とても多くのプログラマが仕事でASCIIを使うからです。
この問題の影響を受ける人口は、Unicodeを扱う、10%の人々だけなのです。
はい解散
自分の使う範囲(日本語しか出てこない)においては、先頭の方に
# -*- coding: cp932 -*-
って書いといて、もちろんソースコード自体もCP932で作成、マルチバイトになる可能性のある文字列の部分は u'...' という形で記述しとくと、LinuxでもWindowsでも動作するものになって便利です。とりあえず文字列というか Unicode ではほとんど悩まなくて済んでます。Python2.7ですけど。ちなみにソースコードはLinux上で Geany で作成&デバッグ。Windows版Geanyがもっと軽快に動けば嬉しいのだけどなぁ。。XLSXからのインポート、XLSXへのエクスポート(グラフ付き)が簡単なので手放せません。
Python3はちょっとしか試してないので、同じ方法でどこまでいけるのかはわからん。
python 3系使ってるけど2系とか文字コード周りマゾくて使う気がさっぱりしない。2.7使ってた頃は文字列が2種類あるのが苦痛で、さっさと3系列に移行しました。幸せになれました。ライブラリが追いついてくるまでちょっと不自由だったけど。
まぁ、互換性の問題で2系列から移行できないってのは仕方ないけどね。
# ちなみに # -*- coding:utf8 -*-
自分の使う範囲(日本語しか出てこない)においては、先頭の方に # -*- coding: cp932 -*- って書いといて、もちろんソースコード自体もCP932で作成、マルチバイトになる可能性のある文字列の部分は u'...' という形で 記述しとくと、LinuxでもWindowsでも動作するものになって便利です。
え、2017年の今になっても、そんなことせにゃならんの?ただそれだけでPython使う気失せる。
3系にすりゃいらん
うるせえemojiでも食ってろ
絵文字のおかげでシングルバイト文字圏のエンジニアが多少はユニコード対応に真剣になったのは良かった。
その記事と参照されている元の記事は、Python2とPython3の話でしょ。
Python3の標準の文字列はutf-8です。日本語処理で困ったことはありませんね。
その記事自体が The Case Against Python 3 (For Now) [learnpytho...ardway.org]という、Python 3をディスった少々的外れな記事に対する、これまた頓珍漢な反論記事なので……。(特に文字列の部分)
元々Pythonにはstrという文字列型(いわゆるマルチバイト文字列)と、後から追加されたunicode(こっちはUNICODE文字列)がありまして、両者は混在可能でした。C言語で言うと、char文字列とwchar_t文字列が混在できる(別の型同士でstrcatしたりできる)というものです。ところが、こいつは英語圏以外では実用にならないのです。なぜかというと、
strとunicodeが混在したときには、自動的にunicodeをAS
pythonってガチで計算処理させると遅くない?高速化しようにもスレッドは並列で動かないし、multiprecessingは重すぎるし。みんなどうしてるんだろう?部分的にCでOpenMP使って分散処理させるのが正解なのかね?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
「毎々お世話になっております。仕様書を頂きたく。」「拝承」 -- ある会社の日常
短時間で結果がだせるからありがたい (スコア:0)
Pythonはライブラリというかモジュールがたくさんあるし、コンパイルしなくていいので手軽だし、
最近はCPUも十分早くなってるし、メモリもたくさんあるので、処理速度も巨大データを扱わない限りは問題になりにくい。
言語仕様もわかりやすいし、なんといっても辞書型が強力なので、データ処理もやりやすい。
「(習得と)開発にかかる時間と処理にかかる時間」の合計では一番短時間で課題解決できると思うのである意味納得。
かつてはCPUは遅く、メモリも今ほど潤沢でなかったので、Cで書かないと処理時間が・・・なんてこともあったけど、
今はCで書く気は起きない。組み込みでない限り・・・。
#Javaはそのうち手を出すかなぁ、と思ってるうちに、ださないまま終わりそう。
Re:短時間で結果がだせるからありがたい (スコア:1)
Python 3を使うべきでない場合(なんてない) [postd.cc]
私の経験では、プログラマの90%はUnicodeについて考える必要はありません。とても多くのプログラマが仕事でASCIIを使うからです。
この問題の影響を受ける人口は、Unicodeを扱う、10%の人々だけなのです。
はい解散
Re: (スコア:0)
自分の使う範囲(日本語しか出てこない)においては、先頭の方に
# -*- coding: cp932 -*-
って書いといて、もちろんソースコード自体もCP932で作成、マルチバイトになる可能性のある文字列の部分は u'...' という形で
記述しとくと、LinuxでもWindowsでも動作するものになって便利です。とりあえず文字列というか Unicode ではほとんど
悩まなくて済んでます。Python2.7ですけど。
ちなみにソースコードはLinux上で Geany で作成&デバッグ。Windows版Geanyがもっと軽快に動けば嬉しいのだけどなぁ。。
XLSXからのインポート、XLSXへのエクスポート(グラフ付き)が簡単なので手放せません。
Python3はちょっとしか試してないので、同じ方法でどこまでいけるのかはわからん。
Re: (スコア:0)
python 3系使ってるけど2系とか文字コード周りマゾくて使う気がさっぱりしない。
2.7使ってた頃は文字列が2種類あるのが苦痛で、さっさと3系列に移行しました。
幸せになれました。ライブラリが追いついてくるまでちょっと不自由だったけど。
まぁ、互換性の問題で2系列から移行できないってのは仕方ないけどね。
# ちなみに # -*- coding:utf8 -*-
Re: (スコア:0)
自分の使う範囲(日本語しか出てこない)においては、先頭の方に # -*- coding: cp932 -*- って書いといて、もちろんソースコード自体もCP932で作成、マルチバイトになる可能性のある文字列の部分は u'...' という形で 記述しとくと、LinuxでもWindowsでも動作するものになって便利です。
え、2017年の今になっても、そんなことせにゃならんの?
ただそれだけでPython使う気失せる。
Re: (スコア:0)
3系にすりゃいらん
Re: (スコア:0)
うるせえemojiでも食ってろ
Re:短時間で結果がだせるからありがたい (スコア:2, 参考になる)
絵文字のおかげでシングルバイト文字圏のエンジニアが多少はユニコード対応に真剣になったのは良かった。
Re: (スコア:0)
その記事と参照されている元の記事は、Python2とPython3の話でしょ。
Re: (スコア:0)
Python3の標準の文字列はutf-8です。
日本語処理で困ったことはありませんね。
Re: (スコア:0)
その記事自体が The Case Against Python 3 (For Now) [learnpytho...ardway.org]という、Python 3をディスった少々的外れな記事に対する、これまた頓珍漢な反論記事なので……。(特に文字列の部分)
元々Pythonにはstrという文字列型(いわゆるマルチバイト文字列)と、後から追加されたunicode(こっちはUNICODE文字列)がありまして、両者は混在可能でした。
C言語で言うと、char文字列とwchar_t文字列が混在できる(別の型同士でstrcatしたりできる)というものです。
ところが、こいつは英語圏以外では実用にならないのです。なぜかというと、
strとunicodeが混在したときには、自動的にunicodeをAS
Re: (スコア:0)
pythonってガチで計算処理させると遅くない?
高速化しようにもスレッドは並列で動かないし、multiprecessingは重すぎるし。
みんなどうしてるんだろう?部分的にCでOpenMP使って分散処理させるのが正解なのかね?