« PythonとwxPythonとwxGladeと | トップページ | MG ストライク・ルージュ(完成) »

Pythonのお勉強

Cametanさんから、ご紹介いただいた以下のサイト。
「Pyhtonチュートリアル」

これ、すごくよいので、メモ。(笑)

もちろん、全文日本語です。

ついでに、「Pyhtonリファレンス」。こちらも日本語。
いやぁ、驚いた。
確かにこれなら書籍買う必要ないわ。(笑)

チュートリアルの方ですが、まさに知りたい情報がきちんと順を追って書かれています。
for文なんか、ワタクシのよく知ってる言語系とはずいぶん違うな、という印象でしたが、これで使い方がイメージ出来ました。
普通の他の処理系と同様に使うことも出来ます。
#ちょいとクセありますけど。

文字列に関しても、概ねのことはチュートリアルに書いてあるので、ある程度、他の言語を習得している方なら、このチュートリアルを斜め読みするだけで、十分にPythonを使えるようになりそうです。

大変素晴らしい情報を頂きました。(笑)

これもブログなんぞを書き散らしているおかげですかね。
こうして困ってるようなところを書き散らしておくと、読んでくださってる方から、コメントとして助けがある。
ありがたいことです。

こういう時、書いてて良かったな、と思いますね。

Pyhton処理系はWindowsにもあるようだし、wxGladeを使ってる分にはWindowsでもイケそうなんで、クロスプラットフォームな開発にも使えるかも知れません。
ま、ワタクシは、そんな必要全然ないので、Ubuntuで動く個人用ツールが作れればそれで充分ですけどね。

|

« PythonとwxPythonとwxGladeと | トップページ | MG ストライク・ルージュ(完成) »

Ubuntu」カテゴリの記事

パソコン・インターネット」カテゴリの記事

コメント

>or文なんか、ワタクシのよく知ってる言語系とはずいぶん違うな、という印象でしたが、これで使い方がイメージ出来ました。


構文的にはCに似せてますけど、ちょっと変わってますよね。リスト処理にしている辺りが。
その辺、Lispとかの影響が大きいみたいです。
もっともLispやるとfor文さえ書くの面倒くさくなっちゃってアレなんですが(笑)。必要ないところまで再帰させちゃったりして(笑)。
VBAと比べて、Pythonって再帰も難なく扱ってくれるのが楽ですね。


>Pyhton処理系はWindowsにもあるようだし、wxGladeを使ってる分にはWindowsでもイケそうなんで、クロスプラットフォームな開発にも使えるかも知れません。


いや、かなり面白いんじゃないか、とか思いますよ。
実は、minGWなんかもUbuntuにインストール出来るんで(Synapticで探せます)、わざわざWindowsに戻らなくてもWindows用のexeファイルにコンパイル出来たりする模様で。動作はWineで確かめる、で充分だそうです。
まあ、PythonとC連結させる予定が無ければ関係ないんですが(笑)、こうなると色々夢が広がってきます。


この辺の「クロスプラットフォーム」考えると確かにPythonは強力なんですよね。それと、ボトムアッププログラミング向けなんで企業の開発のように「仕様書」とか書かないで「いきなり」書き始めれますしね(不思議な事に、VBAの本だと「仕様書作れ」的な事が入門者向けに書いててビックリしますが)。


オープンソース作家「かおりん」様のデビューを楽しみにしています。

投稿: cametan | 2008年10月26日 (日) 11時55分

>この辺の「クロスプラットフォーム」考えると確かにPythonは強力なんですよね。それと、ボトムアッププログラミング向けなんで企業の開発のように「仕様書」とか書かないで「いきなり」書き始めれますしね(不思議な事に、VBAの本だと「仕様書作れ」的な事が入門者向けに書いててビックリしますが)。


う〜ん、企業体で考えると、「仕様書」は必要なんですよね。
同じ人間がいつまでも同じコードをメンテしない、というのが大きな理由。
プログラムコードが仕様書代わり、なんて冗談交じりに言うひともいますけど、「プログラムにはバグが混入するもの」という前提で考えると、プログラムの動作が、そのまま「意図通りになっている」保証がない。
なので、「こういう動作をする、こういうことを目的として開発されたものですよ」という程度の最低限の基本仕様書は必要になるんです。
ようは、設計者の意図を、きちんと残しておきましょう、と。
それで初めて、他の人間にも引き継ぎが可能になります。
引き継ぎを行う理由は、「プログラムの構造を理解して貰う」のではなく、「設計の意図を理解して貰う」ことにあります。
なので、仕様書さえ残っていれば、全然違うコードで書き直すことも可能なので、「企業では」仕様書を書くことから始めるのだと思います。

