On 2 February 2012 03:47, Nick Coghlan ncogh...@gmail.com wrote:
Rather than being timestamp specific, such a protocol would be a
general numeric protocol. If (integer, numerator, denominator) is used
(i.e. a mixed number in mathematical terms), then __from_mixed__
would be an appropriate
On 01/02/2012 17:50, Guido van Rossum wrote:
Another question: a common pattern is to use (immutable) class
variables as default values for instance variables, and only set the
instance variables once they need to be different. Does such a class
benefit from your improvement?
A less common
I'd add datetime.timedelta to this list. It's exactly what timestamps
are, after all - the difference between the current time and the
relevant epoch value.
Ah yes, I forgot to mention it, whereas it is listed in the final
timestamp formats list :-)
* a) (sec, nsec): C timespec structure,
On 2 February 2012 12:16, Victor Stinner victor.stin...@haypocalc.com wrote:
Let's take an NTP timestamp in format (c): (sec=0,
floatpart=1, divisor=2**32):
Decimal(1) * Decimal(10)**-10
Decimal('0.01')
Decimal(1) / Decimal(2)**32
On Thu, Feb 2, 2012 at 10:16 PM, Victor Stinner
victor.stin...@haypocalc.com wrote:
If we only support int, float and Decimal, we don't need to add a new
protocol, hardcoded functions are enough :-)
Yup, that's why your middle-ground approach didn't make any sense to
me. Returning Decimal when
Even if I like the idea, I don't think that we need all this machinery
to support nanosecond resolution. I should maybe forget my idea of
using datetime.datetime or datetime.timedelta, or only only support
int, float and decimal.Decimal.
I updated my patch (issue #13882) to only support int,
On Thu, Feb 2, 2012 at 10:45 PM, Paul Moore p.f.mo...@gmail.com wrote:
On 2 February 2012 12:16, Victor Stinner victor.stin...@haypocalc.com wrote:
Let's take an NTP timestamp in format (c): (sec=0,
floatpart=1, divisor=2**32):
Decimal(1) * Decimal(10)**-10
On Thu, Feb 2, 2012 at 11:10 PM, Victor Stinner
victor.stin...@haypocalc.com wrote:
Even if I like the idea, I don't think that we need all this machinery
to support nanosecond resolution. I should maybe forget my idea of
using datetime.datetime or datetime.timedelta, or only only support
int,
On Thu, 2 Feb 2012 23:07:28 +1000
Nick Coghlan ncogh...@gmail.com wrote:
We can't add new fields to the stat tuple anyway - it breaks tuple
unpacking.
I don't think that's true. The stat tuple already has a varying number
of fields: http://docs.python.org/dev/library/os.html#os.stat
“For
On Thu, 2 Feb 2012 14:10:14 +0100
Victor Stinner victor.stin...@haypocalc.com wrote:
Even if I like the idea, I don't think that we need all this machinery
to support nanosecond resolution. I should maybe forget my idea of
using datetime.datetime or datetime.timedelta, or only only support
Nick Coghlan wrote:
On Thu, Feb 2, 2012 at 10:16 PM, Victor Stinner
Add an argument to change the result type
-
There should also be a description of the set a boolean flag to
request high precision output approach.
You mean something like:
On Thu, Feb 2, 2012 at 11:31 PM, M.-A. Lemburg m...@egenix.com wrote:
Isn't the above (having the return type depend on an argument
setting) something we generally try to avoid ?
In Victor's actual patch, the returned object is an instance of the
type you pass in, so it actually avoids that
Why int? That doesn't seem to bring anything.
It helps to deprecate/replace os.stat_float_times(), which may be used
for backward compatibility (with Python 2.2 ? :-)).
___
Python-Dev mailing list
Python-Dev@python.org
On Thu, 2 Feb 2012 15:09:41 +0100
Victor Stinner victor.stin...@haypocalc.com wrote:
Why int? That doesn't seem to bring anything.
It helps to deprecate/replace os.stat_float_times(), which may be used
for backward compatibility (with Python 2.2 ? :-)).
I must admit I don't understand the
That said, I don't understand why we couldn't simply deprecate
stat_float_times() right now. Having an option for integer timestamps
is pointless, you can just call int() on the result if you want.
So which API do you propose for time.time() to get a Decimal object?
On Feb 02, 2012, at 11:07 PM, Nick Coghlan wrote:
Yup, that's why your middle-ground approach didn't make any sense to
me. Returning Decimal when a flag is set to request high precision
values actually handles everything (since any epoch related questions
only arise later when converting the
On 02/02/2012 11:30, Chris Withers wrote:
On 01/02/2012 17:50, Guido van Rossum wrote:
Another question: a common pattern is to use (immutable) class
variables as default values for instance variables, and only set the
instance variables once they need to be different. Does such a class
benefit
On Wed, 1 Feb 2012 09:50:55 -0800
Guido van Rossum gu...@python.org wrote:
On Wed, Feb 1, 2012 at 9:13 AM, Hans Mulder han...@xs4all.nl wrote:
On 30/01/12 00:30:14, Steven D'Aprano wrote:
Mark Shannon wrote:
Antoine Pitrou wrote:
[..]
Antoine is right. It is a reorganisation
Am 02.02.2012 12:30, schrieb Chris Withers:
On 01/02/2012 17:50, Guido van Rossum wrote:
Another question: a common pattern is to use (immutable) class
variables as default values for instance variables, and only set the
instance variables once they need to be different. Does such a class
Just a quick update.
I've been analysing and profile the behaviour of my new dict and messing
about with various implementation options.
I've settled on a new implementation.
Its the same basic idea, but with better locality of reference for
unshared keys.
Guido asked:
Another question:
On Feb 3, 2012 2:59 AM, Barry Warsaw ba...@python.org wrote:
On Feb 02, 2012, at 11:07 PM, Nick Coghlan wrote:
Yup, that's why your middle-ground approach didn't make any sense to
me. Returning Decimal when a flag is set to request high precision
values actually handles everything (since any
On Wed, Feb 1, 2012 at 5:03 PM, Victor Stinner
victor.stin...@haypocalc.com wrote:
datetime.datetime
-
datetime.datetime only supports microsecond resolution, but can be enhanced
to support nanosecond.
datetime.datetime has issues:
- there is no easy way to convert it into
On Wed, Feb 1, 2012 at 20:08, stefan brunthaler s.bruntha...@uci.edu wrote:
I understand all of these issues. Currently, it's not really a mess,
but much more complicated as it needs to be for only supporting the
inca optimization.
I really don't think that is a problem. The core contributors
PEP: 409
Title: Suppressing exception context
Version: $Revision$
Last-Modified: $Date$
Author: Ethan Furman et...@stoneleaf.us
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 26-Jan-2012
Post-History: 30-Aug-2002, 01-Feb-2012, 03-Feb-2012
Abstract
One of the
On 2/2/2012 2:10 PM, Ethan Furman wrote:
* Use /Ellipsis/ as the default value (the /.../ singleton).
Accepted. There are no other possible values; it cannot be raised as
it is not an acception; it has the connotation of 'fill in the
rest...' as in /__cause__/ is not set, look in
On 2/2/2012 6:28 AM, Antoine Pitrou wrote:
On Thu, 2 Feb 2012 15:09:41 +0100
Victor Stinnervictor.stin...@haypocalc.com wrote:
Why int? That doesn't seem to bring anything.
It helps to deprecate/replace os.stat_float_times(), which may be used
for backward compatibility (with Python 2.2 ?
Great, PEP 409 is accepted with Ellipsis instead of False!
On Thu, Feb 2, 2012 at 2:40 PM, Glenn Linderman v+pyt...@g.nevcal.com wrote:
On 2/2/2012 2:10 PM, Ethan Furman wrote:
* Use /Ellipsis/ as the default value (the /.../ singleton).
Accepted. There are no other possible values; it
In my opinion using Ellipsis is just wrong. It is completely
non-obvious not only to a beginner, but even to an experienced
python developer. Writing 'raise Something() from None'
looks less suspicious, but still strange.
Isn't 'raise Exception().no_context()' or
'raise
I was looking at the other Open Issues on PEP 3134, think I might try to
resolve them as well, and discovered via testing that they have already
been taken care of.
Is there an established way to get information like that?
I realize that PEPs are partly historical documents, but it would it
On Fri, Feb 3, 2012 at 8:37 AM, Glenn Linderman v+pyt...@g.nevcal.com wrote:
Sorry to bring this up, but the PEP should probably consider another option:
Introducing a precedent following os.stat_decimal_times(). Like
os.stat_float_times, it would decide the return types of timestamps from
On Fri, Feb 3, 2012 at 9:32 AM, Yury Selivanov yselivanov...@gmail.com wrote:
In my opinion using Ellipsis is just wrong. It is completely
non-obvious not only to a beginner, but even to an experienced
python developer. Writing 'raise Something() from None'
looks less suspicious, but still
On Fri, Feb 3, 2012 at 9:16 AM, Ethan Furman et...@stoneleaf.us wrote:
I was looking at the other Open Issues on PEP 3134, think I might try to
resolve them as well, and discovered via testing that they have already been
taken care of.
Is there an established way to get information like that?
Glenn Linderman wrote:
On 2/2/2012 2:10 PM, Ethan Furman wrote:
* Use /Ellipsis/ as the default value (the /.../ singleton).
Accepted. There are no other possible values; it cannot be raised as
it is not an acception; it has the connotation of 'fill in the
rest...' as in /__cause__/
On Thu, Feb 2, 2012 at 3:41 PM, Nick Coghlan ncogh...@gmail.com wrote:
On Fri, Feb 3, 2012 at 9:32 AM, Yury Selivanov yselivanov...@gmail.com
wrote:
In my opinion using Ellipsis is just wrong. It is completely
non-obvious not only to a beginner, but even to an experienced
python developer.
I updated and completed my PEP and published the last draft. It will
be available at:
http://www.python.org/dev/peps/pep-0410/
( or read the source: http://hg.python.org/peps/file/tip/pep-0410.txt )
I tried to list all alternatives.
Victor
___
On Fri, Feb 3, 2012 at 10:04 AM, Guido van Rossum gu...@python.org wrote:
On Thu, Feb 2, 2012 at 3:41 PM, Nick Coghlan ncogh...@gmail.com wrote:
On Fri, Feb 3, 2012 at 9:32 AM, Yury Selivanov yselivanov...@gmail.com
wrote:
In my opinion using Ellipsis is just wrong. It is completely
Nick Coghlan wrote:
On Fri, Feb 3, 2012 at 9:16 AM, Ethan Furman et...@stoneleaf.us wrote:
I was looking at the other Open Issues on PEP 3134, think I might try to
resolve them as well, and discovered via testing that they have already been
taken care of.
Is there an established way to get
Guido van Rossum wrote:
Great, PEP 409 is accepted with Ellipsis instead of False!
Awesome. :)
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
On Fri, Feb 3, 2012 at 10:21 AM, Victor Stinner
victor.stin...@haypocalc.com wrote:
I updated and completed my PEP and published the last draft. It will
be available at:
http://www.python.org/dev/peps/pep-0410/
( or read the source: http://hg.python.org/peps/file/tip/pep-0410.txt )
I tried
On 2/2/2012 3:38 PM, Nick Coghlan wrote:
On Fri, Feb 3, 2012 at 8:37 AM, Glenn Lindermanv+pyt...@g.nevcal.com wrote:
Sorry to bring this up, but the PEP should probably consider another option:
Introducing a precedent following os.stat_decimal_times(). Like
os.stat_float_times, it would
On Thu, 2 Feb 2012 16:25:25 +0100
Victor Stinner victor.stin...@haypocalc.com wrote:
That said, I don't understand why we couldn't simply deprecate
stat_float_times() right now. Having an option for integer timestamps
is pointless, you can just call int() on the result if you want.
So
On Thu, Feb 2, 2012 at 4:34 PM, Nick Coghlan ncogh...@gmail.com wrote:
On Fri, Feb 3, 2012 at 10:04 AM, Guido van Rossum gu...@python.org wrote:
On Thu, Feb 2, 2012 at 3:41 PM, Nick Coghlan ncogh...@gmail.com wrote:
On Fri, Feb 3, 2012 at 9:32 AM, Yury Selivanov yselivanov...@gmail.com
wrote:
On Fri, Feb 3, 2012 at 12:42 PM, Ethan Furman et...@stoneleaf.us wrote:
Nick Coghlan wrote:
FWIW, I expect the implementation will *allow* raise exc from
Ellipsis as an odd synonym for raise exc.
Are we sure we want that? Raising from something not an exception seems
counter-intuitive
On Thu, Feb 2, 2012 at 6:49 PM, Nick Coghlan ncogh...@gmail.com wrote:
On Fri, Feb 3, 2012 at 12:42 PM, Ethan Furman et...@stoneleaf.us wrote:
Nick Coghlan wrote:
FWIW, I expect the implementation will *allow* raise exc from
Ellipsis as an odd synonym for raise exc.
Are we sure we want
Guido van Rossum wrote:
On Thu, Feb 2, 2012 at 6:49 PM, Nick Coghlan ncogh...@gmail.com wrote:
On Fri, Feb 3, 2012 at 12:42 PM, Ethan Furman et...@stoneleaf.us wrote:
Nick Coghlan wrote:
FWIW, I expect the implementation will *allow* raise exc from
Ellipsis as an odd synonym for raise exc.
On 3 February 2012 13:54, Guido van Rossum gu...@python.org wrote:
On Thu, Feb 2, 2012 at 6:49 PM, Nick Coghlan ncogh...@gmail.com wrote:
On Fri, Feb 3, 2012 at 12:42 PM, Ethan Furman et...@stoneleaf.us
wrote:
Nick Coghlan wrote:
FWIW, I expect the implementation will *allow* raise exc
Nick Coghlan wrote:
FWIW, I expect the implementation will *allow* raise exc from
Ellipsis as an odd synonym for raise exc.
Are we sure we want that? Raising from something not an exception seems
counter-intuitive (None being the obvious exception).
I'd want to allow
exc.__cause__ =
On Fri, Feb 3, 2012 at 1:34 PM, Tim Delaney timothy.c.dela...@gmail.com wrote:
? I kinda like the second - it feels more self-descriptive to me than from
Ellipsis - but there's the counter-argument that it could look like noise,
and I think would require a grammar change to allow it there.
Tim Delaney wrote:
In that case, would the best syntax be:
raise Exception() from Ellipsis
or:
raise Exception() from ...
? I kinda like the second - it feels more self-descriptive to me than
from Ellipsis - but there's the counter-argument that it could look
like noise, and I
On 3 February 2012 15:02, Nick Coghlan ncogh...@gmail.com wrote:
Both will be allowed - in 3.x, '...' is just an ordinary expression
that means exactly the same thing as the builtin Ellipsis:
Ellipsis
Ellipsis
...
Ellipsis
I'd totally forgotten that was the case in 3.x ... it's still
I really don't think that is a problem. The core contributors can deal
well with complexity in my experience. :-)
No no, I wasn't trying to insinuate anything like that at all. No, I
just figured that having the code generator being able to generate 4
optimizations where only one is supported
51 matches
Mail list logo
