Author vstinner
Recipients martin.panter, pitrou, serhiy.storchaka, vstinner
Date 2014-10-14.22:48:24
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1413326905.05.0.480124992833.issue22599@psf.upfronthosting.co.za>
In-reply-to
Content
> 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.
History
Date User Action Args
2014-10-14 22:48:25vstinnersetrecipients: + vstinner, pitrou, martin.panter, serhiy.storchaka
2014-10-14 22:48:25vstinnersetmessageid: <1413326905.05.0.480124992833.issue22599@psf.upfronthosting.co.za>
2014-10-14 22:48:25vstinnerlinkissue22599 messages
2014-10-14 22:48:24vstinnercreate