PEP 304 - Controlling generation of bytecode files

Paul Moore gustav at morpheus.demon.co.uk
Wed Jan 29 15:31:16 EST 2003


Oren Tirosh <oren-py-l at hishome.net> writes:

> On Wed, Jan 29, 2003 at 12:50:57PM -0600, Skip Montanaro wrote:
>> 
>>     Terry> 3. This proposal changes behavior globally but does not address
>>     Terry>    the issue of doing so on a per file basis.
>> 
>> That's not the intent of this PEP.  It's hard for me to think of a use case
>> for module-by-module control over where to write .pyc files.  Can you
>> suggest one?
>
> I don't know about module-by-module but would sure be useful on an
> importer-by-importer basis when this is combined with the import hooks 
> PEP. I guess this PEP needs to pay no special attention to this case
> except perhaps mentioning the obvious fact that bytecodepath only affects 
> the standard importer.

I think in the absence of any other statement, you *have* to assume it
only applies to the standard importer. It does need stating
explicitly, though.

I can't imagine many people, when writing a new importer, bothering
about supporting PYTHONBYTECODEPATH (if appropriate). The whole point
about the new hooks is to let people *not* have to reimplement
standard behaviour (that's what was wrong with overriding
__import__). So just adding a whole new set of requirements isn't
going to impress anyone...

[At the moment, I know of no proposed new import hook which will write
pyc files, so this is largely moot as things stand. Or not - where
will the bytecodepath fit in the search order, in the presence of
hooks? I think I can work it out, but does the PEP state clearly? I
haven't seen the latest revision...]

Paul
-- 
This signature intentionally left blank




More information about the Python-list mailing list