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 at gmto.org > <mailto:mbec at 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 at gmto.org > <mailto:mbec at gmto.org> > <mailto:mbec at gmto.org <mailto:mbec at 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 at python.org <mailto:Python-Dev at 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 at python.org <mailto:Python-Dev at 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 at 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
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