On Fri, May 9, 2014 at 3:03 PM, ahi <[email protected]> wrote: > On Fri, May 9, 2014 at 2:51 PM, Hin-Tak Leung > <[email protected]> wrote: >> 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.
Go with Python 2.7 IMHO, portability to 3 is not a problem and not an issue until Python 3 becomes mainline in some (likely distant) future. > On Fri, May 9, 2014 at 2:51 PM, Hin-Tak Leung > <[email protected]> wrote: >> The jython + existing java code ideas serves a few purposes - the python >> binding >> should be feature-complete versus existing work; also, while it is nice >> that Ahmed will continue after the program finishes, and/or others >> will pick up the maintainence of such work, if it shares some >> with a larger bulk there is a better chance of that happening - >> otherwise it is just a few months of work gradually bit-rotting and >> abandoned in a few years' time. I am okay >> with it sharing some work with another language-binding project - otherwise >> you get two sets of bugs and two sets of possibly incompatible >> implementations to worry about; one of them gradually bit-rotting and go >> unmaintained. >> I won't insist on it; it is just a possibility that should be explored. The Java implementation can already be used in Jython as-is, so there is no work to be done there? On Fri, May 9, 2014 at 3:03 PM, ahi <[email protected]> wrote: > I can definitely see the merits of this approach, creating a C library > from the Java binding or from scratch could definitely benefit future > projects. I am also ok with having a pure Python implementation from > scratch. I strongly think this would not be a good thing to work on bindings, especially with Java. These usually create portability issues and raise the bar for build and deployment requirements for no good reason. A native language implementation is IMHO best. What makes sense as Nuno suggested would be to create a standard test suite that is not language dependent. -- Cordially Philippe Ombredanne _______________________________________________ Spdx-tech mailing list [email protected] https://lists.spdx.org/mailman/listinfo/spdx-tech