ま、なかなかね。ドキュメントがきちんと整備されているプロジェクトってのも少ないのかも知れませんけど。意図というか、狙いとしてはそんなことを言ってます。

でも。
入門書に書くことではないかな。
大規模プログラム開発とか、実際には企業のOJTとかで展開するような話だと思います。
だって、「プログラミング」には関係ない話なので。(笑)


>オープンソース作家「かおりん」様のデビューを楽しみにしています。


ああ、これは難しいですねぇ。(爆)

投稿: かおりん | 2008年10月26日 (日) 14時08分

>う〜ん、企業体で考えると、「仕様書」は必要なんですよね。
同じ人間がいつまでも同じコードをメンテしない、というのが大きな理由。


確かに企業ベースだとそうなんでしょうねえ。


まあ、ちょっと仕様とズレますが、オープンソースのソフトウェアも「man」が揃ってるのと全く無いのがあるんですよね。Documentが付いてなかったりして。こう言うの使うとき死ぬほど苦労したりします。
最近、SVNに付いて調べてたんですが、GUIのクライアントソフトでSVNcommanderとか言うのがあって、使いやすそうだったんですが、ドキュメントが不整備で……そうなるとパスせざるを得ない。
結構そう言うケースってあります。


EmacsでRuby環境整えよう、として、elispファイル見つけてくるのは良いんですが、「セットアップの方法」が書いてなかったりして。Webあっちこっち「たらい回し」状態だった時も困りましたねえ。最近のスクリプト言語系の隆盛は良いのですが、その辺「ドキュメント整備」の文化ってあんま育ってないな、とか正直思いました。
PythonはRubyほど酷く無いんですが、やっぱりちょっとその気があります。


Pythonの場合はトリプルクオーテーションで「コメント=即マニュアル」って機能がある事はあるんですが、一方、そこまで「明示的」には使われてなかったりして。そう言う辺り大変です。


どっちか、と言うと小規模開発(個人で行うサンデープログラミングを含む)で「コメント」が恐らく一番重要なんじゃないか、とか思います。仕様書ではないんですがね。ただ、意外とそれ考えて書くのもメンド臭かったりして(笑)。
あと、「関数名を分かりやすく付けよう」って提案もあるんですが、それやると長い名前になって大変だったりして(笑)。何度も呼び出すと嫌気さしてきたりして(笑)。
そうですね〜〜。その辺の「ちょっとした習慣」とか「クセ」を付けるには、逆に最初に「仕様書」って形で無理にでも書くクセ付けた方がいいのかなあ。お話伺ってそう言う事をちょっと思いました。


>入門書に書くことではないかな。


うん、それはそう思ったんですよね(笑)。何でそこから?とか(笑)。フローチャートとかもそうなんですけど。


例えば、僕がオブジェクト指向もどうして「慣れないのか」にも通じるんですが、例えば、「何か書こうとする前」に全体像把握出来るのか、って言う疑問があるんですよね。オブジェクト指向も「書く前にどんなデータ型が要り用になるか分かる」って言うのがあり得るのか、とか思うんですよ。まあ、それこそ素人の戯言なんですけども(慣れてないだけか・笑)。クラス設計するの、ってそう言う事ですよね?「今から書こうとするプログラムで必要になるデータ型を最初に定義しちゃう」って事ですから。素人目にはかなり「不自然」なのです。
恐らく、サンデープログラミングだと「書いてる途中でどう転ぶか分からへんで〜〜」的な(笑)。多分そう言う「かなりラフな」モノの方が「おかしいだろうな」と。VBAの入門書見る限り、それと「真逆だ」ってのが違和感感じた大きな部分でした。

投稿: cametan | 2008年10月26日 (日) 17時36分

>どっちか、と言うと小規模開発(個人で行うサンデープログラミングを含む)で「コメント」が恐らく一番重要なんじゃないか、とか思います。仕様書ではないんですがね。ただ、意外とそれ考えて書くのもメンド臭かったりして(笑)。


