4 ms·

Python3 won't be standard until it's adopted as the main python of several widespread linux distros and available in a clean, batteries included way for OSX and

by olefoo 18y ago

Python3 won't be standard until it's adopted as the main python of several widespread linux distros and available in a clean, batteries included way for OSX and all 36 flavours of windows. Bitching about py3k is basically whining about being forced to learn new things. The one question I have is are people going to start using different filename conventions? I could see temporarily associating .py3 with a /usr/local/bin/py3k for testing purposes and porting 2.6 to 3, but I really hope it doesn't become a widespread practice.

Rhamphoryncus 18y ago
The ideal approach is "#!/usr/bin/env python3.0".
- kteague 18y ago
  If you install Python 3 with "make fullinstall" then the binary will be named just "python". I've always used just "#!/usr/bin/env python" and just kept track of what version of Python a collection of code was targeted for. Changing all scripts from "#!/usr/bin/env python3.0" to ""#!/usr/bin/env python3.1" and so on is too cumbersome. But it depends upon how you manage your code - whether it's just a few loose scripts, part of a larger project, a web app or a desktop app or a command-line script, or what your deployment and install processes looks like, etc. etc. I usually install my Python scripts with Buildout these days, so I let Buildout autogenerate the shebangs to point to the required Python installation.
- olefoo 18y ago
  That solves one slice of the problem, now how do I distinguish between waycoolscript.py written for python3.0 and waycoolscript.py for python2.4? I could live with *.py3 for a few years (remember php3?) but it's kind of a wart. And the thing I like about python is the core teams assiduous avoidance of warts.
gaius 18y ago
As soon as ActiveState do it, basically. Having identical ActivePython (or ActiveTcl, or even ActivePerl) on all of Solaris, Linux, OSX and Windows just makes things so much easier. Me, I'm going to yum up those dictionary comprehensions and that OCaml-style pattern matching as soon as I can. Tasty!

by olefoo 18y ago

Rhamphoryncus 18y ago

The ideal approach is "#!/usr/bin/env python3.0".

kteague 18y ago
If you install Python 3 with "make fullinstall" then the binary will be named just "python". I've always used just "#!/usr/bin/env python" and just kept track of what version of Python a collection of code was targeted for. Changing all scripts from "#!/usr/bin/env python3.0" to ""#!/usr/bin/env python3.1" and so on is too cumbersome. But it depends upon how you manage your code - whether it's just a few loose scripts, part of a larger project, a web app or a desktop app or a command-line script, or what your deployment and install processes looks like, etc. etc. I usually install my Python scripts with Buildout these days, so I let Buildout autogenerate the shebangs to point to the required Python installation.
olefoo 18y ago
That solves one slice of the problem, now how do I distinguish between waycoolscript.py written for python3.0 and waycoolscript.py for python2.4? I could live with *.py3 for a few years (remember php3?) but it's kind of a wart. And the thing I like about python is the core teams assiduous avoidance of warts.

gaius 18y ago

As soon as ActiveState do it, basically. Having identical ActivePython (or ActiveTcl, or even ActivePerl) on all of Solaris, Linux, OSX and Windows just makes things so much easier. Me, I'm going to yum up those dictionary comprehensions and that OCaml-style pattern matching as soon as I can. Tasty!