[Python-Dev] __file__

[Michael Foord]

On 26/02/2010 22:09, Brett Cannon wrote:
>
>
> On Thu, Feb 25, 2010 at 16:13, Greg Ewing <greg.ewing at canterbury.ac.nz 
> <mailto:greg.ewing at canterbury.ac.nz>> wrote:
>
>     Michael Foord wrote:
>
>         I thought we agreed at the language summit that if a .pyc was
>         in the place of the source file it *could* be imported from -
>         making pyc only distributions possible.
>
>
>     Ah, that's okay, then. Sorry about the panic!
>
>
> Michael is right about what as discussed at the language summit, but 
> Barry means what he says; if you look at the PEP as it currently 
> stands it does not support bytecode-only modules.
>
> Barry and I discussed how to implement the PEP at PyCon after the 
> summit and supporting bytecode-only modules quickly began to muck with 
> the semantics and made it harder to explain (i.e. what to set __file__ 
> vs. __compiled__ based on what is or is not available and how to 
> properly define get_paths for loaders). But a benefit of no longer 
> supporting bytecode-only modules by default is it cuts back on 
> possible stat calls which slows down Python's startup time (a 
> complaint I hear a lot). Performance issues become even more acute if 
> you try to come up with even a remotely proper way to have 
> backwards-compatible support in importlib for its ABCs w/o forcing 
> caching on all implementors of the ABCs.
>
> As for having a dependency on a loader, I don't see how that is 
> obscure; it's just a dependency your package has that you handle at 
> install-time.
>
> 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.

Well, understanding bytecode is *still* requires a higher level of 
understanding than the *majority* of Python programmers. Added to which 
there are no widely available tools that *I'm* aware of for decompiling 
recent versions of Python (decompyle worked up to Python 2.4 but then 
went closed source as a commercial service [1].

The situation is analagous to .NET assemblies by the way (which *can* be 
trivially decompiled by several widely available tools). Having a 
non-source distribution prevents your users from changing things and 
then calling you for support without them having to go to a lot more 
effort than it is worth.

There are several companies who currently ship bytecode only. (There was 
someone on the IronPython mailing list only last week asking if 
IronPython could support pyc files for this reason). For many 
pointy-haired-bosses 'some' protection is enough and having Python not 
support this (out of the box) would be a black mark against Python for them.

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

For many use-cases some protection is enough. After all *any* DRM or 
source-code obfuscation is breakable in the medium / long term - so just 
enough to discourage the casual looker is probably sufficient. The fact 
that bytecode only distributions exist speaks to that.

Whether you believe that allowing companies who ship bytecode is a 
disservice to them or not is fundamentally irrelevant. If they believe 
it is a service to them then it is... :-)

As you can tell, I would be disappointed to see bytecode only 
distributions be removed from the out-of-the-box functionality.


All the best,

Michael

> The only perk I can see is space-saving, but that's dangerous as that 
> ties you to a specific VM with a specific magic number (let alone that 
> it leads to people tying themselves to CPython and ignoring the other 
> VMs that simply do not support bytecode).
>

[1] http://www.crazy-compilers.com/decompyle/

> -Brett
>
>
>     -- 
>     Greg
>
>     _______________________________________________
>     Python-Dev mailing list
>     Python-Dev at python.org <mailto:Python-Dev at python.org>
>     http://mail.python.org/mailman/listinfo/python-dev
>     Unsubscribe:
>     http://mail.python.org/mailman/options/python-dev/brett%40python.org
>
>


-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100226/a83dd61c/attachment-0001.html>