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
>
On Jan 31, 2012 11:08 PM, "Nick Coghlan" 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, you don't have
t
On Wed, Feb 1, 2012 at 9:40 PM, Victor Stinner
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 divisor cannot be writt
> 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 f
On Wed, Feb 1, 2012 at 9:08 PM, Antoine Pitrou 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 everywhere, tho
On Wed, 1 Feb 2012 14:08:34 +1000
Nick Coghlan wrote:
> On Wed, Feb 1, 2012 at 12:35 PM, Antoine Pitrou 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'
On Wed, Feb 1, 2012 at 6:03 PM, Victor Stinner
wrote:
> 2012/2/1 Nick Coghlan :
>> 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)
2012/2/1 Nick Coghlan :
> 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) + Decimal(fraction) * Decim
On Wed, Feb 1, 2012 at 12:35 PM, Antoine Pitrou 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 current time is
Analysis paralysis commence. +1 for separate module using decimal.
On Feb 1, 2012 1:44 PM, "PJ Eby" wrote:
> On Tue, Jan 31, 2012 at 7:35 PM, Nick Coghlan wrote:
>
>> Such a protocol can easily be extended to any other type - the time
>> module could provide conversion functions for integers and
On Tue, Jan 31, 2012 at 7:35 PM, Nick Coghlan 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), while the existing
On Wed, 1 Feb 2012 10:35:08 +1000
Nick Coghlan 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 Wed, Feb 1, 2012 at 8:58 AM, Mark Shannon 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 be nanotime
Alexander Belopolsky wrote:
On Tue, Jan 31, 2012 at 7:13 AM, Antoine Pitrou wrote:
On Tue, 31 Jan 2012 21:11:37 +1000
Nick Coghlan 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
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
> (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
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 ke
On Tue, Jan 31, 2012 at 7:13 AM, Antoine Pitrou wrote:
> On Tue, 31 Jan 2012 21:11:37 +1000
> Nick Coghlan 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 o
On Mon, Jan 30, 2012 at 6:31 PM, Victor Stinner
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 exposing high
resolution clocks i
> - 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
On Tue, 31 Jan 2012 21:11:37 +1000
Nick Coghlan 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 (it's a number),
Hi,
2012/1/31 Matt Joiner :
> 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 way you don't ne
On Tue, Jan 31, 2012 at 7:42 PM, Victor Stinner
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 benefits, but I can pro
> 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 9:31 AM, Victor Stinner
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 with a
> resolution of 1
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
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
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 wh
28 matches
Mail list logo