datetime nanosecond support (ctd?)
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. More practically, aren't we close enough yet with current hardware, PTP and the likes, this deserves more consideration? Maybe this has been mentioned before but the limiting factor isn't just getting nanoseconds, but anything sub-microseconds wont work with the current format. OpcUA that I was looking right now has 10-th us resolution, so really cares about 100ns, but the datetime 1us simply wont cut it. Regards, Matthieu
On 10 December 2014 at 16:31, Matthieu Bec <mdcb808@gmail.com> 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: * 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. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On 12/10/14 7:33 AM, Nick Coghlan 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
On 10 December 2014 at 16:31, Matthieu Bec <mdcb808@gmail.com> wrote: 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.
mdcb808 writes:
These are typically discussed on this list or using the bug tracker?
I think this discussion belongs on python-dev because the requirement is clear, but a full specification involves backward compatibility with older interfaces, and clearly different people place different values on the various aspects of the problem. It makes sense to go straight to tracker when the design is done or obvious, or backward compatibility is clearly not involved. The tracker is also the place to record objective progress (patches, tests, bug reports). Python-Dev is where minds meet. What Nick is saying is that more design needs to be done to resolve differences of opinion on the best way to move forward.
maybe YNGTNI applied,
Evidently not. If a senior developer really thought it's a YAGNI, the issue would have been closed WONTFIX. It seems the need is believable.
not clear why it's not there after 2 eyars.
There's only one reason you need to worry about: nobody wrote a patch that meets the concerns of the senior developers (one of which is that concerns raised by anybody remain unresolved; they don't always have strong opinions themselves).[1]
- not sure what's at stake with the strp/ftime() but cant imagine it's a biggie
If you want something done, you don't necessarily need to supply a patch. But you have to do more to move things forward that just say "I can't imagine why anybody worries about that." You have to find out what their worries are, and explain that their worries won't be realized in the case of the obvious design (eg, the one you presented), or provide a design that avoids realizing those worries. Or you can get the senior developers to overrule the worriers, but you need a relatively important use case to make that fly. Or you can get somebody else to do some of the above, but that also requires presenting an important use case (to that somebody). Footnotes: [1] That's not 100% accurate: there is a shortage of senior developer time for reviewing patches. If it's simply that nobody has looked at the issue, simply bringing it up may be sufficient to get attention and then action. But Nick's response makes it clear that doesn't apply to this issue; people have looked at the issue and have unresolved concerns.
Thanks Stephen elaborating on the process. and apologies, I was dismissing the last point only half jokingly. I read the comment for strftime / strptime in the report as meant to remember to implement it. It seems picking a new format letter (or keep using "%f" if acceptable) that would accept/produce up to 9 characters instead of 6 for nanoseconds would do most of the trick. Maybe there's no issue or I don't understand it. That completes my chant to awaken the Elderers! Regards, Matthieu On 12/10/14 9:10 PM, Stephen J. Turnbull wrote:
mdcb808 writes:
These are typically discussed on this list or using the bug tracker?
I think this discussion belongs on python-dev because the requirement is clear, but a full specification involves backward compatibility with older interfaces, and clearly different people place different values on the various aspects of the problem. It makes sense to go straight to tracker when the design is done or obvious, or backward compatibility is clearly not involved. The tracker is also the place to record objective progress (patches, tests, bug reports). Python-Dev is where minds meet.
What Nick is saying is that more design needs to be done to resolve differences of opinion on the best way to move forward.
maybe YNGTNI applied,
Evidently not. If a senior developer really thought it's a YAGNI, the issue would have been closed WONTFIX. It seems the need is believable.
not clear why it's not there after 2 eyars.
There's only one reason you need to worry about: nobody wrote a patch that meets the concerns of the senior developers (one of which is that concerns raised by anybody remain unresolved; they don't always have strong opinions themselves).[1]
- not sure what's at stake with the strp/ftime() but cant imagine it's a biggie
If you want something done, you don't necessarily need to supply a patch. But you have to do more to move things forward that just say "I can't imagine why anybody worries about that." You have to find out what their worries are, and explain that their worries won't be realized in the case of the obvious design (eg, the one you presented), or provide a design that avoids realizing those worries. Or you can get the senior developers to overrule the worriers, but you need a relatively important use case to make that fly.
Or you can get somebody else to do some of the above, but that also requires presenting an important use case (to that somebody).
Footnotes: [1] That's not 100% accurate: there is a shortage of senior developer time for reviewing patches. If it's simply that nobody has looked at the issue, simply bringing it up may be sufficient to get attention and then action. But Nick's response makes it clear that doesn't apply to this issue; people have looked at the issue and have unresolved concerns.
On Thu, Dec 11, 2014 at 11:58 AM, Matthieu Bec <mdcb808@gmail.com> wrote:
...or keep using "%f" if acceptable...
That might be a problem. While it will probably work most of the time, there are likely to be situations where the caller assumes it generates a six-digit string. I did a little poking around. It seems like "%N" isn't used. Skip
Another issue to consider here is that parsing and printing should be symmetrical. The %f format gobbles up exactly 6 digits. Finally, strptime and strftime are not invented by Python, the same functions with (mostly) the same format characters are defined by other languages. Is there not a single other language that has added support for nanoseconds to its strftime/strptime? (I wouldn't be surprised if there wasn't -- while computer clocks have a precision in nanoseconds, that doesn't mean they are that *accurate* at all (even with ntpd running). On Thu, Dec 11, 2014 at 10:33 AM, Skip Montanaro <skip.montanaro@gmail.com> wrote:
On Thu, Dec 11, 2014 at 11:58 AM, Matthieu Bec <mdcb808@gmail.com> wrote:
...or keep using "%f" if acceptable...
That might be a problem. While it will probably work most of the time, there are likely to be situations where the caller assumes it generates a six-digit string. I did a little poking around. It seems like "%N" isn't used.
Skip _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%40python.org
-- --Guido van Rossum (python.org/~guido)
I think strftime / strptime support is a low-priority concern on this topic, and can probably be discussed independently of the core nanosecond support. Regards Antoine. On Thu, 11 Dec 2014 11:14:27 -0800 Guido van Rossum <guido@python.org> wrote:
Another issue to consider here is that parsing and printing should be symmetrical. The %f format gobbles up exactly 6 digits.
Finally, strptime and strftime are not invented by Python, the same functions with (mostly) the same format characters are defined by other languages. Is there not a single other language that has added support for nanoseconds to its strftime/strptime? (I wouldn't be surprised if there wasn't -- while computer clocks have a precision in nanoseconds, that doesn't mean they are that *accurate* at all (even with ntpd running).
On Thu, Dec 11, 2014 at 10:33 AM, Skip Montanaro <skip.montanaro@gmail.com> wrote:
On Thu, Dec 11, 2014 at 11:58 AM, Matthieu Bec <mdcb808@gmail.com> wrote:
...or keep using "%f" if acceptable...
That might be a problem. While it will probably work most of the time, there are likely to be situations where the caller assumes it generates a six-digit string. I did a little poking around. It seems like "%N" isn't used.
Skip _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%40python.org
On Thu, Dec 11, 2014 at 1:23 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:
I think strftime / strptime support is a low-priority concern on this topic, and can probably be discussed independently of the core nanosecond support.
Might be low-priority, but with %f support as a template, supporting something to specify nanoseconds should be pretty trivial. The hardest question will be to convince ourselves that we aren't choosing a format code which some other strftime/strptime implementation is already using. In addition, ISTR that one of the use cases was analysis of datetime data generated by other applications which has nanosecond resolution. Unless those values are stored as epoch seconds, you're going to need to parse them. It's not clear to me why you'd give people only half the solution they need. Skip
On Thu, 11 Dec 2014 13:43:05 -0600 Skip Montanaro <skip.montanaro@gmail.com> wrote:
On Thu, Dec 11, 2014 at 1:23 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:
I think strftime / strptime support is a low-priority concern on this topic, and can probably be discussed independently of the core nanosecond support.
Might be low-priority, but with %f support as a template, supporting something to specify nanoseconds should be pretty trivial. The hardest question will be to convince ourselves that we aren't choosing a format code which some other strftime/strptime implementation is already using.
In addition, ISTR that one of the use cases was analysis of datetime data generated by other applications which has nanosecond resolution.
One of the use cases is to deal with OS-generated timestamps without losing information. As long as you don't need to represent or parse those timestamps, strptime / strftime don't come into the picture. Regards Antoine.
Agreed with Antoine, strftime/strptime are somewhat different concerns. Doesn't mean thay cannot be fixed at the same time but it's a bit a separate. I'm not sure this thread / discussion has reached critical mass yet, meanwhile I was looking at what was involved and came up with this half-baked patch - by no way meant to be complete or correct, but rather get a feel to it. I can't help thinking this is much more involved than I first expected, and what I try to achieve should be reasonably simple. Stepping back a little, I wonder if the datetime module is really the right location, that has constructor(year, month, day, ..., second, microsecond) - with 0<ms<999999, no millis. adding 0<ns<999 would seem quite ugly, in fact nothing looks quite right. datetime seems to be dealing with 'calendar time' stuff - and to some extent, maybe, shouldn't concern itself so much with fraction of seconds. I'm pondering now if the 'time' module that seems to be dealing with 'computer clock time' wouldn't be a better target to introduce struct_timespec and the like. I'd be curious to hear back from this list, if this deserves more investigation or what might be a better way to go. Regards, Matthieu On 12/11/2014 11:46 AM, Antoine Pitrou wrote:
On Thu, 11 Dec 2014 13:43:05 -0600 Skip Montanaro <skip.montanaro@gmail.com> wrote:
On Thu, Dec 11, 2014 at 1:23 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:
I think strftime / strptime support is a low-priority concern on this topic, and can probably be discussed independently of the core nanosecond support.
Might be low-priority, but with %f support as a template, supporting something to specify nanoseconds should be pretty trivial. The hardest question will be to convince ourselves that we aren't choosing a format code which some other strftime/strptime implementation is already using.
In addition, ISTR that one of the use cases was analysis of datetime data generated by other applications which has nanosecond resolution.
One of the use cases is to deal with OS-generated timestamps without losing information. As long as you don't need to represent or parse those timestamps, strptime / strftime don't come into the picture.
Regards
Antoine. _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/mdcb808%40gmail.com
-- Matthieu Bec GMTO Corp cell : +1 626 425 7923 251 S Lake Ave, Suite 300 phone: +1 626 204 0527 Pasadena, CA 91101
On Tue, Dec 16, 2014 at 11:10 AM, matthieu bec <mbec@gmto.org> wrote:
Agreed with Antoine, strftime/strptime are somewhat different concerns. Doesn't mean thay cannot be fixed at the same time but it's a bit a separate.
Which reminds me... Somewhere else (maybe elsewhere in this thread? maybe on a bug tracker issue?) someone mentioned that Ruby uses %N for fractions of a second (and %L specifically for milliseconds). Here's the bit from the Ruby strftime doc: %L - Millisecond of the second (000..999) %N - Fractional seconds digits, default is 9 digits (nanosecond) %3N millisecond (3 digits) %6N microsecond (6 digits) %9N nanosecond (9 digits) %12N picosecond (12 digits) There's no obvious reason I can see to reinvent this particular wheel, at least the %N spoke. The only question might be whether to modify Python's existing %f format to accept a precision (defaulting to 6), or add %N in a manner similar (or identical) to Ruby's semantics. Skip
I vote to copy Ruby's %N and leave %f alone. On Tue, Dec 16, 2014 at 11:08 AM, Skip Montanaro <skip.montanaro@gmail.com> wrote:
On Tue, Dec 16, 2014 at 11:10 AM, matthieu bec <mbec@gmto.org> wrote:
Agreed with Antoine, strftime/strptime are somewhat different concerns. Doesn't mean thay cannot be fixed at the same time but it's a bit a separate.
Which reminds me... Somewhere else (maybe elsewhere in this thread? maybe on a bug tracker issue?) someone mentioned that Ruby uses %N for fractions of a second (and %L specifically for milliseconds). Here's the bit from the Ruby strftime doc:
%L - Millisecond of the second (000..999) %N - Fractional seconds digits, default is 9 digits (nanosecond) %3N millisecond (3 digits) %6N microsecond (6 digits) %9N nanosecond (9 digits) %12N picosecond (12 digits)
There's no obvious reason I can see to reinvent this particular wheel, at least the %N spoke. The only question might be whether to modify Python's existing %f format to accept a precision (defaulting to 6), or add %N in a manner similar (or identical) to Ruby's semantics.
Skip
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%40python.org
-- --Guido van Rossum (python.org/~guido)
yes that was mentioned in this thread, %nN looks quite reasonable. still, I'd like to steer the conversation back to the other aspect - where should something like struct_timespec land in the first place, is datetime really the best to capture that? Most of the conversation has been revolving around strftime/strptime. That seems to validate Antoine's point in the first place. Let's see what people say but maybe this thread should end to restart as separate topics? Regards, Matthieu On 12/16/14 11:08 AM, Skip Montanaro wrote:
On Tue, Dec 16, 2014 at 11:10 AM, matthieu bec <mbec@gmto.org <mailto:mbec@gmto.org>> wrote:
Agreed with Antoine, strftime/strptime are somewhat different concerns. Doesn't mean thay cannot be fixed at the same time but it's a bit a separate.
Which reminds me... Somewhere else (maybe elsewhere in this thread? maybe on a bug tracker issue?) someone mentioned that Ruby uses %N for fractions of a second (and %L specifically for milliseconds). Here's the bit from the Ruby strftime doc:
%L - Millisecond of the second (000..999) %N - Fractional seconds digits, default is 9 digits (nanosecond) %3N millisecond (3 digits) %6N microsecond (6 digits) %9N nanosecond (9 digits) %12N picosecond (12 digits)
There's no obvious reason I can see to reinvent this particular wheel, at least the %N spoke. The only question might be whether to modify Python's existing %f format to accept a precision (defaulting to 6), or add %N in a manner similar (or identical) to Ruby's semantics.
Skip
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/mdcb808%40gmail.com
-- Matthieu Bec GMTO Corp cell : +1 626 425 7923 251 S Lake Ave, Suite 300 phone: +1 626 204 0527 Pasadena, CA 91101
Aren't the wrappers for the kernel's time-related structs typically in the time module? That seems the place to start. Eventually we can support going between those structs and the datetype datatype (the latter may have to grow an option to specify nsec). On Tue, Dec 16, 2014 at 11:21 AM, Matthieu Bec <mbec@gmto.org> wrote:
yes that was mentioned in this thread, %nN looks quite reasonable.
still, I'd like to steer the conversation back to the other aspect - where should something like struct_timespec land in the first place, is datetime really the best to capture that?
Most of the conversation has been revolving around strftime/strptime. That seems to validate Antoine's point in the first place.
Let's see what people say but maybe this thread should end to restart as separate topics?
Regards, Matthieu
On 12/16/14 11:08 AM, Skip Montanaro wrote:
On Tue, Dec 16, 2014 at 11:10 AM, matthieu bec <mbec@gmto.org <mailto:mbec@gmto.org>> wrote:
Agreed with Antoine, strftime/strptime are somewhat different concerns. Doesn't mean thay cannot be fixed at the same time but it's a bit a separate.
Which reminds me... Somewhere else (maybe elsewhere in this thread? maybe on a bug tracker issue?) someone mentioned that Ruby uses %N for fractions of a second (and %L specifically for milliseconds). Here's the bit from the Ruby strftime doc:
%L - Millisecond of the second (000..999) %N - Fractional seconds digits, default is 9 digits (nanosecond) %3N millisecond (3 digits) %6N microsecond (6 digits) %9N nanosecond (9 digits) %12N picosecond (12 digits)
There's no obvious reason I can see to reinvent this particular wheel, at least the %N spoke. The only question might be whether to modify Python's existing %f format to accept a precision (defaulting to 6), or add %N in a manner similar (or identical) to Ruby's semantics.
Skip
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/ mdcb808%40gmail.com
-- Matthieu Bec GMTO Corp cell : +1 626 425 7923 251 S Lake Ave, Suite 300 phone: +1 626 204 0527 Pasadena, CA 91101 _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/ guido%40python.org
-- --Guido van Rossum (python.org/~guido)
On Tue, Dec 16, 2014 at 12:10 PM, matthieu bec <mbec@gmto.org> wrote:
I wonder if the datetime module is really the right location, that has constructor(year, month, day, ..., second, microsecond) - with 0<ms<999999, no millis. adding 0<ns<999 would seem quite ugly, in fact nothing looks quite right.
We can make nanosecond a keyword-only argument, so that time(1, 2, 3, nanosecond=123456789) -> 01:02:03.123456789 and time(1, 2, 3, 4, nanosecond=123456789) -> error Users will probably be encouraged to avoid positional form when specifying time to subsecond precision. I would say time(1, 2, 3, microsecond=4) is clearer than time(1, 2, 3, 4) anyways. Another option is to allow float for the "second" argument: time(1, 2, 3.123456789) -> 01:02:03.123456789
Maybe what I meant with `nothing looks quite right': seconds as float, microseconds as float, nanosecond as 0..999, nanoseconds as 0..999999999 with mandatory keyword that precludes microseconds - all can be made to work, none seems completely satisfying. In fact, I don't really have a use for it from python - but something would be needed in C for the implementation of datetime.from_timespec and time.from_timespec that calls the constructor PyObjectCall_CallFunction(clas,"...",...) - can this happen and remain hidden from the python layer? Regards, Matthieu On 12/16/14 12:45 PM, Alexander Belopolsky wrote:
On Tue, Dec 16, 2014 at 12:10 PM, matthieu bec <mbec@gmto.org <mailto:mbec@gmto.org>> wrote:
I wonder if the datetime module is really the right location, that has constructor(year, month, day, ..., second, microsecond) - with 0<ms<999999, no millis. adding 0<ns<999 would seem quite ugly, in fact nothing looks quite right.
We can make nanosecond a keyword-only argument, so that
time(1, 2, 3, nanosecond=123456789) -> 01:02:03.123456789
and
time(1, 2, 3, 4, nanosecond=123456789) -> error
Users will probably be encouraged to avoid positional form when specifying time to subsecond precision. I would say time(1, 2, 3, microsecond=4) is clearer than time(1, 2, 3, 4) anyways.
Another option is to allow float for the "second" argument:
time(1, 2, 3.123456789) -> 01:02:03.123456789
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/mdcb808%40gmail.com
-- Matthieu Bec GMTO Corp cell : +1 626 425 7923 251 S Lake Ave, Suite 300 phone: +1 626 204 0527 Pasadena, CA 91101
On 12/16/14 3:28 PM, Matthieu Bec wrote:
Maybe what I meant with `nothing looks quite right': seconds as float, microseconds as float, nanosecond as 0..999, nanoseconds as 0..999999999 with mandatory keyword that precludes microseconds - all can be made to work, none seems completely satisfying.
In fact, I don't really have a use for it from python - but something would be needed in C for the implementation of datetime.from_timespec and time.from_timespec that calls the constructor
that's the datetime.time.from_timespec btw.
PyObjectCall_CallFunction(clas,"...",...) - can this happen and remain hidden from the python layer?
Regards, Matthieu
On 12/16/14 12:45 PM, Alexander Belopolsky wrote:
On Tue, Dec 16, 2014 at 12:10 PM, matthieu bec <mbec@gmto.org <mailto:mbec@gmto.org>> wrote:
I wonder if the datetime module is really the right location, that has constructor(year, month, day, ..., second, microsecond) - with 0<ms<999999, no millis. adding 0<ns<999 would seem quite ugly, in fact nothing looks quite right.
We can make nanosecond a keyword-only argument, so that
time(1, 2, 3, nanosecond=123456789) -> 01:02:03.123456789
and
time(1, 2, 3, 4, nanosecond=123456789) -> error
Users will probably be encouraged to avoid positional form when specifying time to subsecond precision. I would say time(1, 2, 3, microsecond=4) is clearer than time(1, 2, 3, 4) anyways.
Another option is to allow float for the "second" argument:
time(1, 2, 3.123456789) -> 01:02:03.123456789
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/mdcb808%40gmail.com
-- Matthieu Bec GMTO Corp cell : +1 626 425 7923 251 S Lake Ave, Suite 300 phone: +1 626 204 0527 Pasadena, CA 91101
On 12/16/14 3:31 PM, Matthieu Bec wrote:
On 12/16/14 3:28 PM, Matthieu Bec wrote:
Maybe what I meant with `nothing looks quite right': seconds as float, microseconds as float, nanosecond as 0..999, nanoseconds as 0..999999999 with mandatory keyword that precludes microseconds - all can be made to work, none seems completely satisfying.
In fact, I don't really have a use for it from python - but something would be needed in C for the implementation of datetime.from_timespec and time.from_timespec that calls the constructor
that's the datetime.time.from_timespec btw.
datetime.time.from_timespec actually makes no sense.
PyObjectCall_CallFunction(clas,"...",...) - can this happen and remain hidden from the python layer?
... occured to me I might simply create a us datetime object and set its nanofield after. I'll try wrap up a recap proposal later. Regards, Matthieu
Attached patch defines a new type struct_timespec for the time module. A new capsule exports the type along with to/from converters - opening a bridge for C, and for example the datetime module. Your comments welcomed. If people feel this is worth the effort and going the right direction, I should be able to finish doco, unit-tests, whatever else is missing with a bit of guidance and move on other datetime aspects. Regards, Matthieu
On Wed, Dec 17, 2014 at 7:52 PM, Matthieu Bec <mdcb808@gmail.com> wrote:
Attached patch defines a new type struct_timespec for the time module. A new capsule exports the type along with to/from converters - opening a bridge for C, and for example the datetime module.
I'd recommend opening a new issue in the bug tracker (bugs.python.org) and attach the patch there. Attaching it to an email is a good way for it to get lost and forgotten. :) -eric
done - http://bugs.python.org/issue23084 On 12/17/14 8:20 PM, Eric Snow wrote:
On Wed, Dec 17, 2014 at 7:52 PM, Matthieu Bec <mdcb808@gmail.com> wrote:
Attached patch defines a new type struct_timespec for the time module. A new capsule exports the type along with to/from converters - opening a bridge for C, and for example the datetime module.
I'd recommend opening a new issue in the bug tracker (bugs.python.org) and attach the patch there. Attaching it to an email is a good way for it to get lost and forgotten. :)
-eric
FWIW issue23084 was withdrawn as it appears to be touching and PEP sized, and/or anyways nanosec is defacto just an int. another patch went to http://bugs.python.org/issue15443 seemingly under the radar, I'm not arguing the quality of the patch, but bringing it up here in case with the holidays season it didn't get noticed. I wont bring much anything more so you may rest otherwise. Happy new year! On 12/18/2014 12:47 PM, mdcb808 wrote:
done - http://bugs.python.org/issue23084
On 12/17/14 8:20 PM, Eric Snow wrote:
On Wed, Dec 17, 2014 at 7:52 PM, Matthieu Bec <mdcb808@gmail.com> wrote:
Attached patch defines a new type struct_timespec for the time module. A new capsule exports the type along with to/from converters - opening a bridge for C, and for example the datetime module.
I'd recommend opening a new issue in the bug tracker (bugs.python.org) and attach the patch there. Attaching it to an email is a good way for it to get lost and forgotten. :)
-eric
-- Matthieu Bec GMTO Corp cell : +1 626 425 7923 251 S Lake Ave, Suite 300 phone: +1 626 204 0527 Pasadena, CA 91101
"Nothing looks quite right" is a common phenomenon when you're constrained by backward compatibility. The perfect solution would throw away compatibility, but that has its own downsides. So just go for what looks the least wrong. On Tue, Dec 16, 2014 at 3:28 PM, Matthieu Bec <mbec@gmto.org> wrote:
Maybe what I meant with `nothing looks quite right': seconds as float, microseconds as float, nanosecond as 0..999, nanoseconds as 0..999999999 with mandatory keyword that precludes microseconds - all can be made to work, none seems completely satisfying.
In fact, I don't really have a use for it from python - but something would be needed in C for the implementation of datetime.from_timespec and time.from_timespec that calls the constructor PyObjectCall_CallFunction(clas,"...",...) - can this happen and remain hidden from the python layer?
Regards, Matthieu
On 12/16/14 12:45 PM, Alexander Belopolsky wrote:
On Tue, Dec 16, 2014 at 12:10 PM, matthieu bec <mbec@gmto.org <mailto:mbec@gmto.org>> wrote:
I wonder if the datetime module is really the right location, that has constructor(year, month, day, ..., second, microsecond) - with 0<ms<999999, no millis. adding 0<ns<999 would seem quite ugly, in fact nothing looks quite right.
We can make nanosecond a keyword-only argument, so that
time(1, 2, 3, nanosecond=123456789) -> 01:02:03.123456789
and
time(1, 2, 3, 4, nanosecond=123456789) -> error
Users will probably be encouraged to avoid positional form when specifying time to subsecond precision. I would say time(1, 2, 3, microsecond=4) is clearer than time(1, 2, 3, 4) anyways.
Another option is to allow float for the "second" argument:
time(1, 2, 3.123456789) -> 01:02:03.123456789
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/ mdcb808%40gmail.com
-- Matthieu Bec GMTO Corp cell : +1 626 425 7923 251 S Lake Ave, Suite 300 phone: +1 626 204 0527 Pasadena, CA 91101 _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/ guido%40python.org
-- --Guido van Rossum (python.org/~guido)
python-n (for next) - just poking fun at the other thread On 12/16/14 4:17 PM, Guido van Rossum wrote:
"Nothing looks quite right" is a common phenomenon when you're constrained by backward compatibility. The perfect solution would throw away compatibility, but that has its own downsides. So just go for what looks the least wrong.
On Tue, Dec 16, 2014 at 3:28 PM, Matthieu Bec <mbec@gmto.org <mailto:mbec@gmto.org>> wrote:
Maybe what I meant with `nothing looks quite right': seconds as float, microseconds as float, nanosecond as 0..999, nanoseconds as 0..999999999 with mandatory keyword that precludes microseconds - all can be made to work, none seems completely satisfying.
In fact, I don't really have a use for it from python - but something would be needed in C for the implementation of datetime.from_timespec and time.from_timespec that calls the constructor PyObjectCall_CallFunction(__clas,"...",...) - can this happen and remain hidden from the python layer?
Regards, Matthieu
On 12/16/14 12:45 PM, Alexander Belopolsky wrote:
On Tue, Dec 16, 2014 at 12:10 PM, matthieu bec <mbec@gmto.org <mailto:mbec@gmto.org> <mailto:mbec@gmto.org <mailto:mbec@gmto.org>>> wrote:
I wonder if the datetime module is really the right location, that has constructor(year, month, day, ..., second, microsecond) - with 0<ms<999999, no millis. adding 0<ns<999 would seem quite ugly, in fact nothing looks quite right.
We can make nanosecond a keyword-only argument, so that
time(1, 2, 3, nanosecond=123456789) -> 01:02:03.123456789
and
time(1, 2, 3, 4, nanosecond=123456789) -> error
Users will probably be encouraged to avoid positional form when specifying time to subsecond precision. I would say time(1, 2, 3, microsecond=4) is clearer than time(1, 2, 3, 4) anyways.
Another option is to allow float for the "second" argument:
time(1, 2, 3.123456789 <tel:3.123456789>) -> 01:02:03.123456789
_________________________________________________ Python-Dev mailing list Python-Dev@python.org <mailto:Python-Dev@python.org> https://mail.python.org/__mailman/listinfo/python-dev <https://mail.python.org/mailman/listinfo/python-dev> Unsubscribe: https://mail.python.org/__mailman/options/python-dev/__mdcb808%40gmail.com <https://mail.python.org/mailman/options/python-dev/mdcb808%40gmail.com>
-- Matthieu Bec GMTO Corp cell : +1 626 425 7923 <tel:%2B1%20626%20425%207923> 251 S Lake Ave, Suite 300 phone: +1 626 204 0527 <tel:%2B1%20626%20204%200527> Pasadena, CA 91101 _________________________________________________ Python-Dev mailing list Python-Dev@python.org <mailto:Python-Dev@python.org> https://mail.python.org/__mailman/listinfo/python-dev <https://mail.python.org/mailman/listinfo/python-dev> Unsubscribe: https://mail.python.org/__mailman/options/python-dev/__guido%40python.org <https://mail.python.org/mailman/options/python-dev/guido%40python.org>
-- --Guido van Rossum (python.org/~guido <http://python.org/~guido>)
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/mdcb808%40gmail.com
-- Matthieu Bec GMTO Corp cell : +1 626 425 7923 251 S Lake Ave, Suite 300 phone: +1 626 204 0527 Pasadena, CA 91101
On 12/11/2014 11:14 AM, Guido van Rossum wrote:
(I wouldn't be surprised if there wasn't -- while computer clocks have a precision in nanoseconds, that doesn't mean they are that *accurate* at all (even with ntpd running).
[reading issue] The real-world use cases deal with getting this information from other devices (network cards, GPS, particle accelerators, etc.), so it's not really a matter of cross-computer accurancy, but relative accuracy (i.e. how long did something take?). All in all, looks like a good idea. -- ~Ethan~
Ethan Furman <ethan@stoneleaf.us>:
On 12/11/2014 11:14 AM, Guido van Rossum wrote:
(I wouldn't be surprised if there wasn't -- while computer clocks have a precision in nanoseconds, that doesn't mean they are that *accurate* at all (even with ntpd running).
The real-world use cases deal with getting this information from other devices (network cards, GPS, particle accelerators, etc.), so it's not really a matter of cross-computer accurancy, but relative accuracy (i.e. how long did something take?).
It would be nice if it were possible to deal with high-precision epoch times and time deltas without special tricks. I have had to deal with femtosecond-precision IRL (albeit in a realtime C application, not in Python). Quad-precision floats (<URL: http://en.wikipedia.org/wiki/Quadruple-precision_floating-point_format>) would do it for Python: * just do it in seconds * have enough precision for any needs * have enough renge for any needs Marko
On 2014-12-11 18:33, Skip Montanaro wrote:
On Thu, Dec 11, 2014 at 11:58 AM, Matthieu Bec <mdcb808@gmail.com> wrote:
...or keep using "%f" if acceptable...
That might be a problem. While it will probably work most of the time, there are likely to be situations where the caller assumes it generates a six-digit string. I did a little poking around. It seems like "%N" isn't used.
Could the number of digits be specified? You could have "%9f" for nanoseconds, "%3f" for milliseconds, etc. The default would be 6 microseconds for backwards compatibility. Maybe, also, strptime could support "%*f" to gobble as many digits as are available.
2014-12-11 22:00 GMT+01:00 MRAB <python@mrabarnett.plus.com>:
On 2014-12-11 18:33, Skip Montanaro wrote:
there are likely to be situations where the caller assumes it generates a six-digit string. I did a little poking around. It seems like "%N" isn't used.
Could the number of digits be specified? You could have "%9f" for
nanoseconds, "%3f" for milliseconds, etc. The default would be 6 microseconds for backwards compatibility.
Ruby does that, but use %9N. (a plain %N consume 9 digits by default). GNU date also use %N, but doesn't allow to specify the number of digits to consume.
participants (16)
-
Alexander Belopolsky -
Antoine Pitrou -
Eric Snow -
Ethan Furman -
Greg Ewing -
Guido van Rossum -
Marko Rauhamaa -
matthieu bec -
Matthieu Bec
-
Matthieu Bec -
mdcb808
-
MRAB -
Nick Coghlan -
schmeii -
Skip Montanaro -
Stephen J. Turnbull