spyparse - sparse reimplemented in Python

spyparse - sparse reimplemented in Python

[Anderson Lizardo]

[-- Attachment #1: Type: text/plain, Size: 1400 bytes --]

Hi,

Yesterday I had the (crazy?) idea or reimplementing sparse in Python.
Some personal reasons for doing so:

1) Learn/experiment how to implement some "advanced" data structures in Python
2) Learn more about sparse internals along the way
3) some others I might not remember

Attached is a tarball containing the very very initial code. It
doesn't do anything useful, but should run without errors. A lot of
functions are not implemented yet (I started by sparse_initialize()
and going down until the lower level functions).

Some notes:

- I decided to take a more pragmatic approach and start implementing
only those functions necessary for writing a test-*.c like backend
- For now I'm just doing a plain manual translation of the sparse C
code to Python, thus forcing me to read the entire sparse code (which
IMHO is a good thing for achieving reason (2))
- Along the way I'm rewriting some code to become more OO-friendly
(with classes, methods etc.), therefore while the code is not finished
you will see a lot of mixed procedural and OO code
- I'm newbie in Python coding, so be prepared to see some examples of
bad coding style :)

I cannot guarantee spyparse will have all features from spase (even
because I do it in my free time, which is shared with other projects),
but right now I'm having a lot of fun working on it!

Comments/suggestions are welcome. Regards,
-- 
Anderson Lizardo

[-- Attachment #2: spyparse-0.tar.gz --]
[-- Type: application/x-gzip, Size: 9367 bytes --]

Re: spyparse - sparse reimplemented in Python

[Pavel Roskin]

On Fri, 2008-05-30 at 20:39 -0400, Anderson Lizardo wrote:

> Some notes:
> 
> - I decided to take a more pragmatic approach and start implementing
> only those functions necessary for writing a test-*.c like backend
> - For now I'm just doing a plain manual translation of the sparse C
> code to Python, thus forcing me to read the entire sparse code (which
> IMHO is a good thing for achieving reason (2))

I'm surprised that you decided to relicense your work under GPLv2.
Even though you are rewriting the code, it's still possible to argue
that the original authors have rights to the code.

It may be safer to use the original license, or you should make sure
that the copyright holders are fine with what you are doing.

> - Along the way I'm rewriting some code to become more OO-friendly
> (with classes, methods etc.), therefore while the code is not finished
> you will see a lot of mixed procedural and OO code

I think it's a good idea, because sparse should be flexible.  It should
be possible to change it for different coding standards.  A python
implementation would be good, but it would also help if you provide
detailed comments in the code.

-- 
Regards,
Pavel Roskin
--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: spyparse - sparse reimplemented in Python

[Anderson Lizardo]

On Sun, Jun 1, 2008 at 4:33 PM, Pavel Roskin <proski@gnu.org> wrote:
> On Fri, 2008-05-30 at 20:39 -0400, Anderson Lizardo wrote:
>
>> Some notes:
>>
>> - I decided to take a more pragmatic approach and start implementing
>> only those functions necessary for writing a test-*.c like backend
>> - For now I'm just doing a plain manual translation of the sparse C
>> code to Python, thus forcing me to read the entire sparse code (which
>> IMHO is a good thing for achieving reason (2))
>
> I'm surprised that you decided to relicense your work under GPLv2.
> Even though you are rewriting the code, it's still possible to argue
> that the original authors have rights to the code.
>
> It may be safer to use the original license, or you should make sure
> that the copyright holders are fine with what you are doing.

IANAL, but I had the impression that a copyright is applied to the
specific implementation of the work (and derivative works, such as
extensions or modifications to the original code) itself and not to
the algorithm. I presume my code is not a "derived work" from the
sparse code, even though I claim I'm "manually translating" to python
some parts of it. Unfortanely the "The Open Software License" does not
even describe what consists a "derivative work".

That said, I'd like to hear from some copyright holders about this
issue. I have plans to use my code with future projects that I'm sure
I'll not use OSL, and reading from
http://www.fsf.org/licensing/licenses/ I can see the OSL license is
GPL-imcompatible.

>> - Along the way I'm rewriting some code to become more OO-friendly
>> (with classes, methods etc.), therefore while the code is not finished
>> you will see a lot of mixed procedural and OO code
>
> I think it's a good idea, because sparse should be flexible.  It should
> be possible to change it for different coding standards.  A python
> implementation would be good, but it would also help if you provide
> detailed comments in the code.

Will do. But as I said, I just started coding it three days ago, so
consider the code in very bad shape right now. If I had decided to
publish the code only later, for sure it would be better commented,
but then I'd lose early comments as yours (which, specially for the
license issue, is very important).

BTW some comments are being purposedly ommited from the python code
because it fits better as a description above the function definition
and not on the calls. E.g.:

	// Tokenize the input stream
	token = tokenize(filename, fd, NULL, includepath);

But I'd like to first get more familiar with the sparse code and then
start adding detailed comments to the function definitions.

Thanks for the comments. Regards,
-- 
Anderson Lizardo