STINNER Victor added the comment: > There is one downside of my solution. For now the code uses current builtin > open() which can be overloaded (to handle reading from ZIP archive for > example, or to check permissions).
Oh, does anyone really modify the builtin open() for that? If you already monkey-patch Python builtin, you are probably able to monkey-patch also tokenize._builtin_open. I don't think that monkey-patching builtins is promoted nor well supported. They are probably other places where a local references to builtins functions are kept. The importlib module provides the get_source() function which is the best way to retrieve the source code from any kind of module, including ZIP files. But tokenize.open() really expects a clear text ".py" file. > With my solution it uses builtin open() at the time of import. I don't see how your solution is different than mine. But your solution is probably enough to tokenize needs (it only requires the builtin open funciton) and it's shorter. > I don't know insofar current behavior is intentional. We should take a > decision of yet one core developer. Since I wrote tokenize.open(), I can explain why I chose to import builtins :-) It's just one option to handle two functions with the same name: (builtins.)open and (tokenize.)open. "_open = open" is another common option to handle this issue. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue22599> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
