On 2/27/2014 7:46 PM, Chris Angelico wrote:
On Fri, Feb 28, 2014 at 1:12 PM, Glenn Linderman wrote:
Yes. But the point is really the location of the (), sorry if my "nice
extension" comment is throwing you off that track.
Ah! I see.
We touched on this syntax on -ideas, but at the time, the p
Skip Montanaro writes:
> On Thu, Feb 27, 2014 at 1:23 PM, Antoine Pitrou wrote:
> > Well, if we must maintain macros, let's maintain them everywhere and
> > avoid the burden of two different implementations for the same thing.
>
> Would it be possible to generate the macro versions from the
On Fri, Feb 28, 2014 at 1:12 PM, Glenn Linderman wrote:
> Yes. But the point is really the location of the (), sorry if my "nice
> extension" comment is throwing you off that track.
Ah! I see.
We touched on this syntax on -ideas, but at the time, the proposed
syntax didn't have parens around th
On 2/27/2014 3:40 PM, Chris Angelico wrote:
On Fri, Feb 28, 2014 at 10:33 AM, Nick Coghlan wrote:
On 28 Feb 2014 05:56, "Chris Angelico" wrote:
On Fri, Feb 28, 2014 at 6:36 AM, Glenn Linderman
wrote:
+1
f() except ((TypeError, AttributeError): "No value")
is a nice extension to the i
On Fri, Feb 28, 2014 at 10:33 AM, Nick Coghlan wrote:
>
> On 28 Feb 2014 05:56, "Chris Angelico" wrote:
>>
>> On Fri, Feb 28, 2014 at 6:36 AM, Glenn Linderman
>> wrote:
>> > +1
>> >
>> > f() except ((TypeError, AttributeError): "No value")
>> >
>> > is a nice extension to the idea of
>> >
>>
On 28 Feb 2014 05:56, "Chris Angelico" wrote:
>
> On Fri, Feb 28, 2014 at 6:36 AM, Glenn Linderman
wrote:
> > +1
> >
> > f() except ((TypeError, AttributeError): "No value")
> >
> > is a nice extension to the idea of
> >
> > value = expr except (
> > Exception1: default1,
> >
On Fri, Feb 28, 2014 at 8:29 AM, Chris Angelico wrote:
> @@ -43,6 +43,34 @@
>
> * statistics.mean(data) - no way to handle an empty iterator
>
> +Had this facility existed early in Python's history, there would have been
> +no need to create dict.get() and related methods; the one obvious way to
I've added another utility script to my PEP draft repo:
https://github.com/Rosuav/ExceptExpr/blob/master/replace_except_expr.py
It's built out of some pretty horrendous hacks, it makes some
assumptions about code layout (eg spaces for indentation, and a
try/except block never has anything else on
On Fri, Feb 28, 2014 at 6:36 AM, Glenn Linderman wrote:
> +1
>
> f() except ((TypeError, AttributeError): "No value")
>
> is a nice extension to the idea of
>
> value = expr except (
> Exception1: default1,
> Exception2: default2,
> Exception3: default3,
>)
>
>
On Thu, 27 Feb 2014 13:27:02 -0600
Skip Montanaro wrote:
> On Thu, Feb 27, 2014 at 1:23 PM, Antoine Pitrou wrote:
> > Well, if we must maintain macros, let's maintain them everywhere and
> > avoid the burden of two different implementations for the same thing.
>
> Would it be possible to generat
On 2/27/2014 4:57 AM, Nick Coghlan wrote:
The way I get the colon in the proposed syntax to make sense to my
brain is to view it as being more like the colon in a dictionary
key:value pair than it is like the one that introduces a suite or the
body of a lambda expression:
(lst[2] except {In
On Thu, Feb 27, 2014 at 1:23 PM, Antoine Pitrou wrote:
> Well, if we must maintain macros, let's maintain them everywhere and
> avoid the burden of two different implementations for the same thing.
Would it be possible to generate the macro versions from the
inline/static versions where necessary
On Thu, 27 Feb 2014 13:12:24 -0600
Skip Montanaro wrote:
> I think it's at least worthwhile to investigate the use of
> inline/static functions over the current macros. It's been many years
> since I looked at them. I doubt they have gotten any easier to read or
> edit with all their backslashes.
I think it's at least worthwhile to investigate the use of
inline/static functions over the current macros. It's been many years
since I looked at them. I doubt they have gotten any easier to read or
edit with all their backslashes.
I do have one question though. Suppose you encounter a compiler t
On Thu, 27 Feb 2014 17:22:37 + (UTC)
Sturla Molden wrote:
> Brett Cannon wrote:
>
> > The Visual Studio team has publicly stated they will never support C99,
> > so dropping C89 blindly is going to alienate a big part of our user base
> > unless we switch to C++ instead. I'm fine with trying
On 27/02/14 13:06, Kristján Valur Jónsson wrote:
-Original Message-
From: Victor Stinner [mailto:victor.stin...@gmail.com]
Sent: 27. febrúar 2014 10:47
To: Kristján Valur Jónsson
Cc: Python-Dev (python-dev@python.org)
Subject: Re: [Python-Dev] Start writing inlines rather than macros
On Thu, Feb 27, 2014 at 12:22 PM, Sturla Molden wrote:
> Brett Cannon wrote:
>
> > The Visual Studio team has publicly stated they will never support C99,
> > so dropping C89 blindly is going to alienate a big part of our user base
> > unless we switch to C++ instead. I'm fine with trying to pull
Brett Cannon wrote:
> The Visual Studio team has publicly stated they will never support C99,
> so dropping C89 blindly is going to alienate a big part of our user base
> unless we switch to C++ instead. I'm fine with trying to pull in C99
> features, though, that we can somehow support in a back
On Thu, Feb 27, 2014 at 5:47 AM, Victor Stinner wrote:
> Hi,
>
> 2014-02-27 11:22 GMT+01:00 Kristján Valur Jónsson :
> > Now, Larry Hastings pointed out that we support C89 which doesn’t support
> > Inlines. Rather than suggesting here that we update that compatibility
> > requirement,
>
> In pra
I agree with NICK. having REF in it is a good idea.
So, I'm +1 on setref.
Having long explicit macros with exact semantics in the name is a bad one.
so I'm -1 on any Py_DECREF_AND_REPLACE or similar daschhunds.
Also, is there any real requirement for having separate non-X versions of these?
The X
> -Original Message-
> From: Victor Stinner [mailto:victor.stin...@gmail.com]
> Sent: 27. febrúar 2014 10:47
> To: Kristján Valur Jónsson
> Cc: Python-Dev (python-dev@python.org)
> Subject: Re: [Python-Dev] Start writing inlines rather than macros?
> In practice, recent versions of GCC an
On 27 February 2014 20:44, Ronald Oussoren wrote:
>
> On 27 Feb 2014, at 11:09, Chris Angelico wrote:
>
>> On Thu, Feb 27, 2014 at 7:44 PM, Ronald Oussoren
>> wrote:
>>> What about (also mentioned in the PEP)?
>>>
>>> value = (expr except Exception try default)
>>>
>>> This seems to read nicel
On Thu, Feb 27, 2014 at 9:44 PM, Ronald Oussoren wrote:
>> expr except Exception try default # "try" indicates the initial expr,
>> not the default
>
> I didn’t parse the expression this way at all, but quite naturally parsed is
> as “use expr, and try using default if expr raises Exception” and
Hi,
2014-02-27 11:22 GMT+01:00 Kristján Valur Jónsson :
> Now, Larry Hastings pointed out that we support C89 which doesn’t support
> Inlines. Rather than suggesting here that we update that compatibility
> requirement,
In practice, recent versions of GCC and Clang are used. On Windows,
it's Vis
On 27 Feb 2014, at 11:09, Chris Angelico wrote:
> On Thu, Feb 27, 2014 at 7:44 PM, Ronald Oussoren
> wrote:
>> What about (also mentioned in the PEP)?
>>
>> value = (expr except Exception try default)
>>
>> This seems to read nicely, although “try” is at a completely different
>> position
Hi there.
The discussion on http://bugs.python.org/issue20440 started me thinking that
much of this
bikeshedding could be avoided if we weren't constrained to writing macros for
all of this stuff.
For example, a
Py_INLINE(PyObject *) Py_Incref(PyObject *obj)
{
Py_INCREF(obj);
return obj;
On Thu, Feb 27, 2014 at 7:44 PM, Ronald Oussoren wrote:
> What about (also mentioned in the PEP)?
>
> value = (expr except Exception try default)
>
> This seems to read nicely, although “try” is at a completely different
> position than it is in the equivalent try statement.
>
> I like the gene
On 21 Feb 2014, at 16:52, Chris Angelico wrote:
> On Sat, Feb 22, 2014 at 1:34 AM, Brett Cannon wrote:
>> While I like the general concept, I agree that it looks too much like a
>> crunched statement; the use of the colon is a non-starter for me. I'm sure
>> I'm not the only one whose brain has
28 matches
Mail list logo
