5 ms·

$ ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)" $ brew install python3 pypy3 (to be less pithy, it's super easy t

$ ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)" $ brew install python3 pypy3 (to be less pithy, it's super easy to write code that will run on both 2.7 and 3.x -- avoid print-as-statement and use format strings instead of '%' for interpolation and that will get you 95% of the way there--probably 99-100% of the way for simple automation scripts)

Thrymr 12y ago
> use format strings instead of '%' for interpolation To be clear, %-formatting has not gone away in Python 3: https://docs.python.org/3/library/stdtypes.html#printf-style-string-formatting https://docs.python.org/3/library/stdtypes.html#printf-style...
burntsushi 12y ago
As the maintainer of a Python project that is 2.7 and 3.3+ compatible on the same code base, there is nothing super easy about it. It's horrific actually. Enough so that I'll never do it again. It goes far beyond just print functions. Libraries like `six` help, but the subtle differences in how Unicode handling has changed makes it a real challenge.
- bkeroack 12y ago
  I've written a largish project (~10k lines) targeting 2.7 and another one for 3.4. Other than the new features present in Python 3 (function annotations and asyncio), my code style has not changed at all. Neither project deals directly with unicode encoding/decoding however.
  - burntsushi 12y ago
    I'm talking about the same code running on both 2.7 and 3.3+.
- eeZi 12y ago
  A nice read: http://lucumr.pocoo.org/2013/5/21/porting-to-python-3-redux/ http://lucumr.pocoo.org/2013/5/21/porting-to-python-3-redux/
  - burntsushi 12y ago
    I've read all the relevant material. That doesn't mean it isn't painful. The same author of that blog post wrote another blog post complaining about how Unicode is handled in Python 3.
deckiedan 12y ago
Yes, python2/3 scripts are possible, and yes, Homebrew works. However, I don't really want (if I can help it) to install homebrew on all the workstations of everyone on the team (mostly video-editing), and for personal laptops, I don't really want to add that as a requirement. I certainly don't want to turn my < 100kb of scripts into hundreds of megabytes of requirements. I'm already having to bundle an up-to-date static compiled standard rsync rather than the apple one (to cope with extended attributes across SMB mounts...). It would be really nice to not have to think the whole time "Is this compatible python2 and python3", but to just write pure python3. A lot of our scripts are to do with managing and synching all the files needed for video-editing, and other media-management utilities. I already dumped BASH (my initial attempt), as it failed or became ludicrously verbose when dealing with things like folder names starting with '-' or '*', newlines, quotation marks, tabs, or other "special" characters in file names. I don't know HOW they managed to get newlines into filenames, but our editors are creative people. I wouldn't be surprised if they managed to embed fonts and colours next. So it does involve quite a lot of string processing, our automation scripts. Our tape archival system is CentOS, our main Server is a Synology RAID, and all the main edit stations are OSX, with the possibility of adding Windows boxen in the future. And since not all our projects are in English, everything is UTF-8, and mostly 'just works'. But I don't think the transition to Python3 is going to be 100% seamless. Hopefully unittests help, but I'm sure there are cases I'll miss.

Thrymr 12y ago

> use format strings instead of '%' for interpolation To be clear, %-formatting has not gone away in Python 3: https://docs.python.org/3/library/stdtypes.html#printf-style-string-formatting https://docs.python.org/3/library/stdtypes.html#printf-style...

burntsushi 12y ago

As the maintainer of a Python project that is 2.7 and 3.3+ compatible on the same code base, there is nothing super easy about it. It's horrific actually. Enough so that I'll never do it again. It goes far beyond just print functions. Libraries like `six` help, but the subtle differences in how Unicode handling has changed makes it a real challenge.

bkeroack 12y ago
I've written a largish project (~10k lines) targeting 2.7 and another one for 3.4. Other than the new features present in Python 3 (function annotations and asyncio), my code style has not changed at all. Neither project deals directly with unicode encoding/decoding however.
- burntsushi 12y ago
  I'm talking about the same code running on both 2.7 and 3.3+.
eeZi 12y ago
A nice read: http://lucumr.pocoo.org/2013/5/21/porting-to-python-3-redux/ http://lucumr.pocoo.org/2013/5/21/porting-to-python-3-redux/
- burntsushi 12y ago
  I've read all the relevant material. That doesn't mean it isn't painful. The same author of that blog post wrote another blog post complaining about how Unicode is handled in Python 3.

deckiedan 12y ago

Yes, python2/3 scripts are possible, and yes, Homebrew works. However, I don't really want (if I can help it) to install homebrew on all the workstations of everyone on the team (mostly video-editing), and for personal laptops, I don't really want to add that as a requirement. I certainly don't want to turn my < 100kb of scripts into hundreds of megabytes of requirements. I'm already having to bundle an up-to-date static compiled standard rsync rather than the apple one (to cope with extended attributes across SMB mounts...). It would be really nice to not have to think the whole time "Is this compatible python2 and python3", but to just write pure python3. A lot of our scripts are to do with managing and synching all the files needed for video-editing, and other media-management utilities. I already dumped BASH (my initial attempt), as it failed or became ludicrously verbose when dealing with things like folder names starting with '-' or '*', newlines, quotation marks, tabs, or other "special" characters in file names. I don't know HOW they managed to get newlines into filenames, but our editors are creative people. I wouldn't be surprised if they managed to embed fonts and colours next. So it does involve quite a lot of string processing, our automation scripts. Our tape archival system is CentOS, our main Server is a Synology RAID, and all the main edit stations are OSX, with the possibility of adding Windows boxen in the future. And since not all our projects are in English, everything is UTF-8, and mostly 'just works'. But I don't think the transition to Python3 is going to be 100% seamless. Hopefully unittests help, but I'm sure there are cases I'll miss.