はてなブックマーク

雑誌 Software Designさんから執筆依頼を頂いた。「Visual Studio Code の Jupyter Notebook実行機能を使ってPythonのテキスト処理などを学べる記事を」ということで、得意なテーマだしスケジュールに余裕のある時期でもあったので、けっこう気軽に引き受けさせていただいた。 この記事は、プログラミング初心者が雑誌を見ながらコードを一文字づつJupyter Notebookに写経して実行する、という読み方を念頭に執筆した。なので、文章を読みながら出てきたコードを入力し、Shift+Enter で実行できるように留意している。そこで、記事文章もJupyter NotebookのMarkdownセルで執筆し、解説とコードと実行結果をすべて Jupter Notebookだけで管理してみた。 せっかくVSCodeとJupyter NotebookをPytho

さて、質問です。 a = 1.0 a is 1.0 上記の処理で、a is 1.0 の結果は True となるでしょうか、それとも False となるでしょうか？ True と答えたあなた、不正解です。反省してください。 False と答えたあなた、同じく不正解です。猛省してください。 正解は 「わからない」 です。 Pythonインタープリタを起動して、対話的に実行してみましょう。 >>> a = 1.0 >>> a is 1.0 False False ですね。a に代入した float オブジェクトと、a is 1.0 で比較している float オブジェクトは、同じ値ですが異なるオブジェクトです。 でも、ちょっと書き換えて、同じ処理を関数の中で実行するとどうでしょう？ >>> def test(): ... a = 1.0 ... return a is 1.0 ... >>> t

math.prod() リストなどのイテレータの要素の積を計算する math.prod() が追加されました。 sum() の掛け算版ですね。 >>> import math >>> math.prod([1,2,3,4]) 24 正規表現が \N{名前} 記法をサポート reモジュールで、正規表現に文字の名前を指定する \N{名前} を使えるようになりました。 >>> re.match(r'\N{LATIN SMALL LETTER A}', 'a') <re.Match object; span=(0, 1), match='a'> >>> re.match(r'\N{GRINNING FACE WITH SMILING EYES}', '😁') <re.Match object; span=(0, 1), match='😁'> 文字の名前は、unicodedata.name()

拡張モジュールがリリースビルド/デバッグビルドで共用可能に これまで、デバッグ用にビルドされたPythonでは、Pythonのメモリ使用状況を調査するための機能 が有効になっていました。このため、リリース用にビルドされたPythonとデバッグ用にリリースされたPythonでは、内部のデータ構造が一部異なっており、拡張モジュールのバイナリもリリースビルド用とデバッグビルド用を別々に作成する必要がありました。 Python3.8のデバッグビルドではこの機能がオフになり、リリースビルド用の拡張モジュールをデバッグビルドでも利用できるようになりました。これまで、デバッグビルドのPythonで調査するときには使用する拡張モジュールもすべてデバッグビルド用に再構築していましたが、この作業が不要になりました。 拡張モジュールが共有ライブラリ版とスタティック版で共用可能に Pythonの構築方法には、Py

multiprocessing.shared_memory モジュールで、共有メモリを使ってプロセス間でデータを交換できるようになりました。似たような処理は mmap モジュールで実現できましたが、マルチプラットフォームで簡単に利用できるようになります。 Numpyの ndarray オブジェクトを複数のプロセスで共有する場合、まず最初のプロセスで次のように共有メモリを作成します。この例では、共有メモリの名前は "sharedmemory_test1" とします。 import math from multiprocessing import shared_memory import numpy as np SHAPE = (3,3) # 共有メモリ "sharedmemory_test1" を作成 size = math.prod(SHAPE) * numpy.dtype("float"

Python3.8の新機能で、これ一番好きかも。このためだけにPython3.8必須にしてもいい。 通常、 f文字列 に変数名や式を指定すると、その値が文字列に埋め込まれます。 >>> foo, bar = 10, 20 >>> print(f'value is {foo+bar}') value is 30 便利な機能ですが、デバッグ用にデータを出力するときには、ちょっと面倒です。たとえば foo と bar の値を確認するときは、確認したい変数名のテキストと、表示したい式を別々に書く必要があります。 >>> print(f'foo={foo} bar={bar} foo+bar={foo+bar}') foo=10 bar=20 foo+bar=30 そこで、f文字列に出力指定方法が追加され、出力したい式に続けて = を指定すると、その式と式の値の両方が文字列に埋め込まれるようになりま

