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
Doug
_______________________________________________
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
