On approximately 2/28/2010 3:22 PM, came the following characters from
the keyboard of Greg Ewing:
Glenn Linderman wrote:
if the command line/runpy can do it, the importer could do it. Just
a matter of desire and coding. Whether it is worth pursuing further
depends on people's perceptions of "kookiness" vs. functional and
performance considerations.
Having .py files around that aren't source text could
lead to a lot of confusion, given that most platforms
these days decide which application to open for a given
file based solely on the filename extension. I wouldn't
enjoy trying to open a .py file only to have my text
editor blow up because it was actually a binary file.
So on balance I think it's a bit too kooky for my
taste.
I understand your thoughts, but have some rebuttal comments. Mind you,
if there is a better solution that can improve performance for both the
source+binary and the binary-only distributions, I'm all for it. But in
general, I'm all for performance improvements, even if there is some
kookiness :) Thankful for Brett's posting of the actual search code
fragment.
If your text editor blows up because it is binary, it is a sad text editor.
If you have .py mapped to a text editor, that's sort of kooky too; I
have it mapped to Python.
The .py files that are binary would generally be part of an application
distribution in binary form, and therefore would be installed in some
place like /bin or C:\Program Files ... not the place you'd look for
source code, to confuse your text editor.
--
Glenn -- http://nevcal.com/
===========================
A protocol is complete when there is nothing left to remove.
-- Stuart Cheshire, Apple Computer, regarding Zero Configuration Networking
_______________________________________________
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
