はてなブックマーク

記事を移転しました。今後ともどうぞ、よろしくお願いいたします。 https://python.ms/map-filter/ 以下、旧版 map リストの各要素に関数を適用します。 filter リストの各要素のうち条件に満たないものを削除します。 1. map リストの各要素に関数を適用します。 # リストの各要素を二乗します。 def double(x): return x * 2 lst = [1, 2, 3, 4, 5, 6, 7] for e in map(double, lst): print(e) # 2 # 4 # 6 # 8 # 10 # 12 # 14 2. filter リストから条件を満たす要素だけを取り出します。 # 偶数だけ取得します。 def is_even(x): return x % 2 lst = [1, 2, 3, 4, 5, 6, 7] for e i

Python で割り算をするときの繰り上げと切り捨てについて、説明させていただきます。 ３つのやり方があります。 1. 演算子のみを使う。 これがオススメ。欠点は、切り上げが伝わり辛い。利点は、表記が簡潔で実行速度が 10 倍速く、何も import しなくていい。 # 切り捨て 4 // 3 # 切り上げ -(-4 // 3) ∀Programmer ∃Python 2. math モジュールを使う。 オススメしない。利点は、切り上げが伝わりやすいこと。欠点は、表記が冗長になり 10 倍遅く、math を import しないといけない。 import math # 切り捨て math.floor(4 / 3) # 切り上げ math.ceil(4 / 3) 3. int モジュールを使う。 オススメしない。利点は、無い。整数であることを強調したい時は、有効だと思います。欠点は、表記が冗

ひとりごと。色々、漁ってると、こんな雰囲気。 並行処理で もっと高速に書きたい → Go シングルマシンで もっと高速に書きたい → Rust ◯ 用途 Rustと競合？ - Goへの誤解について 似てるのは例外機構を捨てたこととバイナリがポータブルなことぐらい。得意な用途は全く異なります。... Go は非同期処理をシンプルに書きつつマルチコア性能を引き出すのが強みです。 Rust は徹底してオーバーヘッドを排除してシングルコアの限界性能を引き出せるのが強みです。... これらの強みが関係ない分野だけが競合しています（CLIツールなど）。 ◯ Go が採用された例 隠れマルコフモデルという統計機械翻訳のアルゴリズムを使ってC++で実装されていた機械翻訳エンジンを、 パフォーマンスを上げるために並列処理が得意なGo言語に書き換えるという仕事をいただきました。 サンフランシスコで創業したスタ

クラスオブジェクトは、 クラス定義を抜けると生成されるオブジェクトです。 インスタンスオブジェクトは、 クラスオブジェクトからインスタンス化されるオブジェクトです。 class GirlFriend(object): def __init__(self, name): self.name = new_name GirlFriend # <- これはクラスオブジェクトが代入されている。 girl_friend = GirlFriend('サーバルちゃん') girl_friend # <- これはインスタンスオブジェクトが代入されている。 いまいちピンと来ないので、もう少し掘り下げて見たいと思います。Python でオブジェクトと言えば、関数と値をひとつにまとめたものです。この文章では Python のオブジェクトの仕組み、そのものについて取り扱っています。 疑問: インスタンスオブジェクト

get を使わない。 原則、副作用の無く新たにオブジェクトを生成しない関数, メソッドは原則「名詞」を使うのが望まい。 # x noun = obj.get_noun() # o noun = obj.noun() 感動した記事 Getter/Setterは悪だ。以上 もし get がダメなら、give ならどうだろう、とか考えてしまった笑 obj がすでに持っているオブジェクトを get しろというのは、文章としておかしい。ならば tell とか give ならと思った。 確かにそれっぽいけど。最終的に値を生成した関数やメソッドは、例えば create_new_user() みたいなのも create して tell が入ってるけど その tell は省略されてるから tell, give みたいなのは省略するのがいい感じかな.. そんなコードみたことないし obj.noun() が妥当

