Hi there, I checked the list of missing C modules on the wiki pages. I could contribute some code for binascii.py. Some time ago i started porting the C module to python. It's halfway done, but some functions are pretty usable and have some test coverage. Right now, I don't have time to download pypy and play with it, so I don't know if there are any issues with integrating my code. It would be best if I could develop and test the module on CPython. Cheers Florian ________________________________________________________________ Verschicken Sie romantische, coole und witzige Bilder per SMS! Jetzt neu bei WEB.DE FreeMail: http://freemail.web.de/?mc=021193
Hi Florian, [Florian Bauer Thu, Nov 25, 2004 at 04:53:33PM +0100]
Hi there,
I checked the list of missing C modules on the wiki pages. I could contribute some code for binascii.py.
nice.
Some time ago i started porting the C module to python. It's halfway done, but some functions are pretty usable and have some test coverage. Right now, I don't have time to download pypy and play with it, so I don't know if there are any issues with integrating my code. It would be best if I could develop and test the module on CPython.
that's just fine. Actually it's faster <wink> to develop against CPython and not let the current PyPy interpret your application level code. cheers, holger
holger krekel wrote:
Hi Florian,
[Florian Bauer Thu, Nov 25, 2004 at 04:53:33PM +0100]
Hi there,
I checked the list of missing C modules on the wiki pages. I could contribute some code for binascii.py.
nice.
Some time ago i started porting the C module to python. It's halfway done, but some functions are pretty usable and have some test coverage. Right now, I don't have time to download pypy and play with it, so I don't know if there are any issues with integrating my code. It would be best if I could develop and test the module on CPython.
that's just fine. Actually it's faster <wink> to develop against CPython and not let the current PyPy interpret your application level code.
As an addition: I'm just busy figuring out how to make C modules which are implemented in Python easier to compile back to C. It turned out that there is only little to change if your implementation does not use fancy features like generators. If you can assume that - all your globals are constant after initialization - you don't use ints or longs larger than machine words - methods are constants and not shadowed by instance vars - exceptions are raised only if you provide a try statement - no generators - no imports of modules which don't obey these rules - use __all__ to report the exports then this module is almost ready to become a builtin module. I just have to convert the exported objects in __all__ an give them an application-python interface, again. ciao - chris -- Christian Tismer :^) <mailto:tismer@stackless.com> tismerysoft GmbH : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9A : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 802 86 56 mobile +49 173 24 18 776 fax +49 30 80 90 57 05 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/
Christian Tismer wrote:
holger krekel wrote:
Hi Florian, [Florian Bauer Thu, Nov 25, 2004 at 04:53:33PM +0100]
Hi there,
I checked the list of missing C modules on the wiki pages. I could contribute some code for binascii.py.
nice.
Some time ago i started porting the C module to python. It's halfway done, but some functions are pretty usable and have some test coverage. Right now, I don't have time to download pypy and play with it, so I don't know if there are any issues with integrating my code. It would be best if I could develop and test the module on CPython.
that's just fine. Actually it's faster <wink> to develop against CPython and not let the current PyPy interpret your application level code.
As an addition: I'm just busy figuring out how to make C modules which are implemented in Python easier to compile back to C. It turned out that there is only little to change if your implementation does not use fancy features like generators. If you can assume that - all your globals are constant after initialization - you don't use ints or longs larger than machine words - methods are constants and not shadowed by instance vars - exceptions are raised only if you provide a try statement - no generators - no imports of modules which don't obey these rules - use __all__ to report the exports
then this module is almost ready to become a builtin module. I just have to convert the exported objects in __all__ an give them an application-python interface, again.
ciao - chris
This is pretty trivial in the case of binascii.py. The interface assumes strings, not iterables, so there's no need for fancy stuff. What I'm thinking about is whether I should use regular expressions or not. I haven't played around with it yet, but I guess that at least for running under CPython re.sub woud be faster than a state machine with the loop coded in python. But in pypy, maybe not. Any thoughts on this matter? Btw. I will need some time to clean up the module. In the next 10 days I'm pretty busy with matching the deadline for my thesis <wink>. But afterwards, I'll clean up my code and submit it. Florian
Hi Florian, [Florian Bauer Fri, Nov 26, 2004 at 04:40:18PM +0100]
What I'm thinking about is whether I should use regular expressions or not. I haven't played around with it yet, but I guess that at least for running under CPython re.sub woud be faster than a state machine with the loop coded in python. But in pypy, maybe not. Any thoughts on this matter?
We don't have a regexp implementation in PyPy yet. We just reuse cpython's c-coded one. IIRC, Jonathan David Riehl had some kind of a python-coded regexpish state machine for his tokenizer+parser suite completly written in Python. The according code is here: http://codespeak.net/svn/basil/trunk/basil/lang/python/
Btw. I will need some time to clean up the module. In the next 10 days I'm pretty busy with matching the deadline for my thesis <wink>. But afterwards, I'll clean up my code and submit it.
fine! and good luck ... holger
Florian Bauer wrote:
Christian Tismer wrote:
holger krekel wrote:
Hi Florian, [Florian Bauer Thu, Nov 25, 2004 at 04:53:33PM +0100]
Hi there,
I checked the list of missing C modules on the wiki pages. I could contribute some code for binascii.py.
nice.
Some time ago i started porting the C module to python. It's halfway done, but some functions are pretty usable and have some test coverage. Right now, I don't have time to download pypy and play with it, so I don't know if there are any issues with integrating my code. It would be best if I could develop and test the module on CPython.
that's just fine. Actually it's faster <wink> to develop against CPython and not let the current PyPy interpret your application level code.
As an addition: I'm just busy figuring out how to make C modules which are implemented in Python easier to compile back to C. It turned out that there is only little to change if your implementation does not use fancy features like generators. If you can assume that - all your globals are constant after initialization - you don't use ints or longs larger than machine words - methods are constants and not shadowed by instance vars - exceptions are raised only if you provide a try statement - no generators - no imports of modules which don't obey these rules - use __all__ to report the exports
then this module is almost ready to become a builtin module. I just have to convert the exported objects in __all__ an give them an application-python interface, again.
ciao - chris
This is pretty trivial in the case of binascii.py. The interface assumes strings, not iterables, so there's no need for fancy stuff.
Good.
What I'm thinking about is whether I should use regular expressions or not.
I looked over binascii.c and found no real reason to use regexen. If I would do it, I would probably take the C source and tweak it until it is Python. Or did you plan to do a re implementation? :-))
I haven't played around with it yet, but I guess that at least for running under CPython re.sub woud be faster than a state machine with the loop coded in python. But in pypy, maybe not. Any thoughts on this matter?
Well,re.sub uses state machines as well, and re will finally be implemented in Python as well. So there will not be that difference. I you use state machines, write simple code and just think you are coding in C. Your code will later be translated into C, and it will be simplified to use machine words as much as possible. Good luck with your thesis - chris -- Christian Tismer :^) <mailto:tismer@stackless.com> tismerysoft GmbH : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9A : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 802 86 56 mobile +49 173 24 18 776 fax +49 30 80 90 57 05 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/
Christian Tismer wrote:
Florian Bauer wrote:
Christian Tismer wrote:
holger krekel wrote:
Hi Florian, [Florian Bauer Thu, Nov 25, 2004 at 04:53:33PM +0100]
Hi there,
I checked the list of missing C modules on the wiki pages. I could contribute some code for binascii.py.
nice.
Some time ago i started porting the C module to python. It's halfway done, but some functions are pretty usable and have some test coverage. Right now, I don't have time to download pypy and play with it, so I don't know if there are any issues with integrating my code. It would be best if I could develop and test the module on CPython.
that's just fine. Actually it's faster <wink> to develop against CPython and not let the current PyPy interpret your application level code.
As an addition: I'm just busy figuring out how to make C modules which are implemented in Python easier to compile back to C. It turned out that there is only little to change if your implementation does not use fancy features like generators. If you can assume that - all your globals are constant after initialization - you don't use ints or longs larger than machine words - methods are constants and not shadowed by instance vars - exceptions are raised only if you provide a try statement - no generators - no imports of modules which don't obey these rules - use __all__ to report the exports
then this module is almost ready to become a builtin module. I just have to convert the exported objects in __all__ an give them an application-python interface, again.
ciao - chris
This is pretty trivial in the case of binascii.py. The interface assumes strings, not iterables, so there's no need for fancy stuff.
Good.
What I'm thinking about is whether I should use regular expressions or not.
I looked over binascii.c and found no real reason to use regexen. If I would do it, I would probably take the C source and tweak it until it is Python.
That's what I'm doing :-)
Or did you plan to do a re implementation? :-))
Rather not.
I haven't played around with it yet, but I guess that at least for running under CPython re.sub woud be faster than a state machine with the loop coded in python. But in pypy, maybe not. Any thoughts on this matter?
Well,re.sub uses state machines as well, and re will finally be implemented in Python as well. So there will not be that difference.
I you use state machines, write simple code and just think you are coding in C. Your code will later be translated into C, and it will be simplified to use machine words as much as possible.
Ok. Thats what my code looks like at the moment.
Good luck with your thesis - chris
Thanks (also to Holger)! Florian
participants (3)
-
Christian Tismer -
Florian Bauer -
hpk＠trillke.net