Brett Cannon <bac@OCF.Berkeley.EDU> writes: > 2) Define our own standard on return values -- This would require > editing timemodule.c to make sure any C version that gets used conforms to > what we specify. The other option is to just remove the C version and use > the Python version exclusively; speed and backwards-compatibility be > damned, although the docs leave such a big hole open for what ``strptime`` > will do that it would still conform to the docs. =) I've not been following this much, and I come from a platform (Windows) with no C version of strptime, so I'm both grateful for the new version, and unconcerned about compatibility :-) However, I think there's a slightly less aggressive compromise. Would it be possible (or useful) to specify and document the behaviour of the Python version (essentially, "define our own standard"), but rather than jump through hoops to force C versions into conformance, just punt and say that C versions, when used, may differ in their handling of unspecified input? This probably only makes sense as an option if: a) The Python user can be expected to *know* whether they have the C version or the Python version, and b) People writing code for portability have a way of defending against the differences (or they write to the lowest common denominator of making no assumptions...) I don't know if these two assumptions are reasonable, though... Paul. -- This signature intentionally left blank
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