簡単に言えば... 値を変更できるオブジェクトのことを mutable と呼びます。 Objects whose value can change are said to be mutable; 値を変更できないオブジェクトのことを immutable と呼びます。 objects whose value is unchangeable ... are called immutable. 3. Data model — Python 3.5.6 documentation ◯ mutable なオブジェクト 例えば、list 型、 dict 型、普通にユーザが定義したクラスは mutable です。 ユーザ定義クラス class Person(): def __init__(self, name): self.name = name person = Person('yaruo') per

render と render_to_response は、いずれも HttpResponse オブジェクトを返すショートカットのラッパーメソッドです。 ポイント 大きな違いは HttpRequset クラスの request オブジェクトをどのように渡すか渡さないかにあります。 ① 書き方の違い view.py で動作を比較したいと思います。次の３つのメソッド view_method1 と view_method2, view_method3 は、"だいたい" 同じ動作をします。 render メソッドを使ったほうが可読性が上がりそうですね。 # request を template にいれています。 def view_method1(request): template = loader.get_template('app_name/template_name.html') conte

大きく書き換えました。 主な変更点は次の 8 点です。 1. Vim → Neovim 2. 新規採用 → pycodestyle 3. 新規採用 → pydocstyle 4. NeoBundle → dein.vim 6. 新規採用 → deoplete.nvim 7. jedi-vim → deoplete-jedi 8. virtualenv → 削除（分離が可能になったので venv に更新し 別立て） Neovim は Vim の後継機みたいなものです。 旧版 作業が完了すると vim は、次の３つの動作をするようになります。 ① 構文の色付け ② 構文チェック Syntastic pyflakes invalid syntax の指摘 ③ 自動補完 jedi-vim 作業 大まかに分けて、これから次の６つのものを追加、インストールします。 項番 名前 説明 Step1 vim

結論 10,000行以上ならドメイン駆動モデルによる静的言語。 10,000行以下ならMVCモデルによる動的言語。 注意 とても乱暴な数字ですが、イメージをつけやすくするために 10,000行とする考えを採用させていただきました。 表１．結論 項番 項目 静的 動的 1 開発速度（大規模） O X 2 開発速度（中規模） O O 3 開発速度（小規模） X O 開発速度としては、つぎのような感じで場合分けして軍配があがります。この人の記事は、使い分けも、含めて書いてくれてるのでありがたいです。 まとめ Java と Python 両方使える人は 小規模のとき Python 中規模のとき 開発スピード重視なら Python 作り込みが必要なら Java 大規模のとき Java という風に使い分けてもいいんじゃないでしょうか。 Python と Java で AppEngine アプリを開発し

課題 Python で開発したアプリをソースコードを閲覧されないように配布したい。 方針 pyc でのみ構成されるファイルを egg にまとめる。 installing only .pyc (python compiled) with setuptools - Stack Overflow 上記方針の問題 完璧に閲覧されないようにするのは、ほぼ無理だと思われる。 licensing - How do I protect Python code? - Stack Overflow decompile ツールもあるため、容易に解析されてしまう様子。 Is it possible to decompile a compiled .pyc file into a .py file? Decompile Python 2.7 .pyc - Stack Overflow tools - Decompi

こちらをオススメします。 以下の記事は古いです。 Django の User モデルは、そのまま継承することはできません。 この理由は User モデルは Auth というデフォルトでついているアプリ内のモデルだからです。なので、アプリ内のモデルを拡張してあげればいいのですが、もとになる機能なので直接は触らせてくれ無いと言う訳です。 解決策 Case 1. Django 1.4 以前の場合 → User と OneToOneField の関係にあるモデル(ex, UserProfile)を作成する。 Case 2. Django 1.5 以降の場合 → AbstractUser を継承させたモデルを使う。 Case 1. Django 1.4 以前の場合 やり方としては、 Step1. User と OneToOneField の関係にあるモデル(ex, UserProfile)を作成する