➜

This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author Alexander.Belopolsky
Recipients Alexander.Belopolsky, SilentGhost, Trundle, belopolsky, georg.brandl, l0nwlf, ned.deily, sandro.tosi, vstinner, wsanchez
Date 2011-01-02.23:43:12
SpamBayes Score 4.2583203e-08
Marked as misclassified No
Message-id <AANLkTimj3KBu7=DL1E3QKP=u18nXLE4GX_bGQtcEOw-o@mail.gmail.com>
In-reply-to <1294010956.93.0.342939520634.issue8013@psf.upfronthosting.co.za>
Content 
On Sun, Jan 2, 2011 at 6:29 PM, Georg Brandl <report@bugs.python.org> wrote:
..
> You cannot have both: a safe implementation and the correct behavior with glibc
> (not Linux!) -- except if you start special-casing.  Not sure that's worth it.
>
That's the reason why this and the related ctime issue were lingering
for so long.

My plan was to pick the low-hanging fruit (the null check) for 3.3 and
leave proper bounds checking and possibly switch to reentrant APIs for
the next release.   There is a long tradition in keeping OS functions'
wrappers thin with an expectation that application programmers will
know the limitations/quirks of their target OSes.  Given that datetime
module does not have these issues, I don't see this as "must fix."
History
Date User Action Args
2011-01-02 23:43:16Alexander.Belopolskysetrecipients: + Alexander.Belopolsky, georg.brandl, belopolsky, wsanchez, vstinner, ned.deily, Trundle, SilentGhost, sandro.tosi, l0nwlf
2011-01-02 23:43:12Alexander.Belopolskylinkissue8013 messages
2011-01-02 23:43:12Alexander.Belopolskycreate