[Hamish Lawson]
> One of the arguments put forward against renaming the existing time module
> to _time (as part of incorporating a pure-Python strptime function) is that
> it could break some builds. Therefore I'd suggest that it could be a useful
> principle for any C extension added in the future to the standard library
> to have an accompanying pure-Python wrapper that would be the one that
> client code would usually import.
I am for that, but then again I am biased in this situation. =)
But it seems reasonable. I would think everyeone who makes any major
contribution of code to Python would much rather code it up in Python then
C. It would probably help to get more code accepted since I know I felt
a little daunted having to write that callout for strptime.
The only obvious objection I can see to this is a performance hit for
having to go through the Python stub to call the C extension. But I just
did a very simple test of calling strftime('%c') 25,000 times from time
directly and using a Python stub and it was .470 and .490 secs total
respectively according to profile.run().
The oher objection I can see is that this would promote coding everything
in Python when possible and that might not always be the best solution.
Some things should just be coded in C, period. But I think for such
situations that the person writing the code would most likely recognize
that fact.
Or maybe I am wrong in all of this. I don't know the exact process of how
a C extension file gets accepted or what currently leads to an extension
file getting a stub is. I would (and I am sure anyone else new to the
list) really appreciate someone possibly explaining it to me since I would
like to know.
-Brett C.
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