PEP 304 - is anyone really interested?

John Roth newsgroups at jhrothjr.com
Fri Jun 24 00:21:54 EDT 2005


"Patrick Maupin" <pmaupin at gmail.com> wrote in message 
news:1119567362.026775.272080 at g44g2000cwa.googlegroups.com...
> Thomas Heller wrote:
>
>> Although I was not interested originally, I think that's
>> a use case I also have.  Optional config files, which
>> should not be compiled to .pyc or .pyo.  Only removing
>> the .py file doesn't have the expected effect
>> if a .pyc and/or .pyo if is left.
>
>
> I also think that if nobody has the same use-case as envisioned by the
> original PEP, we should probably step back and rethink how it should be
> implemented.  The original PEP envisioned the installation of
> third-party .py file libraries without their corresponding .pyc files
> into directories for which the eventual script user had no
> write-access.  As more people become coginzant of the correct way to
> install Python libraries, I think this use-case fades in importance.

See below.

> The key distinction between this older use-case and the currently
> envisioned use-case is that the former assumes third-party code, and
> the latter assumes that the control over .pyc generation is desired by
> the _author_ of some python code, rather than merely the _installer_ of
> some python code.  In this latter case, environment variables are not
> strictly necessary, because the top-level script could do whatever it
> needs to control .pyc generation, from inside Python itself.

Well, after thinking this over, I'm finding a significant problem with
the envisioned mechanism: it specifies a _single_ directory tree that
shadows the source tree. I'd like to suggest a different mechanism,
at least for packages (top level scripts don't generate .pyc files
anyway.) Put a system variable in the __init__.py file. Something
like __obj__ = path would do nicely. Then when Python created
the __init__.pyc file, it would insert a back link __src__ entry.

That way, either the source or the object directory could be
specified in the Pythonpath, the import machinery could then do the
right thing by checking the appropriate directory for the .py and .pyc
files.

I will say that I would personally find it very useful to have the
.py and .pyc (.pyo) files in separate directories for development
work.

>> AFAIK, it is not possible to define empty env vars on Windows.

> You make a good point about null environment variables.  I think the
> original PEP was fairly *nix-centric, both in that aspect, and in the
> aspect of requiring the value of bytecodebase to be the "root" of the
> file system.  This might not have the desired results in all cases on
> Windows.

Actually, the PEP states that if the environment variable does not specify
a directory then it does not generate a .pyc file. Any entry that is not a
directory would do, such as some special characters that are illegal in
file and directory names.

John Roth

>
> Regards,
> Pat
> 




More information about the Python-list mailing list