[Python-ideas] disabling .pyc and .pyo files

Brett Cannon brett at python.org
Wed Dec 9 01:45:42 CET 2009


2009/12/8 Kristján Valur Jónsson <kristjan at ccpgames.com>

>  You are right, I was suggesting the former.  From what cursory glance I
> had at the code it seemed simpler to not look for a .pyo file at all, rather
> than to add a special rule regarding its relation to a .py file.  That would
> also help rule out any timestamp problems.  But I‘m happy with whatever way
> we agree on to solve the „orphaned bytecode“ problem and glad to see that
> I‘m not the only one experiencing it.
>
>
I prefer the former as well (don't read any bytecode no matter if source is
available or not); clear and simple semantics that are easy to implement.


>
>
> Kristján
>
>
>
> *From:* bcannon at gmail.com [mailto:bcannon at gmail.com] *On Behalf Of *Brett
> Cannon
> *Sent:* 8. desember 2009 23:14
> *To:* Kristján Valur Jónsson
> *Cc:* python-ideas at python.org
> *Subject:* Re: [Python-ideas] disabling .pyc and .pyo files
>
>
>
>
>
> 2009/12/8 Kristján Valur Jónsson <kristjan at ccpgames.com>
>
> [SNIP]
>
>  I looked at the import code and I found that it is trivial to block the
> reading and writing of .pyo files.  I am about to implement that patch for
> our purposes, thus forcing recompilation of the .py files on each run if so
> specified.   This will ensure that the application will execute only the
> code represented by the checked-out .py files.  But it occurred to me that
> this functionality might be of interest to other people than just us.  I can
> imagine, for example, that buildbots running the python regression testsuite
> might be running into problems with stray .pyo files from time to time.
>
>
>
> Are you suggesting that the flag turn off reading *period*, or only if no
> source is available? I think you mean the former while Guido suggested the
> latter.
>
>
>
> -Brett
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20091208/d53e1b9b/attachment.html>


More information about the Python-ideas mailing list