[Python-Dev] __file__

[Brett Cannon]

On Fri, Feb 26, 2010 at 17:20, Doug Hellmann <doug.hellmann at gmail.com>wrote:

>
> On Feb 26, 2010, at 5:59 PM, Michael Foord wrote:
>
>  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>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.
>
>
> We ship bytecode only, basically for the reason Michael states here
> (keeping support costs under control from "ambitious" users).
>
>   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.
>
>
> Right. We're more concerned with not having users muck with stuff than with
> keeping the implementation a secret, although having a bit of obfuscation
> doesn't hurt.
>
> 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.
>
>
> +1
>

So what is the burden of including a single source file that added the
support to load from bytecode-only modules? I am not saying you shouldn't be
able to have this functionality, just that I personally don't want to pay
for the overhead (both performance-wise and development-wise) by default
just because you and some other people want this functionality for some
clients.

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