<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
On 26/02/2010 22:09, Brett Cannon wrote:
<blockquote
cite="mid:bbaeab101002261409q77c048f9x9bd5c06d18e8943e@mail.gmail.com"
type="cite"><br>
<br>
<div class="gmail_quote">On Thu, Feb 25, 2010 at 16:13, Greg Ewing <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:greg.ewing@canterbury.ac.nz">greg.ewing@canterbury.ac.nz</a>></span>
wrote:<br>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">Michael Foord wrote:<br>
<br>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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.<br>
</blockquote>
<br>
</div>
Ah, that's okay, then. Sorry about the panic!<br>
<br>
</blockquote>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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. </div>
</div>
</blockquote>
<br>
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].<br>
<br>
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.<br>
<br>
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.<br>
<br>
<blockquote
cite="mid:bbaeab101002261409q77c048f9x9bd5c06d18e8943e@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div>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. </div>
</div>
</blockquote>
<br>
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.<br>
<br>
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... :-)<br>
<br>
As you can tell, I would be disappointed to see bytecode only
distributions be removed from the out-of-the-box functionality.<br>
<br>
<br>
All the best,<br>
<br>
Michael<br>
<br>
<blockquote
cite="mid:bbaeab101002261409q77c048f9x9bd5c06d18e8943e@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div>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).</div>
<div><br>
</div>
</div>
</blockquote>
<br>
[1] <a class="moz-txt-link-freetext" href="http://www.crazy-compilers.com/decompyle/">http://www.crazy-compilers.com/decompyle/</a><br>
<br>
<blockquote
cite="mid:bbaeab101002261409q77c048f9x9bd5c06d18e8943e@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div>-Brett</div>
<div><br>
</div>
<div><br>
</div>
<div> </div>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">--
<br>
<font color="#888888">Greg</font>
<div>
<div class="h5"><br>
_______________________________________________<br>
Python-Dev mailing list<br>
<a moz-do-not-send="true" href="mailto:Python-Dev@python.org"
target="_blank">Python-Dev@python.org</a><br>
<a moz-do-not-send="true"
href="http://mail.python.org/mailman/listinfo/python-dev"
target="_blank">http://mail.python.org/mailman/listinfo/python-dev</a><br>
Unsubscribe: <a moz-do-not-send="true"
href="http://mail.python.org/mailman/options/python-dev/brett%40python.org"
target="_blank">http://mail.python.org/mailman/options/python-dev/brett%40python.org</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
<a class="moz-txt-link-freetext" href="http://www.ironpythoninaction.com/">http://www.ironpythoninaction.com/</a>
<a class="moz-txt-link-freetext" href="http://www.voidspace.org.uk/blog">http://www.voidspace.org.uk/blog</a>
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.
</pre>
</body>
</html>