Python(バージョン 3)を初歩から学習していく際のメモを書いていきます。
Pythonの知識自体は、0の状態からのスタートしています。(2013/11/10〜)
内容を見直し、記述を修正しました。(2017/01/02)
学習時に見ているサイト
公式ドキュメント
http://docs.python.jp/3.3/Python-izm
http://www.python-izm.com/Dive Into Python 3
http://getpython3.com/diveintopython3/Dive Into Python 3 日本語版
http://diveintopython3-ja.rdy.jp/index.htmlpip (RubyのgemやPerlのCPAN?)
http://d.hatena.ne.jp/rudi/20110107/1294409385Python基礎文法最速マスター
http://d.hatena.ne.jp/dplusplus/20100126/p1
コーディングスタイルPEP8(推奨されるコーディングスタイル)
Python には、ほとんどのプロジェクトが守っているスタイルガイドとして PEP 8 があります。それは非常に読み易く目に優しいコーディングスタイルを推奨しています。全ての Python 開発者はある時点でそれを読むべきです。ここに最も重要な点を抜き出しておきます:
インデントには空白 4 つを使い、タブは使わないこと。
空白 4 つは (深くネストできる) 小さいインデントと (読み易い) 大きいインデントのちょうど中間に当たります。タブは混乱させるので、使わずにおくのが良いです。
ソースコードの幅が 79 文字を越えないように行を折り返すこと。
こうすることで小さいディスプレイを使っているユーザも読み易くなり、大きなディスプレイではソースコードファイルを並べることもできるようになります。
関数やクラスや関数内の大きめのコードブロックの区切りに空行を使いなさい。
可能なら、コメントはコードと同じ行に書きなさい。
docstring を使いなさい。
演算子の前後とコンマの後には空白を入れ、括弧類のすぐ内側には空白を入れないこと: a = f(1, 2) + g(3, 4)。
クラスや関数に一貫性のある名前を付けなさい。慣習では CamelCase をクラス名に使い、lower_case_with_underscores を関数名やメソッド名に使います。常に self をメソッドの第 1 引数の名前 (クラスやメソッドについては クラス初見 を見よ) として使いなさい。
あなたのコードを世界中で使ってもらうつもりなら、風変りなエンコーディングは使わないこと。どんな場合でも、Python のデフォルト UTF-8 またはプレーン ASCII が最も上手くいきます。
同様に、ほんの少しでも他の言語を話す人がコードを読んだりメンテナンスする可能性があるのであれば、非 ASCII 文字も識別子に使うべきではありません。
導入
pyenvを使用して導入する。
gitが使える状態になっていること。
$ git clone https://github.com/yyuu/pyenv.git ~/.pyenv
$ echo 'export PYENV_ROOT="$HOME/.pyenv"' >> ~/.bash_profile
$ echo 'export PATH="$PYENV_ROOT/bin:$PATH"' >> ~/.bash_profile
$ echo 'eval "$(pyenv init -)"' >> ~/.bash_profile
$ exec $SHELL
$ pyenv install 3.4.3
$ pyenv global 3.4.3
$ pyenv rehash
zshを使用している場合、環境変数の設定を書き込むファイルは、~/.zshrc
にする。
pyenvのサイト上では、~/.zshenv
に書くように記載されているが、emacsの設定との
干渉があるのか、うまくpyenvが使えなかった場合があったので、暫定的に~/.zshrc
を利用。
pyenv rehashは、pipを使ってPythonパッケージを導入する際に
Pathの通っているコマンドとして導入されるものがある場合、実行が必要。
pyenv rehashを実行すると、コマンドへのパスが通る。
次のようなエラーが出る場合。
Ignoring ensurepip failure: pip ? requires SSL/TLS
以下を参考にDebianに必要パッケージを導入して解決。
Common build problems
https://github.com/yyuu/pyenv/wiki/Common-build-problems
sudo apt-get install -y make build-essential libssl-dev zlib1g-dev libbz2-dev \
libreadline-dev libsqlite3-dev wget curl llvm libncurses5-dev
pipを使うときに、pip自体ののアップグレードが必要とでる場合は、指示に従って
以下を実行しておく。
$ pip install --upgrade pip
$ pyenv rehash
Pythonスクリプトの実行
$ python sample.py
Pythonスクリプトを実行すると、スクリプトに書かれている上から順番に処理されていく。
他のプログラミング言語のように、mainといった関数は必要無い。
Unix/Linux系の環境の場合は、作成したPythonスクリプトsample.py
に実行権限がついており、またスクリプトの1行目にShebang(シェバン)
が書かれている場合、スクリプトを./sample.py
の形で直接実行できる。Windowsでは、Shebang
機能はないので、この実行方法は無理であるため、python sample.py
として実行すること。
最近のWindowsのPython 3系では、Shebangと同じ記述で、別の機構により同じようなことができるらしい。
$ ./sample.py
#!/usr/bin/env python
# -*- coding: utf-8 -*-
print("Hello Python!") # => Hello Python
Shebangとマジックコメント
Shebang(シェバン、シバン)
Unix/Linux系の環境では、スクリプトの1行目にShebangを記載しておき、スクリプト自体を実行することで、Shebang
に記載されたプログラム(例えばPython)を実行しそのプログラムに、スクリプトの内容を渡し動作させることができる。
つまり、上記のsample.py
を$ ./sample.py
のように実行すると、Shebang
によってpythonプログラムが実行され、pythonプログラムにsample.py
の内容が渡され、処理される。
マジックコメント
スクリプトの1行目もしくは2行目に、マジックコメントを記述することができる。
マジックコメントを記載する行の先頭には、そのスクリプト言語に対応したコメント文字を記述する。
# -*- coding: utf-8 -*-
マジックコメントには、そのファイル(ここでいうとsample.py
)内の文字エンコーディングを書いておく。
スクリプトが実行される際、pythonのインタプリタ(Python言語の記述を解釈して動作するプログラム)は、そのスクリプト内に記載されている文字が、指定された文字エンコーディングであることを期待する。
つまり、マジックコメント内にutf-8
という記載があると、Pythonのインタプリタは、スクリプトファイル内の文字のエンコーディングがutf-8
であると期待してスクリプトファイルを解釈しながら処理していく。
Python3では、デフォルトのエンコーディングとしてutf-8
を期待しているが、マジックコメントにSJIS
など任意のエンコーディングを記載することもできる。その場合、スクリプトファイル内に記載する文字を、SJIS
にしておく必要がある。この対応関係がずれると、スクリプト実行時にエラーが発生する。
※ 情報が古いかも。最近は、スクリプトのエンコーディングは、UTF-8に統一されてきているはず。(2017/01/02)
次の正規表現に一致すれば、マジックコメントとして扱われる。実際には、行の先頭に、コメントのための文字(Pythonでは#
)が必要となるが。
coding[=:]\s*([-\w.]+)
この正規表現は、次の意味で理解すれば良い。
- codingという文字がある
- codingの直後は、
=
か:
- 2.の直後に任意の個数のスペースがあっても、 無くても 良い
- 英字アルファベット、数字またはアンダーバー、(つまり [a-zA-Z_0-9])もしくは
-
で構成された1文字以上の文字が続く
# -*- coding: utf-8 -*-
上記はマジックコメントとして成立している。
エディタによるエンコーディングの解釈
エディタがファイルを開くときに、そのファイルのエンコーディングがわからないと
エンコーディング情報がずれてしまうので、正しく表示や書き込みができない。
エディタ(viやemacs)には、ファイルの1行目をチェック、該当しなければ2行目を見て特定の記述があれば、ファイル内の文字エンコーディングをその記述通りであると期待して取り扱う機能がある。
前述のマジックコメントと、この特定の記述(エンコーディングプラグマと呼ぶらしい)には共通している部分があるので、
マジックコメントを正しく記述しておけば、エディタもそのエンコーディングでファイルを開いてくれる。
まつもとさんの記事を引用します。
まつもとゆきひろ『プログラミング言語Ruby』を大いに語る
第7回 「M17N」が開く可能性
http://www.oreilly.co.jp/community/blog/2009/05/m17n-open-the-door-into.htmlエンコーディングが使えるようになったので、マルチバイト文字を使う時にはエンコーディングプラグマ、僕らはマジックコメントと呼んでいますけれど、「# -- coding: utf-8 -- 」と指定してやらないとエラーが出ることがあります。この「-*-」という記号はEmacsがファイルの文字コードが何かを調べる時に使う記号なので、これが付いているとEmacsにも分かるし、Rubyにも分かるという、一石二鳥になっています。
(略)
それでEmacsはこうやってコーディングを理解してくれるのだけど、vimは理解してくれなくて「fileencoding=utf-8」って書くんです。それでRubyの方はAdHocに「coding」の後に「[:または=]<エンコーディング名>」っていう並びがあるとエンコーディング名だと認識してくれます。最短だと「coding」だし「transcoding」とか全然違うこと書いても認識してくれます。馬鹿なんだか頭がいいんだかよく分からないんですが、
― よきに計らってくれるRubyってことですね。
頑張ってます。ただ、これはRubyが本家ってわけではなくて、Pythonでも同じことしてるんで。
#coding:utf-8
# -*- coding: utf-8 -*-
# vim:fileencoding=utf-8
- 1行目は、マジックコメントの書式の簡単なパターン
- 2行目は、Emacsのエンコーディングプラグマ書式
- 3行目は、vi(vim?)のエンコーディングプラグマ書式