On Fri, Feb 26, 2010 at 17:20, Doug Hellmann <doug.hellm...@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.ew...@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
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
