------------------------------ On Fri, May 9, 2014 2:03 PM BST ahi wrote: <snipped> >> I am not too concerned about python 2.7 vs python 3 - most of the world >> is still operating at 2.7, but forward porting, one-off via the 2to3 script, >> is relatively straight-forward; and backward compatibility, at least to the >> last >> few minor releases of 2.7 or even 2.6, can be achived via "from __future__ >> import *". >> It is possible to write python code that works identically under >> 2.7 and 3. That's not really a concern - we'll cross that bridge when we >> need to, when we have some code to discuss on. > >I have to say that I am more comfortable with python 2.7 but that's >because I don't have any experience with python 3, but I am willing >to use python 3 if its for the best. >
I'd say you just use whatever is shipped with your computer - most likely it is 2.7.x . Since we are under the Linux Foundation unbrella, I'll assume you would be working on a recent linux distro (rather than Mac OS X/windows, neither of which really have any system tools written in python); many of the system tools on a modern linux system are themselves written in python so migration is not trivial. But some may already have both of them available. I know fedora certainly do - system tools depends on 2.7 but python 3 is available/optional addition. AFAIK, only fedora is planning to migrate to python 3, for the next release in August. Even if they slip by a release to next year, you can say within about 12 months one of the popular linux distros will be python 3 based, so you should keep that in mind. That said, it is mostly a non-problem. Python 3 ships a script called "2to3" (I already mentioned that) which can automatically translate python 2 code to python 3 code, mostly; and the difference/portings issues are well-understood, you can read up on many well-written articles on-line. And on the python 2 side, you can start using python 3-like functionalities in a late 2.6/2.7 with future module using the "from __future__ import *" idiom. I'd say, just work on one and fix it for the other later. One thing worth keeping in mind is that Python 3's internal string representation is all unicode based, and it distinguishes between strings (textual, possibly non-english) and byte-arrays (no particular textual meaning attach to any chunk of it), whereas in python 2 the two are somewhat synonymous and conversions between them are implicit. You should bear that in mind and think carefully what sort of data you are processing and do not assume you will always be processing English/ascii data, to save yourself and others some future pain. The Go-binding GSoC project may generate some C-binding stuff on a side, so you should keep an eye out and co-ordinate with the other people. Hin-Tak _______________________________________________ Spdx-tech mailing list [email protected] https://lists.spdx.org/mailman/listinfo/spdx-tech
