__pycache__, one more good reason to stck with Python 2?

[jmfauth]

On Jan 19, 7:03 pm, Antoine Pitrou <solip... at pitrou.net> wrote:
> On Wed, 19 Jan 2011 08:30:12 -0800 (PST)
>
> jmfauth <wxjmfa... at gmail.com> wrote:
> > Yes, I can launch a pyc, when I have a single file.
> > But what happens, if one of your cached .pyc file import
> > a module with a name as defined in the parent directory?
> > The machinery is broken. The parent dir is not in the
> > sys.path.
>
> Well, you don't have to launch a pyc file anyway. Put all your code in
> some (pyc) modules on the standard Python path, and use a clear-text
> script with some trivial code to invoke a function from the compiled
> modules.

That's not the point. I'm toying. And the "behaviour" from now
is deeply different from what it was.

> Otherwise you can customize sys.path a little from your script,
> using __file__ and os.path.dirname. Nothing complicated AFAICT.

That's not as simple. You have too prepare the py file in such a way,
that it recognizes the path of its ancestor py file. The "home dir"
is no more the same.


> (by the way, the fact that pyc files are version-specific should
> discourage any use outside of version-specific directories,
> e.g. /usr/lib/pythonX.Y/site-packages)

Here we are. I'm just wondering if all this stuff is not just
here in order to satisfy the missmatched Python installation on
*x platforms compared to Windows whre each Python version
lives cleanely in its isolated space. (Please no os war).

jmf



compared to