Christian Heimes writes: > > Having to type "python3.0" explicitly strikes me as unnecessarily verbose. > > +1
It won't once python 3.1 is released. > > As for module file name extensions, what speaks against allowing (not > > mandating) "py3" for Python 3.x modules? Namespace pollution, of various kinds. Python 3.x modules will already be placed in python3.x/site-packages anyway. I know that in Emacs we have a registry for which mode should be used by default for files with names matching a given regexp. The initial registry basically stabilized a few years back, because new applications were bumping into extensions (the regexps are 95% of the form "\\.abc$") previously claimed. I think this is precisely analogous to recognizing which interpreter should be used by extension, as well as being a practical case where you're likely to get immediate pushback. > File extensions are only important on Windows. Or does anybody know a > system which starts scripts based on the extension like Windows does? Mac OS X's open command does something according to extension: chibi:tmp steve$ echo 'print "hello, world"' >> hello.py chibi:tmp steve$ python hello.py hello, world chibi:tmp steve$ open hello.py chibi:tmp steve$ I don't know what, though. The disk spun, I waited a second, and then the prompt returned. :-) > I see two ways to solve the program for Windows: > > * register additional file extensions for each Python version > like .py26, .pyw26 (for pythonw.exe), .py30 etc. FWIW, I can tell you that Skip will get pushback from me if he proposes registering those extensions in XEmacs's auto-mode-alist. I won't absolutely veto it, but I'll certainly suggest to the other reviewers that this is a bad idea. > * Write a wrapper for Windows which inspects the first line of > a script, searches for "#! ... python2.6" or "#!python26" and > starts the right interpreter. How about a wrapper which (like the Unix shells) starts the interpreter from the file named in the shebang if any, and provide a tool for updating shebangs conveniently (for the user) and automatically (for installers). Of course you need to make sure that this wrapper doesn't use any Python 3000 features.<wink> _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
