Nick mentioned using a single type and converting upon return, I'm starting to like that more. A limited set of time formats is mostly arbitrary, and there will always be a performance hit deciding which type to return.
The goal here is to allow high precision timings with minimal cost. A separate module, and an agreement on what the best performing high precision type is I think is the best way forward. On Feb 1, 2012 8:47 AM, "Victor Stinner" <victor.stin...@haypocalc.com> wrote: > > (I removed the timespec format, I consider that we don't need it.) > > > > Rather, I guess you removed it because it didn't fit the "types as flags" > > pattern. > > I removed it because I don't like tuple: you cannot do arithmetic on > tuple, like t2-t1. Print a tuple doesn't give you a nice output. It is > used in C because you have no other choice, but in Python, we can do > better. > > > As I said in another message, another hint that this is the wrong API > design: > > Will the APIs ever support passing in types other than these five? > Probably > > not, so I strongly believe they should not be passed in as types. > > I don't know if we should only support 3 types today, or more, but I > suppose that we will add more later (e.g. if datetime is replaced by > another new and better datetime module). > > You mean that we should use a string instead of type, so > time.time(format="decimal")? Or do something else? > > Victor > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/anacrolix%40gmail.com >
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
