On Feb 27, 2010, at 9:38 AM, Nick Coghlan wrote:
> I do like the idea of pulling .pyc only imports out into a separate
> importer, but would go so far as to suggest keeping them as a command
> line option rather than as a separately distributed module.
One advantage of doing this as a separately distributed module is that it can
have its own ecosystem and momentum. Most projects that want this sort of
bundling or packaging really want to be shipped with something like py2exe, and
I think the folks who want such facilities would be better served by a nice
project website for "python sealer" or "python bundler" rather than obscure
directions for triggering the behavior via options or configuration.
Making bytecode loading a feature of interpreter startup, whether it's a config
file, a command-line option or an environment variable, is not a great idea.
For folks that want to ship a self-contained application, any of these would
require an additional customization step, where they need to somehow tell their
bundled interpreter to load bytecode. For people trying to ship a
self-contained and tamper-unfriendly (since even "tamper-resistant" would be
overstating things) library to relatively non-technical programmers, it opens
the door to a whole universe of confusion and FAQs about why the code didn't
load.
However bytecode-only code loading is facilitated, it should be possible to
bootstrap from a vanilla python interpreter running normally, as you may not
know you need to load a bytecode-only package at startup. In the stand-alone
case there are already plenty of options, and in the library case, shipping a
zip file should be fine, since the __init__.py of your package should be
plain-text and also able to trigger the activation of the bytecode-only
importer.
There are already so many ways to ship bytecode already, it doesn't seem too
important to support in this one particular configuration (files in a
directory, compiled by just importing them, in the same place as ".py" files).
The real problem is providing a seamless transition path for *build* processes,
not the Python code itself. Do any of the folks who are currently using this
feature have a good idea as to how your build and distribute scripts might
easily be updated, perhaps by a 2to3 fixer?
_______________________________________________
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
