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