Pythonでは、複雑なデータの交換や保管する場合、よく Pickleモジュール が使われます。Pickleはデータを外部に出力可能な形式に変換してファイルに変換したり、サーバと通信して送信したりします。 Pythonのconcurrent.futures や multiprocessing を使って並列処理を行う場合も、プロセス間のデータ交換に Pickle が使われています。 PEP-574 Pickle protocol 5 with out-of-band data Pickleは汎用的なデータフォーマットを定義していて、データを作成したハードウェアと異なるアーキテクチャのハード上で読み込んでも、ただしく元のデータを再現できるようになっています。 しかし、現在ではPickleの使い方は多様化しており、そういった汎用的なデータフォーマットだけでは効率的にデータの転送や保管を行えないこ

Python 3.0 以降では、関数を定義するときに、キーワード専用引数 を指定できるようになりました。 def func(a, b, *, c=1, d=2): return a+b+c+d こんなのですね。引数のリストに * がある関数を呼び出すとき、* の後ろにある引数の値は、かならずキーワード引数として指定しなければいけません。 ↑の関数だと、引数 c はキーワード引数で指定すればちゃんと動きます。 >>> func(1, 2, c=10) 15 しかし、キーワードなしで呼び出すとエラーになります。 >>> func(1, 2, 10) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: func() takes 2 positional arguments but 3

