[Python-Dev] __file__

Glenn Linderman v+python at g.nevcal.com
Mon Mar 1 04:32:09 CET 2010


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



More information about the Python-Dev mailing list