> 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
On 3 February 2012 15:02, Nick Coghlan 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 not ex
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 thi
On Fri, Feb 3, 2012 at 1:34 PM, Tim Delaney 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.
Both will be allowed - in
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 3 February 2012 13:54, Guido van Rossum wrote:
> On Thu, Feb 2, 2012 at 6:49 PM, Nick Coghlan wrote:
> > On Fri, Feb 3, 2012 at 12:42 PM, Ethan Furman
> wrote:
> >> Nick Coghlan wrote:
> >>>
> >>> FWIW, I expect the implementation will *allow* "raise exc from
> >>> Ellipsis" as an odd synony
Guido van Rossum wrote:
On Thu, Feb 2, 2012 at 6:49 PM, Nick Coghlan wrote:
On Fri, Feb 3, 2012 at 12:42 PM, Ethan Furman 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? Raisin
On Thu, Feb 2, 2012 at 6:49 PM, Nick Coghlan wrote:
> On Fri, Feb 3, 2012 at 12:42 PM, Ethan Furman 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 fro
On Fri, Feb 3, 2012 at 12:42 PM, Ethan Furman 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 (None b
On Thu, Feb 2, 2012 at 4:34 PM, Nick Coghlan wrote:
> On Fri, Feb 3, 2012 at 10:04 AM, Guido van Rossum wrote:
>> On Thu, Feb 2, 2012 at 3:41 PM, Nick Coghlan wrote:
>>> On Fri, Feb 3, 2012 at 9:32 AM, Yury Selivanov
>>> wrote:
In my opinion using Ellipsis is just wrong. It is completely
On Thu, 2 Feb 2012 16:25:25 +0100
Victor Stinner 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 which API do you propose
On 2/2/2012 3:38 PM, Nick Coghlan wrote:
On Fri, Feb 3, 2012 at 8:37 AM, Glenn Linderman 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
On Fri, Feb 3, 2012 at 10:21 AM, Victor Stinner
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 to list all alternatives
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:
http://mail.python.org/mailman/
Nick Coghlan wrote:
On Fri, Feb 3, 2012 at 9:16 AM, Ethan Furman 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?
On Fri, Feb 3, 2012 at 10:04 AM, Guido van Rossum wrote:
> On Thu, Feb 2, 2012 at 3:41 PM, Nick Coghlan wrote:
>> On Fri, Feb 3, 2012 at 9:32 AM, Yury Selivanov
>> wrote:
>>> In my opinion using Ellipsis is just wrong. It is completely
>>> non-obvious not only to a beginner, but even to an exp
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
___
Python-De
On Thu, Feb 2, 2012 at 3:41 PM, Nick Coghlan wrote:
> On Fri, Feb 3, 2012 at 9:32 AM, Yury Selivanov
> 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 N
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__/ i
On Fri, Feb 3, 2012 at 9:16 AM, Ethan Furman 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?
>
> I realize
On Fri, Feb 3, 2012 at 9:32 AM, Yury Selivanov 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 strange.
Beginners w
On Fri, Feb 3, 2012 at 8:37 AM, Glenn Linderman 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
> os.stat. Or somethi
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
m
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 Exception().no_cause(
Great, PEP 409 is accepted with Ellipsis instead of False!
On Thu, Feb 2, 2012 at 2:40 PM, 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
On 2/2/2012 6:28 AM, Antoine Pitrou wrote:
On Thu, 2 Feb 2012 15:09:41 +0100
Victor Stinner 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 und
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 /__cont
PEP: 409
Title: Suppressing exception context
Version: $Revision$
Last-Modified: $Date$
Author: Ethan Furman
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 open issues from PEP 3
On Wed, Feb 1, 2012 at 20:08, stefan brunthaler 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 can deal
well with
On Wed, Feb 1, 2012 at 5:03 PM, Victor Stinner
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 "seconds since the
On Feb 3, 2012 2:59 AM, "Barry Warsaw" 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 epoch
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:
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 clas
On Wed, 1 Feb 2012 09:50:55 -0800
Guido van Rossum wrote:
> On Wed, Feb 1, 2012 at 9:13 AM, Hans Mulder 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 of th
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 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 d
> 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?
time.time(timestamp=deci
On Thu, 2 Feb 2012 15:09:41 +0100
Victor Stinner 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 stat_float_times documen
> 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
http://mail.python.org/mailman/li
On Thu, Feb 2, 2012 at 11:31 PM, M.-A. Lemburg 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 issue.
> I think
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 so
On Thu, 2 Feb 2012 14:10:14 +0100
Victor Stinner 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, float and decim
On Thu, 2 Feb 2012 23:07:28 +1000
Nick Coghlan 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 backward compatibil
On Thu, Feb 2, 2012 at 11:10 PM, Victor Stinner
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, float and decimal.De
On Thu, Feb 2, 2012 at 10:45 PM, Paul Moore wrote:
> On 2 February 2012 12:16, Victor Stinner 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) / D
> 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 in
On Thu, Feb 2, 2012 at 10:16 PM, Victor Stinner
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 a flag is set to request hi
On 2 February 2012 12:16, Victor Stinner 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
> Decimal('0.023283064365386962890625')
>
> Yo
> 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 struct
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 patt
On 2 February 2012 03:47, Nick Coghlan 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 name. If (integ
51 matches
Mail list logo
