Hi,
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
I agree. At this point is already difficult to find voluntaries for the
current base in Java but hopefully the new code in Python won't be too
depending on external libraries, making it easier for integration with
Jython and other platforms when necessary. Perhaps a good idea to keep
the code interfacing with these dependencies isolated.
During this month I'm putting together on github a folder with assorted
SPDX documents from different sources to run stress tests on the
parsers. Should help to highlight what needs to be corrected or handled
by the Python code.
Anyone knows if file examples for SPDX 2.0 are already available?
With kind regards,
Nuno Brito
---
spdx: http://triplecheck.de/download
phone: +49 615 146 03187
On 2014-05-09 14:51, Hin-Tak Leung wrote:
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
