Re: PEP 3147 - new .pyc format



On Tue, 02 Feb 2010 09:38:07 +0100, Daniel Fetchinson wrote:

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.

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.

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;

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

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

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

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

(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...

(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).

Neither of these are seriously an option.


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.



--
Steven
.



Relevant Pages

  • Re: how is python not the same as java?
    ... that is not correct java is compiled and the VM interprets the code ... and what do you think is in those pesky little .pyc files you may ... the pyc files are just a "catching" system for the common python ... call the compiler when needed doesn't make Python ...
    (comp.lang.python)
  • Re: Python bytecode compatibility between interpreter versions
    ... Note that I specifically mentioned .pyc files vs. java class files, ... not Java the language/environment/platform vs. Python. ... > your platform. ... Perhaps one day .pyc files can work in such a manner. ...
    (comp.lang.python)
  • Re: PEP 3147 - new .pyc format
    ... I often end up renaming it multiple times ... I only would need to worry about python source ... the .pyc files and just care about the source. ... Forget about byte-code compiling, and just treat Python as a purely ...
    (comp.lang.python)
  • Re: Any way to not create .pyc files?
    ... As long as you zipped up the package will all .pyc and .pyo files removed, Python will have no choice but to compile the files every time they are imported - unless I'm grossly mistaken Python won't put the pyc files into the zip archive, or modify any that were there already. ... Instead of the users starting the application directly, they could start a starter application that checks with the server to determine if local files need to be updated, and if so grab them and then start the main app. ...
    (comp.lang.python)
  • Re: Race condition when generating .pyc files
    ... Part of the code lives in one place, ... hosts when the module's .pyc file is generated. ... python source first. ... Inhibiting the generation of .pyc files altogether if that's even ...
    (comp.lang.python)