Guido van Rossum wrote: > I just found a place in my own code that broke because stat now > returns floats for mtime etc. I was using a Zope "OIBTree" object, > which is a dict-like extension type mapping strings to ints; it > very reasonbly doesn't like it if you assign a float to it. > > I'm not say that because *my* code breaks, this is a bad feature. But > I am worried that we'll find more programs using external data types > that won't accept floats (I'm thinking of Numpy arrays), and I'm now > not so sure if this is acceptable breakage... Apparently the fact > that it "works" on the Mac isn't really a great proof. > > Maybe we can introduce a variant of the stat() function that returns > floats, or alternative field names that are only available when using > attributes (not when using the tuple-ish API)? If you're suggesting a new API, why not have it return one of the new datetime objects ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/
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