Python 3.8 の概要 (その5) - デバッグ用 f文字列フォーマット - atsuoishimoto's diary
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 3.8 の概要 (その1) - Assignment expressions - atsuoishimoto's diary
古来、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
BeProudでの仕事を終えて - atsuoishimoto's diary
昨年11月から参加させていただいていた BeProud でのプロジェクトは6月いっぱいで一区切りということになり、私のBeProudでのバイトもいったんお休みということにさせていただいた。 当初は3月ぐらいまでという予定だったのだが、プロジェクトの都合と、居心地の良さもあってついつい長居してしまった。Pythonを学びたい人、思う存分Python力を振るいたい人には素晴らしい環境だったと思う。 この8ヶ月、shacho をはじめ BeProud の皆様には大変お世話になりました。お陰でとても楽しい日々を過ごすことができました。本当にありがとうございました。 さて、今後の予定についてはまだ未定だ。しばらくはダラダラする、というのは決めているが、それ以外はなんにも決めていない。これからやりたいこと、やりたくないことというのはなんとなく見えているのだが、具体的にどんな活動をしたものか、具体的なイ
mockはこう使え - atsuoishimoto's diary
最近、Mockライブラリ http://www.voidspace.org.uk/python/mock/ を使ってみたのでメモ。 このライブラリは、その性質上、動的にメソッドや属性を作成するケースが多く、普通のPythonライブラリのようにイントロスペクションに頼って使い方を調べるのは難しい。本気で使うならまじめにドキュメントを読み込む必要がある。 関数の置き換え テスト中に呼び出される関数をMockで置き換える例。ここでは、関数 myapp.utils.func1() を置き換える。 from mock import Mock import myapp.utils # myapp.utils.func1 を、常に100を返す関数に置き換える myapp.utils.func1 = Mock(return_value=100) 戻り値が定数でない場合は、Mock()にside_effec
The Zen of Python 解題 - 前編 - atsuoishimoto's diary
The Zen of Python, by Tim Peters Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Complex is better than complicated. Flat is better than nested. Sparse is better than dense. Readability counts. Special cases aren't special enough to break the rules. Although practicality beats purity. Errors should never pass silently. Unless explicitly silenced. In
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
