On 1/25/2014 10:37 AM, Larry Hastings wrote: > On 01/25/2014 07:26 AM, Nick Coghlan wrote: >> However, you've indicated that adding varargs support is going to take >> you quite a bit of work, so postponing it is an option definitely >> worth considering at this point in the release cycle. > > It's worth considering. I'm estimating it's about 1.5 days' worth of > work. Mainly because, at the same time, I need to teach Clinic to have > separate namespaces for "parser" and "impl" functions. At the same time > I was going to implement a frequently-requested feature, allowing the C > variable storing an argument to have a different name than the actual > Python parameter. > > And it could be one of those "hey that was easier than I thought" > things. 1.5 days is kind of worst-case. So maybe the best thing would > be to give it a half-day and see if it turned out to be easy. > > Of course, If we bring the Derby to a close now-ish (debate going on in > python-committers right now!), then I'll definitely put it off until 3.5. I have been annoyed by the mismatch between Python signatures and C-implementation for at least a decade. Now that the idea that all functions (except possible for range) should have Python signatures seems to have been accepted, I am willing for the full implementation to wait until 3.5. I think the Derby experiment has pretty well exposed what still needs to be done, so I expect it should be possible to have it all in 3.5 as long as people do not burn out first. -- Terry Jan Reedy
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4