[Cython] Willing to contribute
Hi everybody, I've been a enthusiast Python programmer for 3 years now, and I've hailed Cython project with great interest. Now, I'm willing to contribute. I've would say I'm an quite an expert Python programmer and I've some-year-long experience with C, modern C++ and its cousin Java. Sidenote, I'm a student at Politecnico di Milano, Italy. Everything started with trying to speed up a Mandelbrot generator, which heavily relies on complex numbers. Eventually I've found in "Mini Projects (or something similar)" wiki that C99 `complex' is still to be implemented. So, I decide to make a step further and try to hop into development. I've would be grateful if a core developer could point me in the right direction concerning coding style, repositories, deadlines (I'm still a student, so I may have 'offline' days this winter) and other issues. I may start with something easy (`complex' implementation, or command line API restructuration), and I'd like someone from the team to discuss what I'll be implementing (ok, just for the first days), just to see if "I'm doing it right" (TM) and, mostly, if I'm the right man or I'm just making you loose your time. You can see an example of what I did in the past here: http://code.google.com/p/libsmth/ - for instance (still a WIP). I really appreciate your work :) --SKS ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
[Cython] CmdLine.py refactoring
Hi, I've cloned GitHub repo and started working on it. First, I'm rewriting Compiler/CmdLine.py to use the optparse/argparse module. Then I'll try to address the Bugzilla ticket mentioned in the source file. Question: optparse has been deprecated since 2.7 (which adopts optparse module). So, which one to choose? Old one, or new one? Or should I work on a fallback system? --SKS ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
[Cython] CommandLine.py refactoring
> Then I'll try to address the Bugzilla ticket mentioned in the source file. Well, I meant Trac ticket. --SKS ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] CmdLine.py refactoring
Sunday 7th August 2011 16:21:06, Stefan Behnel wrote: > Will you put it up somewhere on github? Here's my branch for command line refactoring. There's still nothing interesting on, but changes will be pushed soon. https://github.com/satufk/cython/tree/_commandline > I'm also not sure how well this will fit in, given that the default options > are stored in Main.py and don't belong in CmdLine.py as the command line is > only one of the ways to run Cython. I'd prefer not to duplicate too much of > that setup. I agree. That's the reason while I'm thinking about a partial refactoring of all the Options&co. system, to provide a more coherent interface. Well, at least, I'm just evaluating at what extent it could be possible. > argparse is new and not supported by anything but 2.7 and recent 3.x > versions. Cython currently runs on Python 2.4, which rules out a dependency > on argparse. I never tried it, so I can't tell what exactly the advantages > over optparse are. They certainly can't be big enough to make up for a > duplicate implementation of Cython's cmd line parser. Fixed the issue. Simply, try: catch the import. The modules are very similar, so no more than 10 lines of overhead. When the old module will disappear, I'll just remove that lines :) --SKS ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] CmdLine.py refactoring
Sunday 7th August 2011 16:21:06, Stefan Behnel wrote: > argparse is new and not supported by anything but 2.7 and recent 3.x > versions. Cython currently runs on Python 2.4, which rules out a dependency > on argparse. I never tried it, so I can't tell what exactly the advantages > over optparse are. They certainly can't be big enough to make up for a > duplicate implementation of Cython's cmd line parser. Work on commandline is almost over, then I'll expose my refactoring proposal :) Working with argparse vs. optparse showed me that, indeed, the two things are much different (and, in this sense, argparse is more straightforward than optparse), moreover that the optparse (nor the old if: elif: approach) version cannot parse complicated commandlines (see Tests/TestCommandLine.py) - a thing which we may expect with some exoteric build system producing 10-line- long command lines (a.k.a. autotools) . As a proof of its quality, Fedora, Ubuntu and SuSe all ship a python-argparse package for older versions of python (<2.7). Given that the module is self- contained and as small as 80KB, wouldn't be feasible to add it as a build dependency? So that I could drop the alternate implementation - which, sadly, makes one of the tests from the testsuite (apart from my own) fail. Find all commits at: https://github.com/satufk/cython/commits/_commandline --SKS ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] CmdLine.py refactoring
Tuesday 9th August 2011 10:15:14, Stefan Behnel wrote: > However, I also see the problem that optparse is deprecated and may get > removed in a future 3.x version. So, switching to optparse now means that > we may have to switch to something else later, whereas that's not the case > with the current code, however clumsy and low-level it may be. I've fixed the glitches, now both versions (argparse and optparse) are supported. Still, optparse's code performs a bit faster and doesn't need a couple of HACKs that are necessary for optparse's code to run. If all tests perform correctly, I'll merge the branch into master. So, no upgrade problems, nor optparse embedding issues :) I did want to rewrite the module beacuse I think that clarity of implementation should win over milliseconds of speed. Which, I think, is the very same spirit on which Python is founded. Regards, --SKS ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
[Cython] What now?
Hi, now that I've nailed Cython code, I'd like to get into something more funny. Currently, I'm working on a set of macros to seamlessy integrate Cython into CMake build process (in fact, I love CMake). But, I'd like to work also on something more essential, so... Is there any updated TODO list? (ToDo.txt in git repo dates back to more than 8 months ago). I may also work on the wiki Cheers, --SKS ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] What now?
Thursday 11th August 2011 19:51:14, Dag Sverre Seljebotn wrote: > Error testcases in tests/errors are currently rather inconvenient, since > changing anything often shifts a lot of error message line numbers. > Something like this format might be better, where the line number is > implied from the position of the comment: > > # mode: error > > with nogil: > print 1 #ERROR:4:print statement not allowed in nogil block > > I just filed this as http://trac.cython.org/cython_trac/ticket/710 That's a good point. I've started working on it. Actually, runtests.py should be split into a module and a public run-main stub, to make it load faster. I'll try to cope with this too. --SKS ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
[Cython] Away: automagical (c)import plans
Hi folks, I'm not dead, I'm just on holiday :) Meanwhile, I've started investigating the CEP I'll be working on (http://wiki.cython.org/enhancements/overlaypythonmodules). Brainstorming: if I understood well (code is not documented) I'll have to work on Cython.Compiler.SymTab, in particular, on Scope and Entry classes. That doesn't seem difficult, but I won't say so until work is over :D Regards, --SKS ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] What now?
Sounds really interesting to me. Thanks for your proposal :) I may have to dig the internals, so, first I'll study the Compiler code. --SKS ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
