<br><br><div class="gmail_quote">On Fri, Feb 26, 2010 at 14:29, 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 Fri, Feb 26, 2010 at 2:09 PM, Brett Cannon <<a href="mailto:brett@python.org">brett@python.org</a>> wrote:<br>
> And personally, I don't see what bytecode-only modules buy you. The<br>
> obfuscation argument is bunk as we all know. Bytecode contains so much data<br>
> that disassembling it gives you a very clear picture of what the original<br>
> code was like. I think it's almost a dis-service to support bytecode-only<br>
> files as it leads people who are misinformed or simply don't take the time<br>
> to understand what is contained in a .pyc file into a false sense of<br>
> security about their code not being easy to examine by someone else.<br>
<br>
</div>Byte-code only wasn't always supported. We added it knowing full well<br>
it had all those problems (plus, it locks in the Python version),<br>
simply because a certain class of developers won't stop asking for it.<br>
Their users are apparently too dumb to decode bytecode but smart<br>
enough to read source code, even if they don't understand it, and this<br>
knowledge could hurt them. Presumably users smart enough to decode<br>
bytecode will know enough not to hurt themselves.<br>
<br></blockquote><div><br></div><div>Maybe it should be made optional much like the talk of frozen modules eventually becoming an optional thing.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Maybe Greg's and my response to the mention of dropping this feature<br>
is too strong -- after all we're both dinosaurs. And maybe the<br>
developers who want the feature can write their own loader.</blockquote><div><br></div><div>We could also provide if necessary.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
But given<br>
that this feature takes an entirely different path through import.c<br>
anyway, I still don't see how dropping it is necessary in order to<br>
implement the PEP.</blockquote><div><br></div><div>It's not necessary at all. I think what Barry was going for was simply cleaning up semantics once instead of having to drag it out.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
If you have separate motivation to drop the<br>
feature, you should deprecate it properly.<br></blockquote><div><br></div><div>Fine by me. It would be easy enough to raise ImportWarning in the bytecode-only case if Barry decides to push for this.</div><div><br></div><div>
Here is a question for Barry to think about if he decides to move forward with all of this: would mixed support for both bytecode-only and source/bytecode be required for the same directory, or could it be one or the other but not both? Differing semantics based on what is found in the directory would make the path hook more expensive (which is a one-time cost per directory), but it would cut stat calls in the finder in half (which is a cost made per import).</div>
<div><br></div><div>-Brett</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class="h5"><br>
--<br>
--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)<br>
</div></div></blockquote></div><br>