[Python-Dev] how important is setting co_filename for a module being imported to what __file__ is set to?
benjamin at python.org
Mon Aug 31 04:51:00 CEST 2009
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...
More information about the Python-Dev