Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3
Nick Coghlan, 14.02.2012 05:44: > On Tue, Feb 14, 2012 at 2:25 PM, Eli Bendersky wrote: >> With the deprecation warning being silent, is there much to lose, though? > > Yes, it creates problems for anyone that deliberately converts all > warnings to errors when running their test suites. This forces them to > spend time switching over to a Python version dependent import of > either cElementTree or ElementTree that could have been spent doing > something actually productive instead of mere busywork. > > And, of course, even people that *don't* convert warnings to errors > when running tests will have to make the same switch when the module > is eventually removed. I'm -1 on emitting a deprecation warning just because cElementTree is being replaced by a bare import. That's an implementation detail, just like cElementTree should have been an implementation detail in the first place. In all currently maintained CPython releases, importing cElementTree is the right thing to do for users. These days, other Python implementations already provide the cElementTree module as a bare alias for ElementTree.py anyway, without emitting any warnings. Why should CPython be the only one that shouts at users for importing it? Stefan ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3
On 2012-02-14, at 08:58 , Stefan Behnel wrote: > > These days, other Python implementations already provide the cElementTree > module as a bare alias for ElementTree.py anyway, without emitting any > warnings. Why should CPython be the only one that shouts at users for > importing it? Since all warnings are now silent by default (including DeprecationWarning), it's less of a shout and more of an eyebrow-frown and a tut-tuting really. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 410 (Decimal timestamp): the implementation is ready for a review
> A datetime module based approach would need to either use a mix of
> datetime.datetime() (when returning an absolute time) and
> datetime.timedelta() (when returning a time relative to an unknown
> starting point),
Returning a different type depending on the function would be
surprising and confusing.
time.clock_gettime(CLOCK_REALTIME) would return datetime.datetime,
whereas time.clock_gettime(CLOCK_MONOTONIC) would return
datetime.timedelta?
Or time.clock_gettime(CLOCK_REALTIME) would return datetime.timedelta
whereas time.time() would return datetime.datetime? What would be the
logic?
> or else just always return datetime.timedelta (even
> when we know the epoch and could theoretically make the time
> absolute).
datetime.timedelta is similar to decimal.Decimal, but I don't want to
support both, one is enough. I prefer Decimal because it is simpler
and "compatible" with float.
> In the former case, it may be appropriate to adopt a boolean flag API
> design and the "I want high precision time" request marker would just
> be "datetime=True". You'd then get back either datetime.datetime() or
> datetime.timedelta() as appropriate for the specific API.
A boolean flag has a problem with the import of the decimal module:
time.time(decimal=True) would need an implicit ("hidden") import of
the decimal module.
Another argument present in the PEP:
"The boolean argument API was rejected because it is not "pythonic".
Changing the return type with a parameter value is preferred over a
boolean parameter (a flag)."
http://www.python.org/dev/peps/pep-0410/#add-a-boolean-argument
> If handed a datetime value, you need to know the correct epoch value,
> do the subtraction, then extract the full precision timestamp from the
> resulting timedelta object.
datetime.datetime don't have a .totimestamp() method.
If I remember correctly, time.mktime(datetime.datetime.timetuple())
has issues with timezone and the DST.
> - implement __int__ and __float__ on timedelta (where the latter is
> just "self.total_seconds()" and the former
> "int(self.total_seconds())")
It looks like an hack. Why would float(timedelta) return seconds? Why
not minutes or nanoseconds? I prefer an unambiguously and explicit
.toseconds() method.
> The big problem is that datetime and
> timedelta pose a huge problem for compatibility with existing third
> party APIs that accept timestamp values.
I just think that datetime and timedelta are overkill and have more
drawbacks than advantages. FYI when I implemented datetime, it just
just implemented by calling datetime.datetime.fromtimestamp(). The
user can do an explicit call to this function, and
datetime.timedelta(seconds=ts) for timedelta.
> This is in stark contrast to what happens with decimal.Decimal:
> coercion to float() or int() will potentially lose precision, but
> still basically works. While addition and subtraction of floats will
> fail, addition and subtraction of integers works fine. To avoid losing
> precision, it's sufficient to just avoid the coercion.
Why would you like to mix Decimal and float? If you ask explicitly to
get Decimal timestamps, you should use Decimal everywhere or you lose
advantages of this type (and may get TypeError).
> I think the outline above really illustrates why the *raw* data type
> for timestamps should just be a number, not a higher level semantic
> type like timedelta or datetime. Eventually, you want to be able to
> express a timestamp as a number of seconds relative to a particular
> epoch. To do that, you want a number. Originally, we used ints, then,
> to support microsecond resolution, we used floats. The natural
> progression to support arbitrary resolutions is to decimal.Decimal.
Yep.
> Then, the higher level APIs can be defined in *terms* of that high
> precision number. Would it be nice if there was a PyPI module that
> provided APIs that converted the raw timestamps in stat objects and
> other OS level APIs into datetime() and timedelta() objects as
> appropriate?
Do you really need a module to call
datetime.datetime.fromtimestamp(ts) and
datetime.timedelta(seconds=ts)?
> timedelta.total_seconds() can be updated to accept a "timestamp" argument
Yes, it would be consistent with the other changes introduced by the PEP.
> Also, by using decimal.Decimal, we open up the possibility of, at some
> point in the future, switching to returning high precision values by
> default
I don't think that it is necessary. Few people need this precision and
float will always be faster than Decimal because float is implemented
in *hardware* (FPU).
I read somewhere that IBM plans to implement decimal float in their
CPU, but I suppose than it will also have a "small" size like 64 bits,
whereas 64 bits is not enough for a nanosecond resolution (same issue
than binary float).
> implicit promotion of floats to decimal values in binary
> operations without losing data
I don't think that such change would be accepted. You should ask
Stephan Krah or Mark Di
Re: [Python-Dev] PEP 410 (Decimal timestamp): the implementation is ready for a review
FWIW, I'm with Barry on this; doing more with the datetime types seems preferable to introducing yet more different stuff to date/time handling. On Mon, Feb 13, 2012 at 19:33, Victor Stinner wrote: > Oh, I forgot to mention my main concern about datetime: many functions > returning timestamp have an undefined starting point (an no timezone > information ), and so cannot be converted to datetime: > - time.clock(), time.wallclock(), time.monotonic(), > time.clock_gettime() (except for CLOCK_REALTIME) > - time.clock_getres() > - signal.get/setitimer() > - os.wait3(), os.wait4(), resource.getrusage() > - etc. > > Allowing datetime.datetime type just for few functions (like > datetime.datetime or time.time) but not the others (raise an > exception) is not an acceptable solution. It seems fairly simple to suggest that the functions with an undefined starting point could return a timedelta instead of a datetime? >> * datetime.datetime has ordering issues with daylight saving time (DST) in >> the duplicate hour of switching from DST to normal time. >> >> Sure, but only for timezone-ful datetimes, right? > > I don't know enough this topic to answer. Martin von Loewis should > answer to this question! Yes, this should only be an issue for dates with timezones. >> * datetime.datetime is not as well integrated than Epoch timestamps, some >> functions don't accept this type as input. For example, os.utime() expects >> a tuple of Epoch timestamps. >> >> So, by implication, Decimal is better integrated by virtue of its ability to >> be coerced to floats and other numeric stack types? > > Yes. decimal.Decimal is already supported by all functions accepting > float (all functions expecting timestamps). I suppose something like os.utime() could be changed to also accept datetimes. >> If it really is impossible or suboptimal to build high resolution datetimes >> and timedeltas, and to use them in these APIs, then at the very least, the >> PEP >> needs a stronger rationale for why this is. > > IMO supporting nanosecond in datetime and timedelta is an orthogonal issue. Not if you use it to cast them aside for this issue. ;) Cheers, Dirkjan ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 410 (Decimal timestamp): the implementation is ready for a review
>> IMO supporting nanosecond in datetime and timedelta is an orthogonal issue. > > Not if you use it to cast them aside for this issue. ;) Hum yes, I wanted to say that even if we don't keep datetime as a supported type for time.time(), we can still patch the type to make it support nanosecond resolution. Victor ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 394 request for pronouncement (python2 symlink in *nix systems)
On Feb 14, 2012, at 12:38 PM, Nick Coghlan wrote: >> One other thing I'd like to see the PEP address is a possible migration >> strategy to python->python3. Even if that strategy is "don't do it, man!". >> IOW, can a distribution change the 'python' symlink once it's pointed to >> python2? What is the criteria for that? Is it up to a distribution? Will >> the PEP get updated when our collective wisdom says its time to change the >> default? etc. > >I have no idea, and I'm not going to open that can of worms for this >PEP. We need to say something about the executable aliases so that >people can eventually write cross-platform python2 shebang lines, but >how particular distros actually manage the transition is going to >depend more on their infrastructure and community than it is anything >to do with us. Then I think all the PEP needs to say is that it is explicitly up to the distros to determine if, when, where, and how they transition. I.e. take it off of python-dev's plate. Cheers, -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3
On Mon, Feb 13, 2012 at 23:16, Nick Coghlan wrote: > On Tue, Feb 14, 2012 at 1:42 PM, Eli Bendersky wrote: > > An open question remains on whether to deprecate cElementTree, now that > this > > change is in place. > > > > Currently in 3.3 the whole cElementTree module is: > > > > # Deprecated alias for xml.etree.ElementTree > > > > from xml.etree.ElementTree import * > > > > Would it be alright to issue a DeprecationWarning if this module is > > imported? Then hopefully a couple of releases after 3.3 we can just dump > it. > > What do we really gain by dumping it, though? Just add a CPython > specific test that ensures: > >for key, value in xml.etree.ElementTree.__dict__.items(): >self.assertIs(getattr(xml.etree.cElementTree, key), value) > > and then ignore it for the next decade or so. > > Programmatic deprecation is a significant imposition on third party > developers and should really be reserved for APIs that actively > encourage writing broken code (e.g. contextlib.nested) or are > seriously problematic for python-dev to maintain. For cleanup stuff, > documented deprecation is sufficient. > > Something that might be worth doing (although it would likely scare > the peanut gallery) is to create a PEP 4000 to record the various > cleanup tasks (like dropping cElementTree) that are being deliberately > excluded from the 3.x series. I honestly think a PEP 4000 is a good idea simply to document stuff that we are allowing to exist in Python 3 but don't think people should necessarily be using in order to follow best practices (e.g. this, ditching optparse, no more % string formatting, etc.). ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3
Le 14/02/2012 08:58, Stefan Behnel a écrit : > I'm -1 on emitting a deprecation warning just because cElementTree is being > replaced by a bare import. That's an implementation detail, just like > cElementTree should have been an implementation detail in the first place. > In all currently maintained CPython releases, importing cElementTree is the > right thing to do for users. +1! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyPy 1.8 released
On 10/02/2012 09:44, Maciej Fijalkowski wrote: you can download the PyPy 1.8 release here: http://pypy.org/download.html Why no Windows 64-bit build :'( Is the 32-bit build safe to use on 64-bit Windows? Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyPy 1.8 released
2012/2/14 Chris Withers > On 10/02/2012 09:44, Maciej Fijalkowski wrote: > >> you can download the PyPy 1.8 release here: >> >> http://pypy.org/download.html >> > > Why no Windows 64-bit build :'( > The win64 port was not finished. This platform is different from others mostly because a pointer (64bit) is larger than a long (32bit on all Windows flavors) Is the 32-bit build safe to use on 64-bit Windows? Yes, like many other 32-bit programs pypy for win32 works on Windows 64-bit. It will be limited to 3Gb of memory, of course. -- Amaury Forgeot d'Arc ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 410 (Decimal timestamp): the implementation is ready for a review
On Feb 13, 2012, at 07:33 PM, Victor Stinner wrote: >Oh, I forgot to mention my main concern about datetime: many functions >returning timestamp have an undefined starting point (an no timezone >information ), and so cannot be converted to datetime: > - time.clock(), time.wallclock(), time.monotonic(), >time.clock_gettime() (except for CLOCK_REALTIME) > - time.clock_getres() > - signal.get/setitimer() > - os.wait3(), os.wait4(), resource.getrusage() > - etc. That's not strictly true though, is it? E.g. clock_gettime() returns the number of seconds since the Epoch, which is a well-defined start time at least on *nix systems. So clearly those types of functions could return datetimes. I'm fairly certain that between those types of functions and timedeltas you could have most of the bases covered. -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 410 (Decimal timestamp): the implementation is ready for a review
2012/2/14 Barry Warsaw : > On Feb 13, 2012, at 07:33 PM, Victor Stinner wrote: > >>Oh, I forgot to mention my main concern about datetime: many functions >>returning timestamp have an undefined starting point (an no timezone >>information ), and so cannot be converted to datetime: >> - time.clock(), time.wallclock(), time.monotonic(), >>time.clock_gettime() (except for CLOCK_REALTIME) >> - time.clock_getres() >> - signal.get/setitimer() >> - os.wait3(), os.wait4(), resource.getrusage() >> - etc. > > That's not strictly true though, is it? E.g. clock_gettime() returns the > number of seconds since the Epoch, which is a well-defined start time at least > on *nix systems. I mentionned the exception: time.clock_gettime(CLOCK_REALTIME) returns an Epoch timestamp, but all other clocks supported by clock_gettime() has an unspecified starting point: - CLOCK_MONOTONIC - CLOCK_MONOTONIC_RAW - CLOCK_PROCESS_CPUTIME_ID - CLOCK_THREAD_CPUTIME_ID > So clearly those types of functions could return datetimes. What? What would be the starting point for all these functions? It would be surprising to get a datetime for CLOCK_PROCESS_CPUTIME_ID for example. > I'm fairly certain that between those types of functions and timedeltas you > could have most of the bases covered. Ah, timedelta case is different. But I already replied to Nick in this thread about timedelta. You can also ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 410 (Decimal timestamp): the implementation is ready for a review
(Oops, I sent my email by mistake, here is the end of my email) > (...) Ah, timedelta case is different. But I already replied to Nick in this > thread about timedelta. You can also see arguments against timedelta in the PEP 410. Victor ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 410 (Decimal timestamp): the implementation is ready for a review
I think I will just state my reasoning one last time and then leave it to the BDFL or BDFOP to make the final decision. Victor on IRC says that there is not much difference between Decimal and timedelta, and this may be true from an implementation point of view. From a cognitive point of view, I think they're miles apart. Ultimately, I wish ints and floats weren't used for time-y things, and only datetimes (for values with well-defined starting points, including the epoch) and timedeltas (for values with no starting point) were used. We obviously can't eliminate the APIs that return and accept ints and floats, most of which we inherited from C, but we can avoid making it worse by extended them to also accept Decimals. I think it would be valuable work to correct any deficiencies in datetimes and timedeltas so that they can be used in all time-y APIs, with whatever resolution is necessary. My primary concern with the PEP is adding to users confusion when they have to handle (at least) 5 different types[*] that represent time in Python. Cheers, -Barry [*] int, float, Decimal, datetime, timedelta; are there others? signature.asc Description: PGP signature ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 394 request for pronouncement (python2 symlink in *nix systems)
On Wed, Feb 15, 2012 at 12:44 AM, Barry Warsaw wrote: > On Feb 14, 2012, at 12:38 PM, Nick Coghlan wrote: > >>> One other thing I'd like to see the PEP address is a possible migration >>> strategy to python->python3. Even if that strategy is "don't do it, man!". >>> IOW, can a distribution change the 'python' symlink once it's pointed to >>> python2? What is the criteria for that? Is it up to a distribution? Will >>> the PEP get updated when our collective wisdom says its time to change the >>> default? etc. >> >>I have no idea, and I'm not going to open that can of worms for this >>PEP. We need to say something about the executable aliases so that >>people can eventually write cross-platform python2 shebang lines, but >>how particular distros actually manage the transition is going to >>depend more on their infrastructure and community than it is anything >>to do with us. > > Then I think all the PEP needs to say is that it is explicitly up to the > distros to determine if, when, where, and how they transition. I.e. take it > off of python-dev's plate. Yeah, good idea. I'll also add an explicit link to the announcement of the Arch Linux transition [1] that precipitated this PEP. [1] https://www.archlinux.org/news/python-is-now-python-3/ -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 410 (Decimal timestamp): the implementation is ready for a review
On Wed, Feb 15, 2012 at 8:29 AM, Barry Warsaw wrote: > My primary concern with the PEP is adding to users confusion when they have to > handle (at least) 5 different types[*] that represent time in Python. My key question to those advocating the use of timedelta instead of Decimal: What should timedelta.total_seconds() return to avoid losing nanosecond precision? How should this be requested when calling the API? The core "timestamp" abstraction is "just a number" that (in context) represents a certain number of seconds. decimal.Decimal qualifies. datetime.timedelta doesn't - it's a higher level construct that makes the semantic context explicit (and currently refuses to interoperate with other values that are just numbers). Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] How to round timestamps and durations?
On Mon, Feb 13, 2012 at 4:59 AM, Victor Stinner wrote: > Hi, > > My work on the PEP 410 tries to unify the code to manipulate > timestamps. The problem is that I'm unable to decide how to round > these numbers. > > Functions using a resolution of 1 second (e.g. time.mktime) expects > rounding towards zero (ROUND_HALF_DOWN), as does int(float). Example: > time.mktime(time.localtime(-1.9)), time.mktime(time.localtime(1.9)) > (-1.0, 1.0) Otherwise known as truncation and the same behavior as C when assigning a float to an int. > > datetime.datetime.fromtimestamp() rounds to nearest with ties going > away from zero (ROUND_HALF_UP). Example: > datetime.datetime.fromtimestamp(-1.1e-6), datetime.datetime.fromtimestamp(1.1e-6) > (datetime.datetime(1970, 1, 1, 0, 59, 59, 99), > datetime.datetime(1970, 1, 1, 1, 0, 0, 1)) datetime.datetime.fromtimestamp(-1.9e-6), datetime.datetime.fromtimestamp(1.9e-6) > (datetime.datetime(1970, 1, 1, 0, 59, 59, 98), > datetime.datetime(1970, 1, 1, 1, 0, 0, 2)) > > datetime.timedelta * float and datetime.timedelta / float rounds to > nearest with ties going to nearest even integer (ROUND_HALF_EVEN), as > does round(). Example: > [(datetime.timedelta(microseconds=x) / 2.0).microseconds for x in range(6)] > [0, 0, 1, 2, 2, 2] > > Should I also support multiple rounding methods depending on the > operation and of the Python function? Should we always use the same > rounding method? > > Antoine pointed me that ROUND_HALF_UP can produce timestamps "in the > future", which is especially visible when using a resolution of 1 > second. I like this rounding method because it limits the loss of > precision to an half unit: abs(rounded - timestamp) <= 0.5. But it can > be "surprising". I didn't know the other APIs ever rounded up so I find them a bit surprising. Realistically I expect any code out there that actually cares one way or another outside of the int(time.time()) case will care so I'd stick with that style of truncation (towards zero) rounding in all situations myself. -gps > The rounding method should maybe be the same than int(float) (so > ROUND_HALF_DOWN) to avoid surprising results for applications using > int(time.time()) for example (I had such problem with rotated logs and > test_logging). ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 410 (Decimal timestamp): the implementation is ready for a review
On Tue, Feb 14, 2012 at 2:29 PM, Barry Warsaw wrote: > I think I will just state my reasoning one last time and then leave it to the > BDFL or BDFOP to make the final decision. > > Victor on IRC says that there is not much difference between Decimal and > timedelta, and this may be true from an implementation point of view. >From a > cognitive point of view, I think they're miles apart. Ultimately, I wish ints > and floats weren't used for time-y things, and only datetimes (for values with > well-defined starting points, including the epoch) and timedeltas (for values > with no starting point) were used. > > We obviously can't eliminate the APIs that return and accept ints and floats, > most of which we inherited from C, but we can avoid making it worse by > extended them to also accept Decimals. I think it would be valuable work to > correct any deficiencies in datetimes and timedeltas so that they can be used > in all time-y APIs, with whatever resolution is necessary. > > My primary concern with the PEP is adding to users confusion when they have to > handle (at least) 5 different types[*] that represent time in Python. +1 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 410 (Decimal timestamp): the implementation is ready for a review
On Tue, Feb 14, 2012 at 4:23 PM, Nick Coghlan wrote: > On Wed, Feb 15, 2012 at 8:29 AM, Barry Warsaw wrote: >> My primary concern with the PEP is adding to users confusion when they have >> to >> handle (at least) 5 different types[*] that represent time in Python. > > My key question to those advocating the use of timedelta instead of Decimal: > > What should timedelta.total_seconds() return to avoid losing > nanosecond precision? > How should this be requested when calling the API? It should return a float as it does today. Add a timedelta.total_nanoseconds() call for people wanting high precision as a raw number and remind people of the precision limits of total_seconds() in the docs. -gps ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 410 (Decimal timestamp): the implementation is ready for a review
On Tue, Feb 14, 2012 at 5:13 PM, Gregory P. Smith wrote: > On Tue, Feb 14, 2012 at 4:23 PM, Nick Coghlan wrote: >> On Wed, Feb 15, 2012 at 8:29 AM, Barry Warsaw wrote: >>> My primary concern with the PEP is adding to users confusion when they have >>> to >>> handle (at least) 5 different types[*] that represent time in Python. >> >> My key question to those advocating the use of timedelta instead of Decimal: >> >> What should timedelta.total_seconds() return to avoid losing >> nanosecond precision? >> How should this be requested when calling the API? > > It should return a float as it does today. Add a > timedelta.total_nanoseconds() call for people wanting high precision > as a raw number and remind people of the precision limits of > total_seconds() in the docs. total_nanoseconds() would return an int() in case that wasn't obvious. > > -gps ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] How to round timestamps and durations?
Am 13.02.2012 13:59, schrieb Victor Stinner: > Hi, > > My work on the PEP 410 tries to unify the code to manipulate > timestamps. The problem is that I'm unable to decide how to round > these numbers. > > Functions using a resolution of 1 second (e.g. time.mktime) expects > rounding towards zero (ROUND_HALF_DOWN), as does int(float). Example: FWIW, that's ROUND_DOWN. ROUND_HALF_DOWN rounds up from > x.5. Georg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
