Hi, I didn't look very hard, but I haven't seen any postings of Ahmed in spdx-tech's archive. In any case, that's not optional - all communications (and *regular* ones as that) should CC spdx-tech.
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. 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. It is not entirely unthinkable doing java code as a shared library - I know of one software which is fairly successful in its own way(pdftk) and nobody even noticed that part of it is in a java-based gcj compiled shared library. Creating a c-binding (whether it is based on the java code or new) is also a good way of ensuring new languages can be supported quickly; I don't know how the GO-binding project is going to go about it, but there is some shared work that can go in that direction. Hin-Tak -------------------------------------------- On Fri, 9/5/14, Philippe Ombredanne <[email protected]> wrote: Subject: Re: GSoC python binding project - Fw: Re: Google Summer of Code 2014: Ahmed's project To: [email protected] Cc: "[email protected]" <[email protected]>, "ahi" <[email protected]>, "Philippe Ombredanne" <[email protected]>, "Nuno Brito" <[email protected]> Date: Friday, 9 May, 2014, 9:08 On Fri, May 9, 2014 at 1:14 AM, Hin-Tak Leung <[email protected]> wrote: > Hi Ahmed, > Administratively, I think we should also estabish a few ground rules: > - you should register some public source-code hosting facility - github, etc - as soon > as possible, for show-casing your up-coming work and aiding discussion > and collaboration. Amhed: Gary can set you up on git.spdx.org alright. And you can mirror it elsewhere as you please. And communication-wise, all the communication should go through the spdx-tech list. [....] > As for the actual work itself, besides the suggestions I already made, > following the thought on the jython + existing java-work approach, there is > also a somewhat similar route via gcj and building the java binding into shared libraries > than going C-binding approach. Amhed, Hin-Tak: Anything that would be dependent on bindings with another SPDX implementation, a Java implementation or else is IMHO a bad idea. The goal is to have an implementation in pure Python, not an interpretation for a certain interpreter of Python. In terms of Python version this should be based on Python 2.7, and optionally support Python 3. The Java tests cases might be interesting for reference and possibly for inspiration, but beyond that the way SPDX is implemented in Java is language and library specific and might not apply to Python. Also SPDX is not entirely about RDF: we have also a name/value pair serialization format. With that said, RDF-wise (for the data model) there are plenty of Python libs available that grok RDF, RDFlib and RDFalchemy being among the most prominent -- Cordially Philippe Ombredanne _______________________________________________ Spdx-tech mailing list [email protected] https://lists.spdx.org/mailman/listinfo/spdx-tech
