Python

singledispatch PEP 443 – Single-dispatch generic functions single-dispatch generic functions : form of generic programming 記事 Generic Function in Python with Singledispatch

Python: Exception Python Exceptions: An Introduction 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 try: # 処理 linux_interaction() except AssertionError as error: # 例外 print(error) else: ## 例外がない場合 try: with open('file.log') as file: read_data = file.read() except FileNotFoundError as fnf_error: print(fnf_error) finally: # 最後に必ず実行 print('Cleaning up, irrespective of any exceptions.') Python Exception Base Classes 組み込み例外 8.6. ユーザー定義例外

HttpRequest.encoding django.http.request.HttpRequest cgi.parse_header で、Content-Typeヘッダーから content_type と content_params(dict) を取得。 conent_paramsに charset が入っている可能性がある codecs.lookup を使って、charset の存在を確認。 存在したらHttpRequest.encodingプロパティに設定する 実態は, HttpRequest._encoding

BOM(byte order mark) ファイルの先頭3バイトが ‘EF BB BF’ の UTF-8 rest_framework_csv rendererで、 コンテキストの encoding を判定している encodingに utf-8-sig を 指定する viewset: get_renderer_context をオーバーライドする 1 2 3 4 5 6 7 8 9 10 11 def get_renderer_context(self): """(override)""" context = super().get_renderer_context() # ここで、以下の条件の時に utf-8-sigにセット # 1) text/csv を求めている # 2) utf-8 でエンコードが指定されている(デフォルト) if self.request.META.get('HTTP_ACCEPT', '').startswith('text/csv'): context['encoding'] = 'utf-8-sig' return context 記事 bom付きutf-8に変換するnkfコマンド PythonでUTF-8 with BOMを開く Declaring character encodings in HTML The byte-order mark (BOM) in HTML Accept-Encoding HttpRequest.META

https://www.music.mcgill.ca/~gary/306/week9/osc.html http://opensoundcontrol.org/ https://pypi.org/project/python-osc/ https://techracho.bpsinc.jp/katayama-yuuki/2017_07_13/42884 https://github.com/colinbdclark/osc.js https://github.com/ValdemarOrn/SharpOSC

$ sudo yum install graphviz-python graphviz-devel $ pip install pygraphviz

Google Maps API googlemaps/google-maps-services-python Google Geocoding API で住所から緯度経度を求める

https://pythonhosted.org/vcs/api/index.html https://pypi.python.org/pypi/RhodeCode https://code.rhodecode.com/ RhodeCode Requirements Waitress WSGI server [WebOb provides wrappers around the WSGI request environment, and an object to help create WSGI responses.](WebOb provides wrappers around the WSGI request environment, and an object to help create WSGI responses.) FormEncode validates and converts nested structures.

サバクラ両方で動く JavaScript の大規模開発を行うために 原文：Scaling Isomorphic Javascript Code (This is just for study, please contact me at tily05 atmark gmail.com if any problem.) 考えてみれば Model-View-Controller とか MVC ってよく聞くよね。実際どんなものか知ってる？ 抽象的に言うなら「オブジェクト情報の保持されるグラフィック・システム (つまり、ラスターではないグラフィック。ゲームとか) 上に構築された、表示系を中心としたアプリケーションにおいて、主要な機能どうしの関わりをうまく分離すること」とでも言おうか。もう少し深く考えを押し進めてみれば、これは当然、他のさまざまなアプリケーションにもあてはまる言葉 (bucket term ?) だ。 過去に多くの開発コミュニティが MVC による解決案を提供し、それによってよくあるユースケースにうまく対処し、地位を築くことができた。例をあげるなら、Ruby や Python コミュニティは Rails や Django を作り、MVC アーキテクチャを実現した。 こうした手法は Java, Ruby, Python といった他の言語では容易に受け入れらてきたが、Node.js について十分ではない。理由は単純で、それはただ、JavaScript が今や isomorphic な言語であるからだ。isomorphic というのは「ソースコードのどの行 (もちろん注目すべき例外もあるが) をとってみても、クライアント・サーバーの両方で実行できる」ということを意味している。表面的には無害に見えるが、この特徴のせいで現状の MVC ベースのパターンでは解決できない課題がたくさんある。 この記事では、まず現存するパターンをいくつか取り上げ、いかにそのようなパターンに関する実装や心配事が言語や環境に関わらず普遍的なものとなり得たか、そのようなパターンがどうして真に “isomorphic” な Javascript のソースコードにはあまり適していないのかを述べる。そして結論として、新しいパターン “Resource-View-Presenter” について述べる。 目次 デザインパターンは、アプリケーションの開発にとってなくてはならないオマンマのような存在である。アプリケーションやその環境についてのさまざまの心配事をカプセル化し、うまくまとめてくれる。ブラウザとサーバの間でこんなにもさまざまの心配事があるからね： View を作るとして、(たとえばサーバ側で) 一時的にしか存在しないのか、(たとえばブラウザ側で) 永続するべきものなのか？ View を作るとして、複数のユースケースやシナリオの間で再利用可能なものか？ View を作るとして、アプリケーション特有のタグやマークアップが使われているか？ ビジネスロジックをどこに記述すべきか？ (Model なのか Controller なのか) アプリケーションの持つ状態はどのように保持されアクセスされるのか？ 現存するパターンを取り上げ、上記の問題がどのように解決されているのか見てみよう： ...