On 26/02/2010 22:09, Brett Cannon wrote:
On Thu, Feb 25, 2010 at 16:13, Greg Ewing <greg.ew...@canterbury.ac.nz
<mailto: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.
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.
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.
All the best,
Michael
The only perk I can see is space-saving, but that's dangerous as that
ties you to a specific VM with a specific magic number (let alone that
it leads to people tying themselves to CPython and ignoring the other
VMs that simply do not support bytecode).
[1] http://www.crazy-compilers.com/decompyle/
-Brett
--
Greg
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org <mailto:Python-Dev@python.org>
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/brett%40python.org
--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog
READ CAREFULLY. By accepting and reading this email you agree, on behalf of
your employer, to release me from all obligations and waivers arising from any
and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap,
clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and
acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your
employer, its partners, licensors, agents and assigns, in perpetuity, without
prejudice to my ongoing rights and privileges. You further represent that you
have the authority to release me from any BOGUS AGREEMENTS on behalf of your
employer.
_______________________________________________
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
