[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
Stefano, 07.08.2011 14:06: I've cloned GitHub repo and started working on it. Will you put it up somewhere on github? First, I'm rewriting Compiler/CmdLine.py to use the optparse/argparse module. That would help in keeping the command line help messages up to date with the actually supported options, but given that the current implementation "ain't broken", it's certainly not a priority to us. 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. Then I'll try to address the Bugzilla ticket mentioned in the source file. That's the "-r" option for recursive compilation of dependencies. I don't think it'll be all that easy to fix, but I think this would totally be worth a try. It may be easier to implement now that we have Cython.Build.Dependencies and friends. Personally, I'd recommend starting with something like that, instead of putting too much effort into the command line parser (which changes pretty rarely these days). BTW, it seems that trac is currently broken, so I can't actually look up the ticket. 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? 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. Stefan ___ 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
