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 <m...@gmto.org <mailto:m...@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 <m...@gmto.org <mailto:m...@gmto.org> <mailto:m...@gmto.org <mailto:m...@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 _______________________________________________ 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/archive%40mail-archive.com
