[Python-Dev] __file__

[Doug Hellmann]

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

Doug

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