On 12/10/14 7:33 AM, Nick Coghlan wrote:
On 10 December 2014 at 16:31, Matthieu Bec wrote:
newbie first post on this list, if what follows is of context ...
Hi all,
I'm struggling with issue per the subject, read different threads and issue
http://bugs.python.org/issue15443 that started 2012 still opened as of
today.
Isn't there a legitimate case for nanosecond support? it's all over the
place in 'struct timespec' and maybe wrongly I always found python and C
were best neighbors. That's for the notional aspect.
If you skip down to the more recent 2014 part of the discussion, the
use case has been accepted as valid, but the idea still needs a
concrete change proposal that addresses the various API design and
backwards compatibility issues that arise. Specifically, questions
like:
Thanks Nick.
These are typically discussed on this list or using the bug tracker?
maybe YNGTNI applied, not clear why it's not there after 2 eyars.
I'm no expert but one could imagine something reasonably simple:
- a new type datetime.struct_timespec (a la time.struct_tm)
- a new constructor datetime.time(struct_timespec), so what already
exists untouched
- pickle versioning using free bits, the new format that favors clarity
over saving byte (as described in 15443)
- not sure what's at stake with the strp/ftime() but cant imagine it's a
biggie
Regards,
Matthieu
* preserving compatibility with passing in microsecond values
* how to accept nanosecond values
* how to correctly unpickle old datetime pickle values
* how to update strptime() and strftime()
Cheers,
Nick.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