これで普通は充分かと思います。
関数や、ソースファイルの先頭に、目的と意図を記載しておく。
それだけで、用は果たせますからね。
それがルールに則って書かれていれば、プログラム仕様書なんかは自動生成可能になるわけですし。


>うん、それはそう思ったんですよね(笑)。何でそこから?とか(笑)。フローチャートとかもそうなんですけど。


フローは、知ってればそれでいいんでしょうけど。
実際の制御を考える際には、意味もあるかも知れません。
必要かどうか、って点ではどうなのかなぁ。
ワタクシ個人としては知らなくてもいいんじゃないの、と。(笑)
プログラムの概念を学ぶにはいいかも知れませんが、まあ、制御構造の概念学んで、なんか楽しいか、というとあまり楽しくない。
なんで、入門書はもっとカンタンにプログラムを組んでいることが実感できるサンプルとか、ガンガン行かせればいいんじゃないんですかね。

ぶっちゃけ、サンデープログラマなら、理屈は後から付いてくる、で充分じゃないかと思います。
一人で試行錯誤して、何回も失敗して。
で、どうにか成功を重ねて、それから概念とか、作法とか説明されている資料を読めば、実感として、「ああ、こういうことだったんだな」と解るかと。
経験してから、の方が理屈は通りやすいんじゃないかと思うんですよね。

>例えば、僕がオブジェクト指向もどうして「慣れないのか」にも通じるんですが、例えば、「何か書こうとする前」に全体像把握出来るのか、って言う疑問があるんですよね。オブジェクト指向も「書く前にどんなデータ型が要り用になるか分かる」って言うのがあり得るのか、とか思うんですよ。まあ、それこそ素人の戯言なんですけども(慣れてないだけか・笑)。クラス設計するの、ってそう言う事ですよね?「今から書こうとするプログラムで必要になるデータ型を最初に定義しちゃう」って事ですから。素人目にはかなり「不自然」なのです。


そのために設計をするんです。
オブジェクト指向というのは、実装の技術(ある意味設計の技術でもありますが。)なので、あらかじめ、データ構造とか設計しておけば、オブジェクトに必要なデータ型が定義できる、はずなんですよ。(笑)
#はず、というのがポイント。(爆)

基本設計をして、機能設計をして、データ設計をして、それからクラス設計なので、このときには、どんなデータが、どのように処理されるのかは、明らかになっている「はず」なんですよ。

なので、大規模プロジェクトになればなるほど、仕様書が大事になる、と。

こういうデータが必要になるので、あらかじめ抽象化して、クラスにしておく、というのがオブジェクト指向の考えだとは思いますけど。
そこからさらに発展系のデータが必要なら、派生して差分だけを記述(定義)していけるってところがメリットなんですけどね。
この辺、基本クラスが良いものであれば多重派生(だったかな?)とか、そういうやり方で新しいクラスに複数の属性を持たせることが出来る、のがいいところのはずなんですけどねぇ。

その辺綺麗に行ってる実装はあまり見ませんね。(爆)

>恐らく、サンデープログラミングだと「書いてる途中でどう転ぶか分からへんで〜〜」的な(笑)。多分そう言う「かなりラフな」モノの方が「おかしいだろうな」と。VBAの入門書見る限り、それと「真逆だ」ってのが違和感感じた大きな部分でした。


サンデープログラマは、それでいいと思います。
作るのが面白いので、作成途中で、そもそも設計が変わるなんてことがあり得る。
#仕様変更ですね。

企業で、仕様書を重視する目的のひとつとしては、先ほどは書きませんでしたが、「ユーザーとあらかじめ約束をする」ためでもあるんです。
オカネを払う企業に対して、こういうものを、このくらいの期間で、このくらいの費用で作成します、と約束するんですね。
なので、あらかじめ仕様書を作成して、こういうものが出来上がります、とユーザーに確認する。必要なものはこれで間違いないですか、と。
で、約束通りのものが出来上がってたらオカネをきちんと貰う、という流れになるので、仕様書でユーザーと合意を取るのが非常に重要になります。

ユーザーも最初の約束通りのものが出来上がっているのか、仕様書を元に確認するので、大事なんですね。
さらに言えば、最初に約束をしておかないと、「いや、実は、この機能はそういう機能を期待していたんじゃないんですよ」とか言い出すひともいたりして。
そんなのは面倒見てられないので、あらかじめ、「いや、仕様書ではこのような機能として定義されているので、その通りに作成しています」と主張するためにも重要なんですよ。(笑)
#ある意味イヤな仕事だ。(爆)

