Google Translate APIを使ったSphinxドキュメントの自動翻訳
多言語への翻訳は大変な作業ですが、近年は機械翻訳の精度も上がってきました。
ふと思いついて .po 形式の翻訳ファイルをGoogle翻訳を通して自動で入力するスクリプト を作ったのですが、サクッと書いた割に予想以上に便利で料金も思ったより安かったので記事にしました。また実際に自分が公開している日本語で書かれたSphinxの資料を、このスクリプトを使って英語に翻訳してみます。
追記: ライセンスについて
id:beatdjam さんのコメントが気になったので共有です。 自分もGoogle Translate APIのドキュメントを読み返してみますが、利用される方も確認してからご利用ください。
以前こういった事例もあったので、OSSで利用することを推奨して良いのか心配。ドキュメントだけなら平気なのかな https://anond.hatelabo.jp/20170225195916
作ったもの
.po 形式の翻訳ファイルをパースし好きな言語にGoogle Translate APIを用いて翻訳するスクリプトを用意しました。
実行には google-cloud-translate とGCP service accountが必要です。
$ pip install --upgrade google-cloud-translate $ export GOOGLE_SERVICE_ACCOUNT_JSON=/path/to/service-account-credential.json $ python translate_po.py --help usage: translate_po.py [-h] [--lang LANG] [--currency CURRENCY] filepath positional arguments: filepath optional arguments: -h, --help show this help message and exit --lang LANG target language (default: "ja") --currency CURRENCY dollar per your currency. (default currency is yen: 111.90)
現状はとりあえずファイルの上書きオプションなどは用意せず、stdoutに書き出すようにしています。 Google Translate APIは、100万文字あたり20ドルかかります。 本一冊とかになると数百円かそれ以上かかりそうですが、手元の文章を翻訳したいなどの用途なら数十円に収まることがほとんどです。 ちなみにマルチバイト文字でも1文字は1文字としてカウントしてくれるようなので、日本語から英語の翻訳などは比較的お得です。 Google Translate APIに投げたテキストの文字数からかかった金額も算出し表示するようにしています。
$ python translate_po.py ./po/index.po 1>./po/index_ja.po Cost: 2.1417659999999996 yen
また翻訳結果はキャッシュしていて、実行したディレクトリの直下に json ファイルを書き出します。 なので2回目の実行は、キャッシュが効きお金を節約できます。
$ python translate_po.py ./po/index.po 1>./po/index_ja.po Cost: 0 yen
実際に翻訳してみる
Webアプリケーションフレームワークの作り方 in Python — c-bata.link (Githubはこちら) はSphinxで書かれた日本語の資料です。 今回はこちらを英語に翻訳していきます。Sphinxのドキュメントの国際化の方法は次のページに非常によくまとまっています。
まず sphinx-intl をインストールします。
$ pip install sphinx-intl $ vim source/conf.py # add following settings # locale_dirs = ['locale/'] # gettext_compact = False $ make gettext $ ls build/locale/ index.pot kobin.pot middleware.pot request.pot response.pot routing.pot server.pot sphinx.pot template.pot wsgi.pot
potファイルができました。今回は日本語から英語に翻訳するので、次のようにします。
$ sphinx-intl update -p build/locale -l ja Create: source/locale/ja/LC_MESSAGES/kobin.po Create: source/locale/ja/LC_MESSAGES/template.po Create: source/locale/ja/LC_MESSAGES/middleware.po Create: source/locale/ja/LC_MESSAGES/sphinx.po Create: source/locale/ja/LC_MESSAGES/request.po Create: source/locale/ja/LC_MESSAGES/routing.po Create: source/locale/ja/LC_MESSAGES/wsgi.po Create: source/locale/ja/LC_MESSAGES/response.po Create: source/locale/ja/LC_MESSAGES/index.po Create: source/locale/ja/LC_MESSAGES/server.po
poファイルが出来上がったら変換をかけます。 このスクリプトは今のところ上書き用のオプションを用意していないので、一度stdoutをファイルに書き出して置き換える必要があります。 いくつかファイルがあるので変換用のスクリプトを用意しました。
$ cat > translate.sh <<EOF
#!/bin/bash
function translate {
for f in ./ja/LC_MESSAGES/*.po; do
python translate_po.py --lang en $f 1>${f%.po}_en.po
mv ${f%.po}_en.po $f;
done;
}
translate
EOF
$ chmod +x ./translate.sh
$ ./translate.sh
Cost: 3.6904620000000006 yen
Cost: 0.024617999999999998 yen
Cost: 1.60017 yen
Cost: 4.728894 yen
Cost: 3.8784539999999996 yen
Cost: 5.8188 yen
Cost: 1.087668 yen
Cost: 1.4009880000000001 yen
Cost: 7.00494 yen
トータル30円くらいかかりました。翻訳精度を考えるとすごくお得に感じます。 最後はこれをbuildしてみましょう。
$ make -e SPHINXOPTS="-D language='ja'" html $ open build/html/index.html
結果は次のような感じです。
reSTのリンクが壊れたり、いくつか変な文字が混ざっていたりはしますが予想以上にそれっぽくなりました。
エキスパートPythonプログラミング 改訂2版 (アスキードワンゴ)
- 作者: Michaｌ Jaworski,ＴａｒｅｋＺｉａｄｅ,稲田直哉,芝田将,渋川よしき,清水川貴之,森本哲也
- 出版社/メーカー: ドワンゴ
- 発売日: 2018/02/26
- メディア: Kindle版
- この商品を含むブログを見る
Double forkによるプロセスのデーモン化と、ファイル変更時の自動サーバーリロードの実装 (Python)
Pythonで約100行のシンプルなWSGIサーバーを書いてみる - c-bata web でWSGIサーバーを作ってみました。 100行程度の非常に簡易的なものでしたが、実際にDjangoアプリケーションを動かすこともできました。 前回作ったWSGIサーバーをもう少し便利に使えるようにいくつか機能を追加したのですが、 その中でもWSGIサーバーに限らず知っておくとよさそうな3つの実装を紹介します。
目次:
- Double Fork によるサーバープロセスのデーモン化
- Pythonファイルの更新に検知してサーバーを自動で再起動する
- 文字列で指定したPythonオブジェクトを動的に読み込んで実行する方法
- 謝辞
Double Fork によるサーバープロセスのデーモン化
WSGIサーバーのように長時間動かすようなプログラムはデーモン化しておきたい場合があります。gunicornでも daemon オプションが用意されていて設定で簡単に切り替えることができます。
ところでバックグラウンドで実行するだけなら端末上でコマンドを入力した後に & をつけることもできます。
デーモン化とはなにか違うのでしょうか。少し試してみましょう。
$ python3.7 -m http.server 8000 & [1] 37682 a14737: ~ $ Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ...
この例では & をつけたことでバックグラウンドになり、別のコマンドを実行できる状態になりましたが、標準ストリームはまだ繋がっていてプロセスの出力が表示されてしまっています。例えば localhost:8000 にアクセスしてみると 127.0.0.1 - - [29/Sep/2018 22:51:32] "GET / HTTP/1.1" 200 - のログがこの端末上に流れます。これ以外にもいくつか問題が残っていて、プログラムによってはSSH接続を切ったときに送られる SIGHUP を受け取ると終了してしまいます。デーモン化というのはこのようにただバックグラウンドにするわけではなく、プロセスから制御端末(tty)を完全に切り離します。
制御端末からプロセスを切り離すために有効なのは setsid() システムコールです*1。これについて知るためにはプロセスグループやセッションという概念を理解しておく必要があります。ただぐぐると詳しい記事が出てくるので詳しい説明はそちらにおまかせします *2。
サーバーにログインすると、ログインセッションが作られます。このセッションのリーダーであるプロセス1つが制御端末(tty)とやり取りを行います。システムコール setsid() を呼び出すと新しいセッションを作成しそのセッショングループのリーダーになります。ここで作成されたセッションはまだ制御端末(tty)を取得していないのでプロセス上に制御端末がなくなったことになります。ただこのとき2つ注意点があります。
- もし
setsid()システムコールを呼び出したプロセスが、プロセスグループリーダーだった場合はエラーが返ってきます。 setsid()を呼ぶことで新しいセッションのセッショングループリーダーになりますが、セッショングループリーダーは唯一制御端末とやりとりすることが可能です。プログラムの実装によってはあとで制御端末を取得してしまうかもしれません。
下図に示す「double fork」と呼ばれるテクニックを利用することでこの2つの懸念が解消されます。
double fork の名の通り、2回 fork(2) を呼び出します。
- 最初に子プロセスを生成した後、親プロセス側で
sys.exit(0)を呼びすぐに終了する。子プロセス側は必ずグループリーダーではないため、setsid()システムコールが呼び出せます。 - 子プロセス側で
sys.setsid()を呼び出し、セッショングループリーダーになり制御端末から切り離します。しかしこの子プロセスはセッショングループリーダーです。さらに孫プロセスを生成し、セッショングループリーダーである子プロセスを終了してしまえば、このセッションに制御端末が取得されることはありません。
ソースコードは次のとおりです。
# https://github.com/kobinpy/kwsgi/pull/2 def daemonize(): """Detaches the server from the controlling terminal and enters the background.""" if os.fork(): # Exit a parent process because setsid() will be fail # if you're a process group leader. sys.exit(0) # Detaches the process from the controlling terminal. os.setsid() if os.fork(): sys.exit(0) # Continue to run application if directory is removed. os.chdir('/') # 0o22 means 755 (777-755) os.umask(0o22) # Remap all of stdin, stdout and stderr on to /dev/null. # Please caution that this way couldn't support following execution: # $ kwsgi ... > output.log 2>&1 os.closerange(0, 3) fd_null = os.open(DEVNULL, os.O_RDWR) if fd_null != 0: os.dup2(fd_null, 0) os.dup2(fd_null, 1) os.dup2(fd_null, 2)
Pythonファイルの更新に検知してサーバーを自動で再起動する
開発用途のサーバーとしては、ファイルの更新を検知して自動でサーバーが再起動してくれると便利そうです。 これは実装が少しだけ複雑ですが、面白い実装になっています。 ソースコードも少し長くなるので細かい解説までは今回は省くことにしましたが、ソースコードにコメントを多めに入れたので読んでみてください。 このプログラムのポイントは次のあたりです。
- Pythonが読み込んだモジュールのファイル一覧と最終更新時刻を取得する
sys.modulesから読み込んでいるモジュールの一覧を取得getattr(module, '__file__')を読み出し、os.path.existsでファイルの存在をチェックos.stat(path).st_mtimeより最終更新時刻を取得する。
- 呼び出しコマンドをサブプロセスでもう一回実行してWSGIサーバーを実行するワーカープロセスを生成する
- メインプロセスとワーカープロセスのやりとりは
tmp領域に作成したファイルを経由して行う
import os import sys import threading import time import _thread import subprocess import tempfile # For reloading server when detected python files changes. EXIT_STATUS_RELOAD = 3 class FileCheckerThread(threading.Thread): def __init__(self, lockfile, interval): threading.Thread.__init__(self) self.daemon = True self.lockfile, self.interval = lockfile, interval self.status = None # 'reload', 'error' or 'exit' def run(self): files = dict() # sys.modules からPythonモジュールの一覧を取得 for module in list(sys.modules.values()): # __file__ が定義されていればそこからファイルパスが取得できる。 path = getattr(module, '__file__', '') if path[-4:] in ('.pyo', '.pyc'): path = path[:-1] if path and os.path.exists(path): files[path] = os.stat(path).st_mtime while not self.status: # lockfile が削除 or 更新されていたら status を 'error' にして例外をraiseして通知する. if not os.path.exists(self.lockfile) or \ os.stat(self.lockfile).st_mtime < time.time() - self.interval - 5: self.status = 'error' _thread.interrupt_main() for path, last_mtime in files.items(): if not os.path.exists(path) or os.stat(path).st_mtime > last_mtime: # ファイルが更新されていたら status を 'reload' にセットして例外をraiseして通知する。 self.status = 'reload' _thread.interrupt_main() break time.sleep(self.interval) def __enter__(self): self.start() def __exit__(self, exc_type, *_): if not self.status: self.status = 'exit' # silent exit self.join() return exc_type is not None and issubclass(exc_type, KeyboardInterrupt) class AutoReloadServer: def __init__(self, func, args=None, kwargs=None): self.func = func self.func_args = args self.func_kwargs = kwargs def run_forever(self, interval): # メインプロセスから呼び出された子プロセスには 'KWSGI_CHILD' 環境変数が存在。 # 無限に呼び出されてしまうため、環境変数で子プロセスであることを教える if not os.environ.get('KWSGI_CHILD'): lockfile = None try: fd, lockfile = tempfile.mkstemp(prefix='kwsgi.', suffix='.lock') os.close(fd) # We only need this file to exist. We never write to it while os.path.exists(lockfile): # ユーザーが端末で実行したプログラムをもう一度実行する。 args = [sys.executable] + sys.argv environ = os.environ.copy() # 無限に呼び出されてしまうため、環境変数で子プロセスであることを教える environ['KWSGI_CHILD'] = 'true' # ワーカープロセスとのやり取りに用いるファイルも環境変数で渡す。 environ['KWSGI_LOCKFILE'] = lockfile p = subprocess.Popen(args, env=environ) while p.poll() is None: # Busy wait... os.utime(lockfile, None) # Alive! If lockfile is unlinked, it raises FileNotFoundError. time.sleep(interval) # 終了ステータスをチェックする。Reload(3) 以外なら終了する。 if p.poll() != EXIT_STATUS_RELOAD: if os.path.exists(lockfile): os.unlink(lockfile) sys.exit(p.poll()) except KeyboardInterrupt: pass finally: if os.path.exists(lockfile): os.unlink(lockfile) return # ワーカープロセスの処理を記述する # ワーカープロセスはコマンド呼び出し時、 KWSGI_LOCKFILE を環境変数で指定する。 # lockfileを通してメインプロセスと通信する。ファイルが削除されていたら終了。ファイルが更新されていたらリロードを意味する。 try: lockfile = os.environ.get('KWSGI_LOCKFILE') bgcheck = FileCheckerThread(lockfile, interval) with bgcheck: self.func(*self.func_args, **self.func_kwargs) if bgcheck.status == 'reload': sys.exit(EXIT_STATUS_RELOAD) except KeyboardInterrupt: pass except (SystemExit, MemoryError): raise except: time.sleep(interval) sys.exit(EXIT_STATUS_RELOAD)
次のように使います。
server = AutoReloadServer(something_func, kwargs={'app': app, 'host': host, 'port': port})
server.run_forever(interval)
Bottleの実装を参考に勉強したのですが、lockfileによるプロセス間のステータスのやりとりや、環境変数を使ったワーカープロセスの判定は自分にとって珍しく面白い実装でした。kwsgiでは次のファイルで実装しています。
文字列で指定したPythonオブジェクトを動的に読み込んで実行する方法
最後は、コマンドラインアプリケーションをつくるときに知っておくと便利なTipsです。 gunicorn や uWSGI といったWSGIサーバーのコマンドラインインターフェイスでは、実行対象のファイル名とそこに書かれてあるWSGIアプリケーションをコマンドライン引数で指定します。
# hello.py def application(env, start_response): start_response("200 OK", [("Content-Type", "text/plain")] return [b"Hello World"]
このようなファイルを用意して、 gunicorn -w 1 hello:application と指定すると、hello.py というファイルを読み込んでからその中にある application と名前のついたオブジェクトを動的に取り出し、WSGIサーバーに読み込ませる必要があります。
やりかたはいくつかありますが、Python3だけを対象にするなら importlib.machinery.SourceFileLoader を使った方法が手軽です。
from importlib.machinery import SourceFileLoader filepath = 'target.py' app_name = 'application' def insert_import_path_to_sys_modules(import_path): abspath = os.path.abspath(import_path) if os.path.isdir(abspath): sys.path.insert(0, abspath) else: sys.path.insert(0, os.path.dirname(abspath)) insert_import_path_to_sys_modules(os.path.abspath(filepath)) module = SourceFileLoader('module', filepath).load_module() app = getattr(t, app_name)
使い方はこのように非常に簡単です。ファイルをモジュールとして動的に読み込み getattr() で対象のオブジェクトを取得します。もしPython 2で同様のことをやるなら importlib が使えないため exec() や compile() 関数を使った少しトリッキーな実装が必要になります。
import types filepath = 'target.py' app_name = 'application' t = types.ModuleType('app') with open(filepath) as config_file: exec(compile(config_file.read(), src.name, 'exec'), t.__dict__) app = getattr(t, app_name)
対象のファイルを open() し、 compile() 関数により動的にファイルの中身をコンパイルしてコードオブジェクトを取得します *3。その後 exec() 関数により types.ModuleType() で用意した変数に module オブジェクトを割り当てます。
こちらの方法を使うことはもうほとんど無いかと思うので、参考までに。ちなみに以前自分が作っていたWSGIフレームワークKobinで、 exec() を使った実装から importlib を使った実装に書き換えたときのコミットは↓のrevisionです、参考までに。
謝辞
自分がdouble forkというものを知ったのは tell-k さんのPyCon JPの発表 Pythonでざっくり学ぶUnixプロセス がきっかけでした。 少し解釈に自信がない部分もあったので、本記事も tell-k さんにレビューいただきました。ありがとうございます。 double forkの2回目のforkをする理由については、別の理由とかではないか少し心配だったのですが tell-kさんも基本的には同じ解釈のようです。 2回目のforkの意図について確認した際に、tell-kさんから次の返事がきました。
私も資料作ってる時に同じ疑問に思いました。そしたら下記リンクにたどり着きましたので共有しておきます。 http://q.hatena.ne.jp/1320139299
setsid = セッションリーダーで、技術的に制御端末の割り当てが可能だから、確実に割り当てできないようにセッションリーダーではない孫を作るっていう認識は私も一緒です。
あとは daemon化とは直接関係なさそうな気はしますが、double fork することで、ゾンビプロセスを抑制できるって話は面白かったです。 http://d.hatena.ne.jp/sleepy_yoshi/20100228/p1
どうやら親が死んで init (システム上の一番最初のプロセス。pid=1, ppid=0)の養子になることが、ゾンビプロセスの発生を抑えることにも繋がっているとのことでした。なぜ init が頻繁にwaitを呼んでいるのか、その理由までは調べきれていませんが参考までに。
他にも今回はgunicornのdouble forkの実装を参考にしました。 gunicornの実装では、 chdir() を呼んでいないのですがこちらの理由もまた分かったらまた追記しておこうかとおもいます。
- gunicorn/util.py at 91974f0f44080fdd6f2885832d101474671c4b9b · benoitc/gunicorn · GitHub
- Unix Programming Frequently Asked Questions - 1. Process Control
今日紹介した実装はどれも書いていて楽しいコードでした。 次は時間があるときにでもWSGIサーバーのパフォーマンス最適化のための方法を勉強してまとめたいなと思います。
Pythonで約100行のシンプルなWSGIサーバーを書いてみる
- 作者:Michal Jaworski,Tarek Ziade
- 発売日: 2018/02/26
- メディア: 単行本
はじめに — Webアプリケーションフレームワークの作り方 in Python の資料が最近になってホットエントリー入りし、思ったよりも多くの方に読んでいただけているようです。見返しているとWSGIサーバーを作りながらHTTPについて学べる章があってもいいかもとふと思いました。書くとすれば内容的には id:shimizukawa さんのPyCon JP 2018の発表をもう少し詳しく説明する資料になりそうな気がします。
PyCon JP 2018: Webアプリケーションの仕組み - 清水川のScrapbox
とはいえ自分もWSGIサーバーを一度も書いたことがないので、気分転換にシンプルなWSGIサーバーを書いてみました。 4時間ぐらいかかるかなと思いながら id:shimizukawa さんの上記の資料のコードをぱくりつつ書いてみたら、1時間ちょっとで最低限動くものが出来ました。その後結局リファクタリングのためにwsgirefやgunicornの実装読んでたら5時間ぐらい使ったのですが、今は手元のDjangoアプリケーションを動かしてみてもPOSTのエンドポイントとか含めてちゃんと動いてくれました。
100行ちょっと超えた程度の実装に落ち着いたので解説もそれほど大変ではなさそう。パフォーマンスの改善やヘッダーを異常に長くしてサーバー詰まらせるようなリクエストの対策などを考えだすと課題はいくらか残っていますが解説用にはちょうどいい実装かなと思います。
import logging import socket import urllib.parse from threading import Thread logger = logging.getLogger(__name__) logger.setLevel(logging.DEBUG) logger.addHandler(logging.StreamHandler()) def worker(conn, wsgi_app, env): with conn: headers = None status_code = None def start_response(s, h): nonlocal headers, status_code status_code = s headers = h wsgi_response = wsgi_app(env, start_response) if headers is None or status_code is None: conn.sendall(b'HTTP/1.1 500\r\n\r\nInternal Server Error\n') return logger.info(f"{env['REMOTE_ADDR']} - {status_code}") status_line = f"HTTP/1.1 {status_code}".encode("utf-8") headers = [f"{k}: {v}" for k, v in headers] response_body = b"" content_length = 0 for b in wsgi_response: response_body += b content_length += len(b) headers.append(f"Content-Length: {content_length}") header_bytes = "\r\n".join(headers).encode("utf-8") env["wsgi.input"].close() # close() does not raise an exception if called twice. conn.sendall(status_line + b"\r\n" + header_bytes + b"\r\n\r\n" + response_body) def make_wsgi_environ(rfile, client_address, port): # should return '414 URI Too Long' if line is longer than 65536. raw_request_line = rfile.readline(65537) method, path, version = str(raw_request_line, 'iso-8859-1').rstrip( '\r\n').split(' ', maxsplit=2) if '?' in path: path, query = path.split('?', 1) else: path, query = path, '' env = { 'REQUEST_METHOD': method, 'PATH_INFO': urllib.parse.unquote(path, 'iso-8859-1'), 'QUERY_STRING': query, 'SERVER_PROTOCOL': "HTTP/1.1", 'SERVER_NAME': socket.getfqdn(), 'SERVER_PORT': port, 'REMOTE_ADDR': client_address[0], 'SCRIPT_NAME': "", 'wsgi.version': (1, 0), 'wsgi.url_scheme': "http", 'wsgi.multithread': True, 'wsgi.multiprocess': False, 'wsgi.run_once': False, } while True: # should return '431 Request Header Fields Too Large' # if line is longer than 65536 or header exceeds 100 lines. line = rfile.readline(65537) if line in (b'\r\n', b'\n', b''): break key, value = line.decode('iso-8859-1').rstrip("\r\n").split(":", maxsplit=1) value = value.lstrip(" ") if key.upper() == "CONTENT-TYPE": env['CONTENT_TYPE'] = value if key.upper() == "CONTENT-LENGTH": env['CONTENT_LENGTH'] = value env_key = "HTTP_" + key.replace("-", "_").upper() if env_key in env: env[env_key] = env[env_key] + ',' + value else: env[env_key] = value env['wsgi.input'] = rfile return env def serve_forever(app, host="127.0.0.1", port=8000, max_accept=128, timeout=30.0, rbufsize=-1): logger.info(f"Serving HTTP on http://{host}:{port}/") with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as sock: sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, True) sock.bind((host, port)) sock.listen(max_accept) while True: conn, client_address = sock.accept() conn.settimeout(timeout) rfile = conn.makefile('rb', rbufsize) env = make_wsgi_environ(rfile, client_address, port) Thread(target=worker, args=(conn, app, env), daemon=True).start() if __name__ == '__main__': from main import app serve_forever(app)
動かすとWSGIアプリケーションから渡されたヘッダーも正しく返しているので、下のようにリダイレクトとかも問題なく動いている。
最近かなりブログの更新頻度が落ちていたので、いつもより雑なネタですが出してみました。
2018/09/23 23:33:00 追記
パクられた！w
— Takayuki Shimizukawa (@shimizukawa) 2018年9月23日
受信byte数が4096byteだとブロックしちゃうバグがあるのだけど、解決するにはコードが複雑になっちゃう。シンプルな解決方法見つけたらおしえてー
この記事で紹介した実装は、socketからreadする長さが4096バイトの整数倍のときに、次の書き込みを期待する実装になっているのでブロックする。ちゃんとハンドリングするならおそらく select とか epoll 使うのが筋ですが、清水川さんの発表資料はトークの対象レベルが結構低めなので非同期I/Oの話を入れられなかったぽい。気が向いたらこっちのサンプルはselect使って修正します。
wsgirefの実装読んでたら、makefileを使ったシンプルな解決策に気づいたのでこの問題修正済みです。
追記おわり
2018/09/24 04:10:00 追記
wsgirefの実装読んでいて知ったのですが、makefileメソッドを使えばファイルライクオブジェクトが返ってくるので、そこから readline() を使って行ベースで読み出せばキレイに解決することに気づきました。パース処理も楽になるし、wsgi.inputも簡単に作れて最高ですhttps://t.co/cOVpNQYd1q https://t.co/zhJxh0U8WQ
— Masashi Shibata (@c_bata_) 2018年9月23日
該当行(wsgiref)
- cpython/socketserver.py at c87d9f406bb23657c1b4cd63017bb7bd7693a1fb · python/cpython · GitHub
- cpython/server.py at c87d9f406bb23657c1b4cd63017bb7bd7693a1fb · python/cpython · GitHub
- cpython/simple_server.py at c87d9f406bb23657c1b4cd63017bb7bd7693a1fb · python/cpython · GitHub
追記おわり
2018/09/25 13:10:00 追記
昼休みにサクッとCLI用意してリポジトリ用意してみた。オートリロードの実装とかimportlib使ったアプリケーションの読み込み実装は昔実装したWSGICLIからコピペでほとんど済みました。
— Masashi SHIBATA (@c_bata_) 2018年9月25日
CLIは $ kwsgi https://t.co/ciFuSBwBAf app --port 8000 --reload みたいに使えます。https://t.co/2ohR8VfAZX
追記おわり
