[Python-Dev] __file__

[Brett Cannon]

On Fri, Feb 26, 2010 at 14:29, Guido van Rossum <guido at python.org> wrote:

> On Fri, Feb 26, 2010 at 2:09 PM, Brett Cannon <brett at python.org> wrote:
> > And personally, I don't see what bytecode-only modules buy you. The
> > obfuscation argument is bunk as we all know. Bytecode contains so much
> data
> > that disassembling it gives you a very clear picture of what the original
> > code was like. I think it's almost a dis-service to support bytecode-only
> > files as it leads people who are misinformed or simply don't take the
> time
> > to understand what is contained in a .pyc file into a false sense of
> > security about their code not being easy to examine by someone else.
>
> Byte-code only wasn't always supported. We added it knowing full well
> it had all those problems (plus, it locks in the Python version),
> simply because a certain class of developers won't stop asking for it.
> Their users are apparently too dumb to decode bytecode but smart
> enough to read source code, even if they don't understand it, and this
> knowledge could hurt them. Presumably users smart enough to decode
> bytecode will know enough not to hurt themselves.
>
>
Maybe it should be made optional much like the talk of frozen modules
eventually becoming an optional thing.


> Maybe Greg's and my response to the mention of dropping this feature
> is too strong -- after all we're both dinosaurs. And maybe the
> developers who want the feature can write their own loader.


We could also provide if necessary.


> But given
> that this feature takes an entirely different path through import.c
> anyway, I still don't see how dropping it is necessary in order to
> implement the PEP.


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.


> If you have separate motivation to drop the
> feature, you should deprecate it properly.
>

Fine by me. It would be easy enough to raise ImportWarning in the
bytecode-only case if Barry decides to push for this.

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

-Brett




>
> --
> --Guido van Rossum (python.org/~guido)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100226/b55e2986/attachment.html>