[Python-Dev] how important is setting co_filename for a module being imported to what __file__ is set to?

Brett Cannon brett at python.org
Mon Aug 31 07:43:07 CEST 2009

On Sun, Aug 30, 2009 at 19:51, Benjamin Peterson<benjamin at python.org> wrote:
> 2009/8/30 Brett Cannon <brett at python.org>:
>> On Sun, Aug 30, 2009 at 19:34, Guido van Rossum<guido at python.org> wrote:
>>> On Sun, Aug 30, 2009 at 5:34 PM, Brett Cannon<brett at python.org> wrote:
>>>> On Sun, Aug 30, 2009 at 17:24, Guido van Rossum<guido at python.org> wrote:
>>>>> (I was going to comment on the execution bit issue but I realized I'm
>>>>> not even sure if you're talking about import.c or not. :-)
>>>> So it turns out a bunch of execution/write bit stuff has come up in
>>>> Python 2.7 and importlib has been ignoring it. =) Importlib has simply
>>>> been opening up the bytecode files with 'wb' and writing out the file.
>>>> But test_import tests that no execution bit get set or that a write
>>>> bit gets added if the source file lacks it. I guess I can use
>>>> posix.chmod and posix.stat to copy the source file's read and write
>>>> bits and always mask out the execution bits. I hate this low-level
>>>> file permission stuff.
>>> It's no fun -- see the layers of #ifdefs in open_exclusive() in
>>> import.c. (Though I think you won't need to worry about VMS. :-) But
>>> it's somewhat important to get it right from a security POV. I would
>>> use os.open() and wrap an io.BufferedWriter around it.
>> I will have to see what of that is implemented in C or in Python. I
>> have always tried to keep all pure Python code out of importlib for
>> bootstrapping reasons in order to keep the possibility of using
>> importlib as the implementation of import. But maybe I should not be
>> worrying about that right at the moment and instead do what keeps the
>> code simple.
> You can use the C implementation of io, _io, which has a full
> buffering implementation. Of course, that also makes it a better
> harder for other implementations which may wish to use importlib
> because the io library would have to be completely implemented...

True. I guess it's a question of whether making importlib easier to
maintain and as minimally reliant on C-specific modules is more/less
important than trying to bootstrap it in for CPython for __import__ at
some point.


More information about the Python-Dev mailing list