In http://mail.python.org/pipermail/python-dev/2012-February/116073.html
Nick Coghlan wrote:
Besides, float128 is a bad example - such a type could just be
returned directly where we return float64 now. (The only reason we
can't do that with Decimal is because we deliberately don't allow
2012/2/1 Nick Coghlan ncogh...@gmail.com:
The secret to future-proofing such an API while only using integers
lies in making the decimal exponent part of the conversion function
signature:
def from_components(integer, fraction=0, exponent=-9):
return Decimal(integer) +
On Wed, Feb 1, 2012 at 6:03 PM, Victor Stinner
victor.stin...@haypocalc.com wrote:
2012/2/1 Nick Coghlan ncogh...@gmail.com:
The secret to future-proofing such an API while only using integers
lies in making the decimal exponent part of the conversion function
signature:
def
On Wed, 1 Feb 2012 14:08:34 +1000
Nick Coghlan ncogh...@gmail.com wrote:
On Wed, Feb 1, 2012 at 12:35 PM, Antoine Pitrou solip...@pitrou.net wrote:
It strikes me as inelegant to have to do so much typing for something
as simple as getting the current time. We should approach the
simplicity
On Wed, Feb 1, 2012 at 9:08 PM, Antoine Pitrou solip...@pitrou.net wrote:
Right, but that's not even a plausible request. Nobody wants to write a
separate time module just to have a different return type.
I can definitely see someone doing import hirestime as time to avoid
having to pass a flag
If a callback protocol is used at all, there's no reason those details
need to be exposed to the callbacks. Just choose an appropriate
exponent based on the precision of the underlying API call.
If the clock divisor cannot be written as a power of 10, you loose
precision, just because your
On Wed, Feb 1, 2012 at 9:40 PM, Victor Stinner
victor.stin...@haypocalc.com wrote:
If a callback protocol is used at all, there's no reason those details
need to be exposed to the callbacks. Just choose an appropriate
exponent based on the precision of the underlying API call.
If the clock
On Jan 31, 2012 11:08 PM, Nick Coghlan ncogh...@gmail.com wrote:
PJE is quite right that using a new named protocol rather than a
callback with a particular signature could also work, but I don't see
a lot of advantages in doing so.
The advantage is that it fits your brain better. That is,
I think this is definitely worth elaborating in a PEP (to recap the
long discussion in #11457 if nothing else).
The discussion in issues #13882 and #11457 already lists many
alternatives with their costs and benefits, but I can produce a PEP if
you need a summary.
In particular, I'd want to
On Tue, Jan 31, 2012 at 7:42 PM, Victor Stinner
victor.stin...@haypocalc.com wrote:
I think this is definitely worth elaborating in a PEP (to recap the
long discussion in #11457 if nothing else).
The discussion in issues #13882 and #11457 already lists many
alternatives with their costs and
Hi,
2012/1/31 Matt Joiner anacro...@gmail.com:
Sounds good, but I also prefer Alexander's method. The type information is
already encoded in the class object.
Ok, I posted a patch version 6 to use types instead of strings. I also
prefer types because it solves the hidden import issue.
This
On Tue, 31 Jan 2012 21:11:37 +1000
Nick Coghlan ncogh...@gmail.com wrote:
Having a low-level module like os needing to know about higher-level
types like decimal.Decimal and datetime.datetime (or even timedelta)
should be setting off all kinds of warning bells.
Decimal is ideally low-level
- use datetime (bad idea for the reasons Martin mentioned)
It is only a bad idea if it is the only available choice.
- use timedelta (not mentioned on the tracker, but a *much* better fit
for a timestamp than datetime, since timestamps are relative to the
epoch while datetime objects try to
On Mon, Jan 30, 2012 at 6:31 PM, Victor Stinner
victor.stin...@haypocalc.com wrote:
Alexander Belopolsky proposed to use
time.time(format=datetime.datetime) instead.
Just to make sure my view is fully expressed: I am against adding flag
arguments to time.time(). My preferred solution to
On Tue, Jan 31, 2012 at 7:13 AM, Antoine Pitrou solip...@pitrou.net wrote:
On Tue, 31 Jan 2012 21:11:37 +1000
Nick Coghlan ncogh...@gmail.com wrote:
Having a low-level module like os needing to know about higher-level
types like decimal.Decimal and datetime.datetime (or even timedelta)
Am 31.01.2012 13:08, schrieb Victor Stinner:
This way you don't need to maintain a
mapping of strings to classes, and other functions/third party can join in
the fun without needing access to the latest canonical mapping. Lastly there
will be no confusion or contention for duplicate keys.
(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
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
Alexander Belopolsky wrote:
On Tue, Jan 31, 2012 at 7:13 AM, Antoine Pitrou solip...@pitrou.net wrote:
On Tue, 31 Jan 2012 21:11:37 +1000
Nick Coghlan ncogh...@gmail.com wrote:
Having a low-level module like os needing to know about higher-level
types like decimal.Decimal and datetime.datetime
On Wed, Feb 1, 2012 at 8:58 AM, Mark Shannon m...@hotpy.org wrote:
Why not add a new function rather than modifying time.time()?
(after all its just a timestamp, does it really need nanosecond precision?)
For those who do want super-accuracy then add a new function
time.picotime() (it could
On Wed, 1 Feb 2012 10:35:08 +1000
Nick Coghlan ncogh...@gmail.com wrote:
With this approach, API usage might end up looking something like:
time.time()
1328006975.681211
time.time(convert=time.as_float)
1328006975.681211
time.time(convert=time.as_int)
1328006979
On Tue, Jan 31, 2012 at 7:35 PM, Nick Coghlan ncogh...@gmail.com wrote:
Such a protocol can easily be extended to any other type - the time
module could provide conversion functions for integers and float
objects (meaning results may have lower precision than the underlying
system calls),
Analysis paralysis commence. +1 for separate module using decimal.
On Feb 1, 2012 1:44 PM, PJ Eby p...@telecommunity.com wrote:
On Tue, Jan 31, 2012 at 7:35 PM, Nick Coghlan ncogh...@gmail.com wrote:
Such a protocol can easily be extended to any other type - the time
module could provide
On Wed, Feb 1, 2012 at 12:35 PM, Antoine Pitrou solip...@pitrou.net wrote:
It strikes me as inelegant to have to do so much typing for something
as simple as getting the current time. We should approach the
simplicity of ``time.time(format='decimal')`` or
``time.decimal_time()``.
Getting the
Hi,
In issues #13882 and #11457, I propose to add an argument to functions
returning timestamps to choose the timestamp format. Python uses float
in most cases whereas float is not enough to store a timestamp with a
resolution of 1 nanosecond. I added recently time.clock_gettime() to
Python 3.3
Sounds good, but I also prefer Alexander's method. The type information is
already encoded in the class object. This way you don't need to maintain a
mapping of strings to classes, and other functions/third party can join in
the fun without needing access to the latest canonical mapping. Lastly
Am 31.01.2012 00:50, schrieb Matt Joiner:
Sounds good, but I also prefer Alexander's method. The type information is
already encoded in the class object. This way you don't need to maintain a
mapping of strings to classes, and other functions/third party can join in the
fun without needing
On Tue, Jan 31, 2012 at 9:31 AM, Victor Stinner
victor.stin...@haypocalc.com wrote:
Hi,
In issues #13882 and #11457, I propose to add an argument to functions
returning timestamps to choose the timestamp format. Python uses float
in most cases whereas float is not enough to store a timestamp
28 matches
Mail list logo
