[Tim Peters] > [Skip Montanaro] [snip] > > Cool! Let's do just that much to start, and don't take it as "a reason" to > rename the time module either (it really is trivial to add another .py file > to Lib! give the name a leading underscore if you want to imply it's a > helper for something else). Sounds good to me. Perhaps this is the best solution for Python 2.3 (goes beta mid-July, right?). If we do this should we leave access to the C version of strptime, or move all calls over to my code? Personally, I say leave it since then any possible differences people might have with their implementation of strptime compared to mine won't affect them. This is not saying that I think there is, though; I have done my best to make sure there is not a deviance. There is also a noticeable performace difference between my implementation and the C version. I have tried to address the best I could by making locale discovery lazy and being able to have the re object used for a format string be returned so as to use that instead of having to recalculate it, but there is still going to be a difference. So basically, I am agreeing with Tim that my module should just be added as Lib/_strptime.py and my callout should just be added to timemodule.c. I will clean up the naming of my helper fxns and add __all__ to only contain strptime to keep it simple. That will get this in for 2.3 and lets this discussion of where time fxns, data types, etc. are going to be in Python. Who would of thought little old me would spark a Timbot response. =) -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