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>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4