[Python-Dev] file

Sat Feb 27 02:20:26 CET 2010

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>

[Python-Dev] __file__

[Python-Dev] file