古来、Pythonでは「代入は文であるべき！」と一貫して主張してきました。 C言語などでは、代入は足し算や掛け算と同じ、値を計算する「式」で、たとえば a = (b=100) / 2; と書くと、b には 100 を代入し、a に 100/2=50 を代入します。1+1 は 2 という値になる 式 ですが、b=100 も同様に値が 100 となる 式 なのです。 Pythonでは、代入は式ではないので、こういう書き方はできません。 Pythonの代入は、足し算などの演算子の仲間ではなく、if や for のような制御文の仲間で、あまり自由な書き方は出来ないのです。 Python FAQ では、その理由として Python の式中での代入を許さない理由は、この構造によって起こる、他の言語ではありがちで見つけづらいバグです: if (x = 0) { // error handling } e

Python.jp Discordサーバ の運用を本格的に開始してから半年以上経ったので、感想など。 ユーザ層 Pythonのユーザ層いうとビジネス層というか、おっちゃんが多いイメージがあるのだか、Discordというゲームで広く使われているシステムなためか、アクティブな参加者は若年層・学生が多いようだ。Discordの利用規約で禁止されている小学生の存在が発覚して、ご退去いただいたこともある。 Discord bot また、プログラマやプログラマ希望者だけではなく、単にDiscordをチャットとして利用している人たちも多い。こういう人たちはプログラミングの知識はあまりないが、ゲームを楽しく遊ぶためのツールとして、Discordにいろんなbotを入れて活用している。そのうち、出来合いのbotでは満足できなくなって、自分なりのbotを作りたくなってきた人たちだ。 私は、この「Discord

これまで、python.jpではPythonの日本語ドキュメントを公開してきたが、この度、ドキュメントのホスティングを終了し、docs.python.org へのリダイレクトのみをおこなうようになった。 www.python.jp 実に喜ばしいことである。これまで、日本語ドキュメントは python.jp においてある私家版でしかなかったが、python.orgで公開されることで、一定の公式っぽさを得ることができる。 また、python.jpは私が一人でほそぼそと、さくらインターネットの一番安いVPSで管理運用してきた。しかし、これからはPython本家の運用チームできっちり運用していただけるのである。 別に難しいことをしていたわけではないが、python.jp運営のプレッシャーはちょっとしたものだった。ここ近年のPythonブームも、私がちょっとしくじってドキュメントを参照できなくなる、

たまに、「Pythonの高速化」なんてブログを見かけることがある。書いてあるのは、たいてい s = 0 for i in list_of_ints: s += i と書くより、 s = sum(list_of_ints) のほうが速い！なので sum() 使おう！とかだ。 たしかに、sum() は速い。Pythonインタープリタによるループの繰り返しを行わず、高速なC言語による処理が行われるためだ。特に、リストやタプルが引数に指定されている場合、さらに高速に実行できるように特別扱いされている。 100,000,000個の整数のリストで処理時間を計測してみると、for ループ版では 3.5秒、sum() 版では 2.2秒となった。すごい、2/3になった！forループ糞だな！ …どうだろう… まず、こういったサンプルプログラムは、極端に単純化されている。私はもう数十年に渡ってさまざまなプログラ

PyData.tokyo One-day Conference 2018 で登壇させていただきました pydatatokyo.connpass.com 発表資料 NumPyの歴史とPythonの並行処理 from Atsuo Ishimoto

これまで、python.jp ではSlackチームを用意していたが、こちらの利用は取り止めて、Discord に移行することにした。 書き込みはそれほどなかったものの、Python.jpチームには、約1000アカウントが登録されていた。そこそこな規模だろう。Slack->Discordへの大規模な移行としては Reactチーム の例があるが、こちらは別に Slack からなにかの制限を受けたというわけではない。 では、なぜDiscordに移行するかといえば、Slackというのはやはりオープンなコミュニティのチャットツールとしてはイマイチだと思うからだ。ReactさんのBlog にあるように、Slackのユーザ登録は面倒だし、複数のチームに所属する場合はそれぞれのチームでいちいちログインしなければならない。コミュニティ用のツールではないので特定ユーザのミュートやBanなどの機能もない。 また

Dell XPS 13 (9370) の全部入り( i7-8550U・4Kタッチパネル・1TB SSD ・16 GBメモリ) を購入した。 これまでのところ、思ったより使い勝手がよい。キーボードはいい感じだし、パームレストのカーボンファイバも触り心地が良い。 液晶は非光沢がなくて光沢のみということでターミナルの背景におじさんが出現する不具合が怖かったが、あまり気にならない。手元のMacBook Airと比べても遜色ない気がする。 Linux環境でのタッチパッドも、設定でかなりまともに使えるようになった。 ← 後述のとおり、16.04ではダメだったので17.10に切り替えた 以下作業メモ 事前準備 どっちにしろWindows 10 Proをインストールするので、プリインストールのWindows 10 Homeは潔くパーティションごと削除。 UbuntuとWindowsのインストール用USBを

さて、 リスト内包のひみつ - atsuoishimoto's diary で、Python3では、リスト内包式は関数呼び出しとなることを説明した。 >>> a = [i*2 for i in range(3)] というスクリプトは、次のように展開される。 >>> def _listcomp(_it): ... ret = [] ... for i in it: ... ret.append(i*2) ... return ret ... >>> _it = range(3) >>> a = _listcomp(it) 通常、この点はあまり気にする必要はないが、問題となるケースもなくはない。 クラスブロックのリスト内包 クラスブロックで次の処理を実行してみよう。 class Foo: NUMS = [i*2 for i in range(3)] まあ、これは当然動作する。Foo.NUMS

こちらのTweetが Python.jp slack でちょっと話題になっていた。 どういうこと？ pic.twitter.com/BxyyWbyvQo— ahuglajbclajep (@ahuglajbclajep) 2018年1月24日 次のようなコードだ >>> a = [lambda: print(i) for i in range(3)] >>> for i in a: i() 2 2 2 結論としては cocoatomo さんの書かれているように、変数の評価タイミングの問題で、 初めまして. そこは Python のループでよくハマるポイントで, i の値の評価が後で行われるのが混乱の原因です. ループの本体の中で一度 i を別の変数に入れるなどして, 評価を走らせると回避できます. FAQ → https://t.co/5iCqdIIhUZ— tomo🐧 (@cocoat

bicycle1885.hatenablog.com こちらの記事を拝見していて、ちょっと気になったので注釈。 PythonやRを使っている人で、ある程度重い計算をする人達には半ば常識になっていることとして、いわゆる「for文を使ってはいけない。ベクトル化*1しろ。」という助言があります。 これは、PythonやRのようなインタープリター方式の処理系をもつ言語では、極めてfor文が遅いため、C言語やFortranで実装されたベクトル化計算を使うほうが速いという意味です。 昔からよくこういう言い方がよくされるが、本当にPythonのfor文は遅いのだろうか。 聞くところによるとRのfor文はガチで遅いそうだが、Pythonの計算が遅いのはインタープリタ方式だからでも、for文が遅いからでもない。もちろん、Pythonはインタープリタなので遅いし、for文だって極めて遅い。しかし、これはPyt

最近、偶然プログラミング初心者に接する機会が続いた。初心者にもいろいろあるが、中でも印象深い女性のことを思い出したので書いておきたい。 大昔、ちょっとした業務改善のシステムを開発することになって、実際にその業務を行っている事務や経理の方々に話を伺ったことがある。 この時お会いした年配の女性が、すさまじいほどのExcelのエキスパートだった。当時のPC環境はまだまだ原始的で、動作も不安定だったが、彼女は独学でExcelマクロを開発し、かなりの業務の自動化に成功していた。 話を聞いてみると、とくにプログラミングの勉強をしたことはなく、本を数冊読んだ程度で、あとはExcelのヘルプだけを頼りにマクロを組み上げたらしい。まだインターネットもさほど普及していない時代だ。ほぼ自分の頭だけで考えて、ここまでたどり着いたのだろう。素晴らしい出来栄えだった。 一番驚いたのは、彼女が重要なソフトウェア工学の原

最近何度か名前を目にした Webアプリケーションフレームワーク API Star を試してみた github.com まだ開発中のフレームワークだが、Pythonの型アノテーションをうまく利用して、Web APIを簡単に開発できるようになっている。 インストール githugからソースをダウンロードして実行してみた $ git clone https://github.com/encode/apistar.git $ pip install -e . アプリケーションの作成 apistar コマンドでひな形を作成する。 $ apistar new test test/app.py test/tests.py アプリケーションの実行 作成した app.py を実行する。 $ python app.py start * Running on http://127.0.0.1:8080/ (Pr

ここ数年、www.python.jp は、 Pelican を使って構築していた。 Pelican は実績のある静的サイトジェネレータで使いやすくはあるが、基本的にはBlogサイトの構築ツールであり、あまり柔軟性や拡張性には重点を置かれていないように感じていた。www.python.jp 以外でもいくつかのサイト構築に使用したが、以下のような不満を感じていた。 アーティクルに Jinjaテンプレートを書きたい reStructuredTextやMarkdown には、定型文などを記述するため手段として、エクステンションやディレクティブなどを開発して組み込む仕組みがあるが、開発・管理はそれなりに面倒で、そう気軽には作れない。Jinjaのマクロ機能などを使って、手軽に拡張できる仕組みがほしい。 アーティクル全体を検索するAPIがない。このため、Blogサイトなどでよくある、サイドバーに「最近の

宣伝が続いて恐縮だが、オライリージャパンよりPythonの解説書を上梓した。昔から、Python内部の仕組みも解説したPython解説書を書きたいと思っていて、ようやく実現した感じだ。 しかし、本書の執筆は、昔、構想を立てていたときに思っていたほどは楽しくはなかった。Python2ではなく、Python3.3以降を対象に書いてしまったからだ。Python3の型システムは綺麗に整理されてしまったし、メタクラスも扱いやすくなった。メモリアロケータは改善され、ガベージコレクションの注意点も大幅に減った。Unicodeの暗黙の変換も無くなった。私が書こうと思っていた知識の多くは、Python3では無用の長物と化した。 本書をPython2向けに書いていたら、今よりずっと多くのページ数を費やしただろう。Python3は、Python2よりも落とし穴が少なく、学習も容易なプログラミング言語だ。 そんな

What's new in Python 3.6 from Atsuo Ishimoto

Python 3.6では、長年に渡って使われてきた、Python の基本的な実装に関わる部分で、重要な変更が行われている。 辞書オブジェクトのレイアウト変更 Raymond Hettingerのアイデア を元に、稲田さん が実装したもので、古くから使われてきたPythonの辞書オブジェクトが修正され、よりメモリ効率の良い形式でデータを格納するように変更された。 この修正により、辞書オブジェクトのメモリ使用量が20〜25%程度改善されている。 バイトコードからワードコードへ Pythonインタープリタは、ソースコードを バイトコード と呼ばれる中間言語に変換し、実行する仕組みになっている。従来、バイトコード はその名の通り8bit長のデータの集まりだったが、Python3.6では、バイトコードのサイズは8bitから16bitに拡張された。 これまでのバイトコードでは 命令コード+可変長の引数

ファイルシステムパス プロトコル pathlib はPython3.4で導入されたが、pathlibで表現されるファイルパスは、 open() やos.path.* などの、既存のファイル操作関連関数では使用できないため、あまり便利には使えていなかった。 Python3.6からは、pathlib.Path などのファイルパスをあらわすオブジェクトに特殊メソッド __fspath__() が実装された。ファイル名を引数として受け取る、open() などの関数は、__fspath__()を呼び出して、ファイルパスを取得するように変更された。 >>> import pathlib >>> spam = pathlib.Path('./spam') >>> spam.__fspath__() 'spam' >>> open(spam, 'w') <_io.TextIOWrapper name='s

クラス定義のカスタマイズ これまで、Pythonのクラス定義をカスタマイズする手段として、メタクラスが使われてきた。しかし、メタクラスを利用したカスタマイズは、Pythonのオブジェクトモデルや型システムの知識が必要で実装が難しく、また複数のメタクラスを同時に使用するのが難しい、などの問題点があった。そこで、PEP 487 -- Simpler customisation of class creation では、メタクラスを使わずにクラスをカスタマイズする手段を提供している init_subclass() メソッド クラスのサブクラスが作成されたときに呼び出され、引数として、派生クラスと、クラス定義の引数が渡される。__init_subclass__()メソッドは、自動的にクラスメソッドとなる。 class Spam: def __init_subclass__(cls, **kwarg

非同期ジェネレータ 現在のPythonでは、ジェネレータを使って、とてもお手軽にイテレータを作成できる。例えば、奇数列を生成するジェネレータは、次のように書ける。 def odds(): i = 1 while True: yield i i += 2 しかし、ジェネレータが存在しなかった頃のPythonでは、わざわざ__iter__メソッドなどの特殊メソッドを実装したクラスを定義し、 class Odds: def __init__(self): self._cur = 1 def __iter__(self): return self def next(self): ret = self._cur self._cur += 2 return ret などと書かなければならなかった。 Python3.5で導入された コルーチン は、イテレータと同様な概念として 非同期イテレータ をサポー