という理由が主だったりするので、サンデープログラマは、別に仕様書にはこだわる必要はさっぱりないとワタクシなんぞは思うんですけどね。
約束するのは自分にだけ、だし、そこでかかるコストも自分で担保するので、まったく問題ないと思います。
まあ、どこで終わりにするのか、そこを最初に決めとこう、って程度の話なら必要かも知れませんけど、逆に言えば、その程度の「仕様」でいいんじゃないですかね。

投稿: かおりん | 2008年10月26日 (日) 20時01分

>#はず、というのがポイント。(爆)〜
>その辺綺麗に行ってる実装はあまり見ませんね。(爆)


う〜〜ん、かおりんさんは正直なお方だ(爆)。


何か「人月の神話」って本があって、それ買って読んでみたいんですが。
もうとにかく「プロジェクト」は仕様書通りに決まらん、納期は遅れる、って本らしいんですが(爆)。どうも「実効性」自体は怪しいらしいんですよねえ。


オブジェクト指向も……そうなんですよねえ。根本的な疑問は「サンデープログラムには向いてないんじゃないのか」ってのがあります。その「設計」の部分が、なのでは、と。VBA辺りの入門書だとそこを強調してたりするんでこれが違和感の元なんでしょうね。


また話ズレますが、「動的型付け」か、「静的型付け」か、なんてのも同様な文脈に思えて。動的の方に慣れると、書く前に「変数の型が分かるか」とか思っちゃったりするんですよね(笑)。みんな変数宣言良くミスらないで書けるな、とか妙なところで感心したりします(笑)。
ただ、これも同様な文脈で、個人で書いて使う分には「使い方」が分かってるんで良いんですが、ユーザーが別に存在する場合はやっぱ話が変わってくるんじゃないのか、とか最近思うようになりました。自分が設定した引数なんかに「全く思いもしなかったような」型ぶち込めれた時の挙動が制御出来ない、って事も起こりうるのかもな、と。
静的で宣言しとけば勝手にエラー出してくれる、ってのは利点で、動的だとプロトタイプには良いけど、逆に自分で全部エラー処理書くのはメンドっちいのかも、とか。計算速度がどうの、じゃなくて意外とそっちのコストの方が大きいのかな、とか思うようになりました。


>#ある意味イヤな仕事だ。(爆)


わはははは(笑)。
まあ、でもWindows系の「デスクトップ向けアプリケーション製作」だと余計そう言う文脈になるんでしょうねえ。半分以上、「プログラミング側からの要請」じゃなくって営業とか、そっちの方からの要請もあるんでしょうし。
GoogleとかのWebアプリ系だとまた違う、とは聞くんですけどね。Googleはドキュメンテーション作りは徹底させるそうなんですが、やっぱ仕様書書かせる、って事は無いそうです。が、こう言うのはWebアプリだから可能なんでしょうね。
まあ、mixiなんかもそうですが、割に永久にbeta版のままでいていい、とか(笑)。しょっちゅうチョコチョコ改造してても良い、って環境と、デスクトップ向けのように「リリース」って作業が決まってる分野とはそう言う点では「やり方」が違ってくるんでしょうね。
多分、Googleなんかはかなり「大掛かりな」サンデープログラムだよな、とか思います。

投稿: cametan | 2008年10月27日 (月) 10時26分

う〜ん、Webアプリだから、仕様書書かないってことはないと思うんですけどね。
Googleのやり方、なんじゃないんですかね?
正直、そのやり方で、大規模なアプリの開発が滞りなく行えるんだろうか、という気もしますが、実際には、メインで采配をふるう人間がスーパーなひとであれば可能なのかな、とか。

実際、開発の現場だと、そういう場面も目にしますしね。

企業によっても、やり方は違うものなのかもしれません。
ワタクシも、それほど世界が広くないので。(笑)

投稿: かおりん | 2008年10月29日 (水) 22時40分

コメントを書く



(ウェブ上には掲載しません)




トラックバック

この記事のトラックバックURL:
http://app.cocolog-nifty.com/t/trackback/500703/42908052

この記事へのトラックバック一覧です: Pythonのお勉強:

« PythonとwxPythonとwxGladeと | トップページ | MG ストライク・ルージュ(完成) »