<br><br><div class="gmail_quote">On Wed, Dec 9, 2009 at 11:27, Guido van Rossum <span dir="ltr"><<a href="mailto:guido@python.org">guido@python.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="im">On Wed, Dec 9, 2009 at 11:07 AM, Jared Grubb <<a href="mailto:jared.grubb@gmail.com">jared.grubb@gmail.com</a>> wrote:<br>
><br>
> On 8 Dec 2009, at 13:44, Ben Finney wrote:<br>
><br>
> * A new attribute ‘sys.import_orphaned_bytecode’. If set ‘True’, the<br>
>  interpreter follows the current behaviour. If ‘False’, any bytecode<br>
>  file satisfies an import only if it has a corresponding source file<br>
>  (where “corresponding” means “this source file would, if compiled,<br>
>  result in a bytecode file replacing this one”).<br>
><br>
> One problem with a sys flag is that it's a global setting. Suppose a package<br>
> is distributed with only pyc/pyo files, then the top-level __init__.py might<br>
> flip the switch such that its sub-files can get imported from the pyc/pyo<br>
> files. But you wouldnt want that flag to persist beyond that.<br>
<br>
</div>I'm not sure that there are any use cases that require using<br>
conflicting values of this setting for different packages.<br>
<div class="im"><br></div></blockquote><div><br></div><div>Same here. This is straying into optimizations for the sake of optimizing.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="im">
> Another idea is to use a new file extension, which isnt the best solution,<br>
> but allows the creator to explicitly set what behavior they intended for<br>
> their files:<br>
>   * if a foo.py file exists, then use the existing foo.pyc/pyo as is done<br>
> today<br>
>   * if a foo.py file does not exist, but a foo.pyxxx exists, use it (but<br>
> file.pyc/pyo is never used, unlike today)<br>
> (pyxxx is a placeholder for whatever would be a reasonable name)<br>
<br>
</div>It's a much bigger change, but using a different extension would<br>
probably remove the need for a flag. It would also help with some<br>
tools that hide .pyc/.pyo files from view (e.g. the typical<br>
.svnignore).</blockquote><div><br></div><div>From a Python VM perspective, the problem with this is it doesn't help improve the situation for other VMs that have no concept of bytecode. If we make pyc/pyo files purely an optimization for CPython (and other VMs that choose to support the format) and not a recognized executable format on its own (like it is now) then that would probably help prevent people from distributing pyc/pyo files only and thus locking out the use of other VMs.</div>

<div><br></div><div>I know some people seem to think pyc/pyo fles are a good way to obfuscate code, but it honestly isn't, IMO. But these people stand the most to lose from us even considering changing default behavior.</div>

<div><br></div><div>In a perfect world I would make pyc/pyo files completely optional and only an optimization that could not work w/o the corresponding source. But in a backwards-compatible, paranoid world I would make it an opt-in flag to ignore lone pyc/pyo files. I am +10 on the former and +1 on the latter.</div>

<div><br></div><div>-Brett</div></div>