PEP 3147 - new .pyc format

[Daniel Fetchinson]

>>> I like seeing them in the same place as the source file, because when I
>>> start developing a module, I often end up renaming it multiple times
>>> before it settles on a final name. When I rename or move it, I delete
>>> the .pyc file, and that ensures that if I miss changing an import, and
>>> try to import the old name, it will fail.
>>>
>>> By hiding the .pyc file elsewhere, it is easy to miss deleting one, and
>>> then the import won't fail, it will succeed, but use the old, obsolete
>>> byte code.
>>
>>
>> Okay, I see your point but I think your argument about importing shows
>> that python is doing something suboptimal because I have to worry about
>> .pyc files. Ideally, I only would need to worry about python source
>> files.
>
> That's no different from any language that is compiled: you have to worry
> about keeping the compiled code (byte code or machine language) in sync
> with the source code.

True.

> Python does most of that for you: it automatically recompiles the source
> whenever the source code's last modified date stamp is newer than that of
> the byte code. So to a first approximation you can forget all about
> the .pyc files and just care about the source.

True, but the .pyc file is lying around and I always have to do 'ls
-al | grep -v pyc' in my python source directory.

> But that's only a first approximation. You might care about the .pyc
> files if:
>
> (1) you want to distribute your application in a non-human readable
> format;

Sure, I do care about pyc files, of course, I just would prefer to
have them at a separate location.

> (2) if you care about clutter in your file system;

You mean having an extra directory structure for the pyc files? This I
think would be better than having the pyc files in the source
directory, but we are getting into 'gut feelings' territory :)

> (3) if you suspect a bug in the compiler;

If the pyc files are somewhere else you can still inspect them if you want.

> (4) if you are working with byte-code hacks;

Again, just because they are somewhere else doesn't mean you can't get to them.

> (5) if the clock on your PC is wonky;

Same as above.

> (6) if you leave random .pyc files floating around earlier in the
> PYTHONPATH than your source files;
>
> etc.
>
>
>
>
>> There is now a chance to 'fix' (quotation marks because maybe
>> there is nothing to fix, according to some) this issue and make all pyc
>> files go away and having python magically doing the right thing.
>
> Famous last words...
>
> The only ways I can see to have Python magically do the right thing in
> all cases would be:
>
> (1) Forget about byte-code compiling, and just treat Python as a purely
> interpreted language. If you think Python is slow now...

I'm not advocating this option, naturally.

> (2) Compile as we do now, but only keep the byte code in memory. This
> would avoid all worries about scattered .pyc files, but would slow Python
> down significantly *and* reduce functionality (e.g. losing the ability to
> distribute non-source files).

I'm not advocating this option either.

> Neither of these are seriously an option.

Agreed.

>> A
>> central pyc repository would be something I was thinking about, but I
>> admit it's a half baked or not even that, probably quarter baked idea.
>
> A central .pyc repository doesn't eliminate the issues developers may
> have with byte code files, it just puts them somewhere else, out of
> sight, where they are more likely to bite.

Here is an example: shared object files. If your code needs them, you
can use them easily, you can access them easily if you want to, but
they are not in the directory where you keep your C files. They are
somewhere in /usr/lib for example, where they are conveniently
collected, you can inspect them, look at them, distribute them, do
basically whatever you want, but they are out of the way, and 99% of
the time while you develop your code, you don't need them. In the 1%
of the case you can easily get at them in the centralized location,
/usr/lib in our example.

Of course the relationship between C source files and shared objects
is not parallel to the relationship to python source files and the
created pyc files, please don't nitpick on this point. The analogy is
in the sense that your project inevitable needs for whatever reason
some binary files which are rarely needed at hand, only the
linker/compiler/interpreter/etc needs to know where they are. These
files can be stored separately, but at a location where one can
inspect them if needed (which rarely happens).

Cheers,
Daniel


-- 
Psss, psss, put it down! - http://www.cafepress.com/putitdown