Re: [Python-Dev] PEP 463: Exception-catching expressions

[Ronald Oussoren]

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 been trained to view a colon in Python
>> to mean "statement", period. This goes against that syntactic practice and
>> just doesn't work for me.
>> 
>> I'm -1 with the current syntax, but it can go into the + range if a better
>> syntax can be chosen.
> 
> We bikeshedded that extensively on -ideas. The four best options are:
> 
> value = (expr except Exception: default)
> value = (expr except Exception -> default)
> value = (expr except Exception pass default)
> value = (expr except Exception then default)
> 
> Note that the last option involves the creation of a new keyword.
> 
> Would any of the others feel better to you?

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 general idea, but like Brett I don’t like using a colon here at all.

Ronald

P.S. Sorry if this way already brought up, I’ve browsed through most of the 
threads on this on -ideas and -dev, but haven’t read all messages.
> 
> ChrisA
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> https://mail.python.org/mailman/options/python-dev/ronaldoussoren%40mac.com

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 463: Exception-catching expressions

[Chris Angelico]

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 general idea, but like Brett I don’t like using a colon here at 
> all.

I see your "although" clause to be quite a strong objection. In the
statement form of an if, you have:

if cond: true_suite
else: false_suite

In the expression form, you have:

true_expr if cond else false_expr

Personally, I think it's a weakness of the if-expression that they're
not in the same order (cond, true_expr, false_expr), but they're still
introduced with the same keywords. The 'if' keyword is followed by the
condition, and the 'else' keyword by the false "stuff".

Putting "try" followed by the default is confusing, because any
exception raised in the default-expr will bubble up. Stealing any
other keyword from the try/except block would make just as little
sense:

expr except Exception finally default # "finally" implies something
that always happens
expr except Exception else default # "else" implies *no* exception
expr except Exception try default # "try" indicates the initial expr,
not the default
default except Exception try expr # breaks L->R evaluation order

Left to right evaluation order is extremely important to me. I don't
know about anyone else, but since I'm the one championing the PEP,
you're going to have to show me a *really* strong incentive to reword
it to advocate something like the last one :) This is stated in the
PEP:

http://www.python.org/dev/peps/pep-0463/#alternative-proposals

Using try and except leaves the notation "mentally ambiguous" as to
which of the two outer expressions is which. It doesn't make perfect
sense either way, and I expect a lot of people would be flicking back
to the docs constantly to make sure they had it right. It's hard when
there's confusion across languages (try writing some code in REXX and
Python that uses division and modulo operators - 1234/10 -> 123.4 in
Py3 and REXX, but 1234//10 and 1234%10 have opposite meaning); it's
unnecessarily hard to have the same confusion in different places in
the same language.

ChrisA
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Start writing inlines rather than macros?

[Kristján Valur Jónsson]

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;
}

could be used in a Py_Assign() function, if a new reference were wanted:
Py_INLINE(void) Py_Assign(PyObject ** target, PyObject *obj)
{
PyObject *tmp = *target;
*target = tmp;
Py_DECREF(tmp);
}

So that you could then safely write code like
Py_Assign(&MyVar, Py_Incref(obj));
This would also allow you to stop writing various super macros to try to cater 
to all possible permutations.

Now, Larry Hastings pointed out that we support C89 which doesn't support 
Inlines.  Rather than suggesting here that we update that compatibility 
requirement,
how about adding a Py_INLINE() macro.?  This would be like Py_LOCAL_INLINE() 
except that it would drop the "static" keyword, unless inline isn't supported:

#if defined(_MSC_VER)
#define Py_INLINE(type) __inline type
#elif defined(USE_INLINE)
#define Py_INLINE(type) inline type
#else
#define Py_INLINE(type) static type
#endif

The only question is with the last line.  How many platforms actually _do_not_ 
have inlines?  Would writing stuff like this be considered problematic for 
those platforms?  Note, that I'm not suggesting replacing macros all over the 
place, only for new code.
Another question is:  Is "static inline" in any practical way different from 
"inline"?

It would be great to get rid of macros in code. It would be great for debugging 
too!

K
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 463: Exception-catching expressions

[Ronald Oussoren]

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 than it is in the equivalent try statement.
>> 
>> I like the general idea, but like Brett I don’t like using a colon here at 
>> all.
> 
> I see your "although" clause to be quite a strong objection. In the
> statement form of an if, you have:

I’m not convinced that this is a strong objection. The order of keywords is 
different, but that doesn’t have to be problem.

> 
> if cond: true_suite
> else: false_suite
> 
> In the expression form, you have:
> 
> true_expr if cond else false_expr

[…]

> 
> 
> Putting "try" followed by the default is confusing, because any
> exception raised in the default-expr will bubble up. Stealing any
> other keyword from the try/except block would make just as little
> sense:
> 
> expr except Exception finally default # "finally" implies something
> that always happens
> expr except Exception else default # "else" implies *no* exception
> 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 not as a RTL 
expression.  

> default except Exception try expr # breaks L->R evaluation order
> 
> Left to right evaluation order is extremely important to me.

I agree with that, RTL evaluation would be pretty odd in Python.


> I don't
> know about anyone else, but since I'm the one championing the PEP,
> you're going to have to show me a *really* strong incentive to reword
> it to advocate something like the last one :) This is stated in the
> PEP:
> 
> http://www.python.org/dev/peps/pep-0463/#alternative-proposals
> 
> Using try and except leaves the notation "mentally ambiguous" as to
> which of the two outer expressions is which. It doesn't make perfect
> sense either way, and I expect a lot of people would be flicking back
> to the docs constantly to make sure they had it right.

Really? The evaluation order you mention in above didn’t make sense to me until 
I tried to make sense of it.

Ronald

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Start writing inlines rather than macros?

[Victor Stinner]

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 Visual Studio 2010. I'm pretty sure that these compilers support
inline functions.

I'm also in favor of using inline functions instead of long macros
using ugly hacks like "instr1,instr2" syntax where instr1 used
assert(). See for example unicodeobject.c to have an idea of what
horrible macros mean.

I'm in favor of dropping C89 support and require at least C99. There
is now C11, it's time to drop the old C89.
http://en.wikipedia.org/wiki/C11_%28C_standard_revision%29

Victor
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 463: Exception-catching expressions

[Chris Angelico]

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 not as a 
> RTL expression.

Thing is, in the statement form, "try doing this" means "do this, and
you might get an exception, so deal with it". In the 'try default'
form, "try this" means "oops, you got an exception, so try this
instead". It's using "try" in the opposite way.

>> default except Exception try expr # breaks L->R evaluation order
>>
>> Left to right evaluation order is extremely important to me.
>
> I agree with that, RTL evaluation would be pretty odd in Python.
>
> Really? The evaluation order you mention in above didn’t make sense to me 
> until I tried to make sense of it.

The "default except Exception try expr" notation has "try" followed by
the thing that might raise an exception, which mimics the statement.
The "expr except Exception try default" notation evaluates from left
to right. Both make some sense, and I'd say it's on balance which is
the more likely to be expected. Imagine an overall expression where
it's ambiguous:

value = (d["foo"] except KeyError try d["spam"])

Which one do you expect to be tried first? I'd say you could poll a
bunch of moderately-experienced Python programmers and get both
answers in reasonable numbers.

ChrisA
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 463: Exception-catching expressions

[Nick Coghlan]

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 nicely, although "try" is at a completely different 
>>> position than it is in the equivalent try statement.
>>>
>>> I like the general idea, but like Brett I don't like using a colon here at 
>>> all.
>>
>> I see your "although" clause to be quite a strong objection. In the
>> statement form of an if, you have:
>
> I'm not convinced that this is a strong objection. The order of keywords is 
> different, but that doesn't have to be problem.

As Chris notes, the problem is that if you use "try", the two
plausible interpretations are:

1. Evaluates left-to-right, try introduces a different part of the
syntax (different from every past statement->expression conversion
where the clauses are reordered, but almost always introduced by the
same keywords as they are in the statement form)
2. Evaluates right-to-left, try introduces the expressions covered by
the exception handler (this is just backwards, and significantly
harder to follow than even the "middle first" conditional expression)

Neither interpretation is particularly acceptable, and the fact that
the other interpretation would remain plausible regardless is a
further strike against both of them.

Personally, I think the PEP makes a good case for particular semantics
with a spelling that isn't great, but isn't completely abhorrent
either. I definitely think it represents an improvement over the
status quo, which is an ongoing proliferation of function-based
special cases for doing particular kinds of exception handling as an
expression, and the spelling advocated for in the PEP seems like the
best of the (many) alternatives that have been proposed.

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 {IndexError: "No value"})

The analogy isn't exact (since exception handling is isinstance()
based rather than equality based), but I think it gives the right
general flavour in terms of the intended meaning of the colon in this
construct. The analogy could likely be encouraged and strengthened by
changing the parentheses requirements to make this read more like a
binary except expression with a parenthesised RHS rather than a
ternary expression:

lst[2] except (IndexError: "No value")

Catching multiple errors would involve a parenthesised tuple as the "key":

f() except ((TypeError, AttributeError): "No value")

The deferred "multiple except clauses" part of the PEP could also
change to be more dict display like:

value = expr except (
Exception1: default1,
Exception2: default2,
Exception3: default3,
   )

Writing out those examples, I actually like that version (where the
parentheses are still mandatory, but the left paren is after the
except keyword rather than before the first expression) better than
the one currently in the PEP. It also avoids the weirdly unbalanced
look of the variant that had the left paren *before* the except
keyword. The main downside I see is that the exception handling
definition syntax would only be permitted in that specific location,
but still look a lot like an ordinary parenthesised expression.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Start writing inlines rather than macros?

[Kristján Valur Jónsson]

> -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 and Clang are used. On Windows, it's
> Visual Studio 2010. I'm pretty sure that these compilers support inline
> functions.
> 
> I'm also in favor of using inline functions instead of long macros using ugly
> hacks like "instr1,instr2" syntax where instr1 used assert(). See for example
> unicodeobject.c to have an idea of what horrible macros mean.
> 
> I'm in favor of dropping C89 support and require at least C99. There is now
> C11, it's time to drop the old C89.
> http://en.wikipedia.org/wiki/C11_%28C_standard_revision%29

well, requiring C99 is another discussion which I'm not so keen on instigating 
:)
As you point out, most of our target platforms probably do support inline
already.  My question is more of the nature: What about those that don't support
inline, is there any harm in defaulting to "static" in that case and leave the 
inlining
to the optimizer on those platforms?

K
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Poll: Py_REPLACE/Py_ASSIGN/etc

[Kristján Valur Jónsson]

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 Xs constitue a permutation explosion, particularly if you want then also 
versions that INCREF the source :)
K

From: Python-Dev [mailto:python-dev-bounces+kristjan=ccpgames@python.org] 
On Behalf Of Nick Coghlan
Sent: 27. febrúar 2014 00:12
To: Antoine Pitrou
Cc: python-dev@python.org
Subject: Re: [Python-Dev] Poll: Py_REPLACE/Py_ASSIGN/etc


On 27 Feb 2014 04:28, "Antoine Pitrou" 
mailto:solip...@pitrou.net>> wrote:
>
> On Wed, 26 Feb 2014 11:40:01 +0200
> Serhiy Storchaka mailto:storch...@gmail.com>> wrote:
>
> > There were several suggestions for naming new macros which replace old
> > value with new value and then (x)decref old value.
> >
> > #define Py_XXX(ptr, value)\
> >  { \
> >  PyObject *__tmp__ = ptr;  \
> >  ptr = new_value;  \
> >  Py_DECREF(__tmp__);   \
> >  }
>
>
> > 1. Py_(X)SETREF.
>
> My vote is on this one.
> I'm also -1 on any name which doesn't have "REF" in it; the name should
> clearly suggest that it's a refcounting operation.

Yeah, I think SETREF is my favourite as well (even though some of the later 
suggestions were mine).

Cheers,
Nick.

>
> Regards
>
> Antoine.
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Start writing inlines rather than macros?

[Brett Cannon]

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 practice, recent versions of GCC and Clang are used. On Windows,
> it's Visual Studio 2010. I'm pretty sure that these compilers support
> inline functions.
>
> I'm also in favor of using inline functions instead of long macros
> using ugly hacks like "instr1,instr2" syntax where instr1 used
> assert(). See for example unicodeobject.c to have an idea of what
> horrible macros mean.
>
> I'm in favor of dropping C89 support and require at least C99. There
> is now C11, it's time to drop the old C89.
> http://en.wikipedia.org/wiki/C11_%28C_standard_revision%29


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 backwards-compatible way
with VS.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Start writing inlines rather than macros?

[Sturla Molden]

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 backwards-compatible way 
> with VS.

So you are saying that Python should use "the C that Visual Studio
supports"? I believe Microsoft is not competent to define the C standard.
If they cannot provide a compiler that is their bad. There are plenty of
other standard-compliant compilers we can use, including Intel, clang and
gcc (MinGW).

Sturla

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Start writing inlines rather than macros?

[Brett Cannon]

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 in C99
> > features, though, that we can somehow support in a backwards-compatible
> way with VS.
>
> So you are saying that Python should use "the C that Visual Studio
> supports"?


Well, C89 + Amendments which happens to be what all C compilers support,
including VS.


> I believe Microsoft is not competent to define the C standard.
>

Maybe, but they still control a large install base.


> If they cannot provide a compiler that is their bad.


And unfortunately ours if we want Windows developers to be able to use
CPython for things like embedding,


> There are plenty of
> other standard-compliant compilers we can use, including Intel, clang and
> gcc (MinGW).
>

You manage to convince a majority of Windows developers to switch compilers
and then I would be happy to promote we drop VS support and switch entirely
to C99. Until then, though, this is like suggesting we cut off Windows XP
because MS doesn't have long-term support anymore: it's a choice between
being pragmatic for serving our install base or doing something to simplify
our lives.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Start writing inlines rather than macros?

[Mark Shannon]

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?
In practice, recent versions of GCC and Clang are used. On Windows, it's
Visual Studio 2010. I'm pretty sure that these compilers support inline
functions.

I'm also in favor of using inline functions instead of long macros using ugly
hacks like "instr1,instr2" syntax where instr1 used assert(). See for example
unicodeobject.c to have an idea of what horrible macros mean.

I'm in favor of dropping C89 support and require at least C99. There is now
C11, it's time to drop the old C89.
http://en.wikipedia.org/wiki/C11_%28C_standard_revision%29


well, requiring C99 is another discussion which I'm not so keen on instigating 
:)
As you point out, most of our target platforms probably do support inline
already.  My question is more of the nature: What about those that don't support
inline, is there any harm in defaulting to "static" in that case and leave the 
inlining
to the optimizer on those platforms?


I agree, modern compilers will inline quite aggressively, so declaring a 
function static
is as good as declaring it inline, provided the function is small.
Static functions are a lot easier to read and maintain than 
LOUD_BUT_UNTYPED_MACRO(x)  :)

Cheers,
Mark.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Start writing inlines rather than macros?

[Antoine Pitrou]

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 to pull in C99
> > features, though, that we can somehow support in a backwards-compatible way 
> > with VS.
> 
> So you are saying that Python should use "the C that Visual Studio
> supports"? I believe Microsoft is not competent to define the C standard.
> If they cannot provide a compiler that is their bad. There are plenty of
> other standard-compliant compilers we can use, including Intel, clang and
> gcc (MinGW).

Other C compilers don't support all of C99, AFAIR. We sometimes get
such bug reports from e.g. AIX users.
I'd be all for accepting C99, ideally. But we must care about our
users' constraints.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Start writing inlines rather than macros?

[Skip Montanaro]

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 that
doesn't understand the inline keyword, so you choose the static
declaration as Kristján suggested. The resulting Python executable
should be functionally correct, but if the optimizer doesn't happen to
inline a given static function you might be stuck with some bad
performance across-the-board (if it never inlines, or doesn't inline
where we really need it to), or only under some circumstances (as a
hypothetical example, inlining in dictobject.c, but not in ceval.c).
Is there a configurable way to tell if a compiler will inline
functions which are declared static, and possibly under what
conditions they might not? It might still be necessary to maintain
macros for those platforms.

Skip
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Start writing inlines rather than macros?

[Antoine Pitrou]

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 can assure you they haven't :-)

> I do have one question though. Suppose you encounter a compiler that
> doesn't understand the inline keyword, so you choose the static
> declaration as Kristján suggested. The resulting Python executable
> should be functionally correct, but if the optimizer doesn't happen to
> inline a given static function you might be stuck with some bad
> performance across-the-board

You're right. Since we only define macros where performance is critical
(such as INCREF and DECREF), it would definitely have a very
significant impact on performance.

> Is there a configurable way to tell if a compiler will inline
> functions which are declared static, and possibly under what
> conditions they might not? It might still be necessary to maintain
> macros for those platforms.

Well, if we must maintain macros, let's maintain them everywhere and
avoid the burden of two different implementations for the same thing.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Start writing inlines rather than macros?

[Skip Montanaro]

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, as some sort of pre-compile
step?

S
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 463: Exception-catching expressions

[Glenn Linderman]

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 {IndexError: "No value"})

The analogy isn't exact (since exception handling is isinstance()
based rather than equality based), but I think it gives the right
general flavour in terms of the intended meaning of the colon in this
construct. The analogy could likely be encouraged and strengthened by
changing the parentheses requirements to make this read more like a
binary except expression with a parenthesised RHS rather than a
ternary expression:

 lst[2] except (IndexError: "No value")

Catching multiple errors would involve a parenthesised tuple as the "key":

 f() except ((TypeError, AttributeError): "No value")

The deferred "multiple except clauses" part of the PEP could also
change to be more dict display like:

 value = expr except (
 Exception1: default1,
 Exception2: default2,
 Exception3: default3,
)

Writing out those examples, I actually like that version (where the
parentheses are still mandatory, but the left paren is after the
except keyword rather than before the first expression) better than
the one currently in the PEP. It also avoids the weirdly unbalanced
look of the variant that had the left paren*before*  the except
keyword. The main downside I see is that the exception handling
definition syntax would only be permitted in that specific location,
but still look a lot like an ordinary parenthesised expression.

Cheers,
Nick.

+1

f() except ((TypeError, AttributeError): "No value")

is a nice extension to the idea of

value = expr except (
Exception1: default1,
Exception2: default2,
Exception3: default3,
   )

Which I've liked since I first saw it, as it neatly solves handling multiple 
except clauses.

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Start writing inlines rather than macros?

[Antoine Pitrou]

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 generate the macro versions from the
> inline/static versions where necessary, as some sort of pre-compile
> step?

Uh... well, perhaps, but one still has to check if the macros *are*
correct.
(I'm not sure a static-to-macro converter would be trivial to write)

Regards

Antoine.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 463: Exception-catching expressions

[Chris Angelico]

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,
>)
>
> Which I've liked since I first saw it, as it neatly solves handling multiple
> except clauses.

You can already list multiple exception types. The definition of the
exception_list is exactly as per the try/except statement (bar the
'as' keyword, which I would love to see implemented some day).

ChrisA
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 463: Exception-catching expressions

[Chris Angelico]

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 the same line(s)), and the
code's a bit messy, but it does work. I ran it on the Python stdlib
and it produced a whole lot of edits (I had it keep the old version in
comments, bracketed with markers with the text "PEP 463" in them,
which makes it easy to find and analyze); one file (with two try
blocks) causes a test failure, but all the rest still pass.

If people can try the script on their own codebases and see how it
looks, that'd be great. I recommend first running the script with
ast.Expr handling removed (as per the file you see above), and then
maybe running it with that one line commented out. You'll get a lot of
unhelpful change suggestions from the double-expression handler.


Could a core committer please apply the last few changes to the PEP?

https://raw.github.com/Rosuav/ExceptExpr/master/pep-0463.txt

or the diff is below. I think this is the last important change left;
things have gone fairly quiet here, and I think the PEP's about ready
to request pronouncement, unless someone knows of something I've
forgotten. (Have I said "I'll write up a paragraph about that" about
anything and not done it yet? Now's the perfect time to remind me.)

Thanks!

ChrisA

diff -r 5f63c8a92d1c pep-0463.txt
--- a/pep-0463.txt Mon Feb 24 14:22:46 2014 -0800
+++ b/pep-0463.txt Fri Feb 28 08:25:33 2014 +1100
@@ -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
+handle an absent key would be to respond to the exception.  One method is
+written which signal the absence in one way, and one consistent technique
+is used to respond to the absence.  Instead, we have dict.get(), and as of
+Python 3.4, we also have min(... default=default), and myriad others.  We
+have a LBYL syntax for testing inside an expression, but there is currently
+no EAFP notation; compare the following::
+
+# LBYL:
+if key in dic:
+process(dic[key])
+else:
+process(None)
+# As an expression:
+process(dic[key] if key in dic else None)
+
+# EAFP:
+try:
+process(dic[key])
+except KeyError:
+process(None)
+# As an expression:
+process(dic[key] except KeyError: None)
+
+Python generally recommends the EAFP policy, but must then proliferate
+utility functions like dic.get(key,None) to enable this.
+

 Rationale
 =
@@ -338,6 +366,19 @@
 except KeyError:
 u = tarinfo.uid

+Look up an attribute, falling back on a default::
+mode = (f.mode except AttributeError: 'rb')
+
+# Lib/aifc.py:882:
+if hasattr(f, 'mode'):
+mode = f.mode
+else:
+mode = 'rb'
+
+return (sys._getframe(1) except AttributeError: None)
+# Lib/inspect.py:1350:
+return sys._getframe(1) if hasattr(sys, "_getframe") else None
+
 Perform some lengthy calculations in EAFP mode, handling division by
 zero as a sort of sticky NaN::

@@ -616,7 +657,7 @@
 it would be with the statement form, and as its syntax is a point on
 which consensus has not been reached, the entire feature is deferred.

-Multiple 'except' keywords can be used, and they will all catch
+Multiple 'except' keywords could be used, and they will all catch
 exceptions raised in the original expression (only)::

 # Will catch any of the listed exceptions thrown by expr;

-- end --
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 463: Exception-catching expressions

[Chris Angelico]

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
> +handle an absent key would be to respond to the exception.  One method is
> +written which signal the absence in one way, and one consistent technique

Doh! Typical... I notice the typo only after hitting send. This should
be "which signals". The linked-to draft file has been updated.

ChrisA
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 463: Exception-catching expressions

[Nick Coghlan]

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,
> > Exception2: default2,
> > Exception3: default3,
> >)
> >
> > Which I've liked since I first saw it, as it neatly solves handling
multiple
> > except clauses.
>
> You can already list multiple exception types. The definition of the
> exception_list is exactly as per the try/except statement (bar the
> 'as' keyword, which I would love to see implemented some day).

Note that this example is covering the deferred case of multiple except
clauses that resolve to different values, not the already handled case of
multiple exception types that resolve to the same value.

Anyway, even if you choose not to switch the parenthesis requirement in
PEP, it should at least make the "colon as in dict display, not as in suite
introduction" comparison, and note this as an alternative proposal for the
required parentheses.

Cheers,
Nick.

>
> ChrisA
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 463: Exception-catching expressions

[Chris Angelico]

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
>> >
>> > value = expr except (
>> > Exception1: default1,
>> > Exception2: default2,
>> > Exception3: default3,
>> >)
>> >
>> > Which I've liked since I first saw it, as it neatly solves handling
>> > multiple
>> > except clauses.
>>
>> You can already list multiple exception types. The definition of the
>> exception_list is exactly as per the try/except statement (bar the
>> 'as' keyword, which I would love to see implemented some day).
>
> Note that this example is covering the deferred case of multiple except
> clauses that resolve to different values, not the already handled case of
> multiple exception types that resolve to the same value.

The "nice extension" to that notation is already handled, though.

> Anyway, even if you choose not to switch the parenthesis requirement in PEP,
> it should at least make the "colon as in dict display, not as in suite
> introduction" comparison, and note this as an alternative proposal for the
> required parentheses.

Hmm. Not sure that it really helps, but okay. Will word something up.

ChrisA
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 463: Exception-catching expressions

[Glenn Linderman]

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 idea of

 value = expr except (
 Exception1: default1,
 Exception2: default2,
 Exception3: default3,
)

Which I've liked since I first saw it, as it neatly solves handling
multiple
except clauses.

You can already list multiple exception types. The definition of the
exception_list is exactly as per the try/except statement (bar the
'as' keyword, which I would love to see implemented some day).

Note that this example is covering the deferred case of multiple except
clauses that resolve to different values, not the already handled case of
multiple exception types that resolve to the same value.

The "nice extension" to that notation is already handled, though.


Yes.  But the point is really the location of the (), sorry if my "nice 
extension" comment is throwing you off that track.


value = expr except (
Exception1: default1,
Exception2: default2,
Exception3: default3,
   )






Anyway, even if you choose not to switch the parenthesis requirement in PEP,
it should at least make the "colon as in dict display, not as in suite
introduction" comparison, and note this as an alternative proposal for the
required parentheses.

Hmm. Not sure that it really helps, but okay. Will word something up.

ChrisA
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/v%2Bpython%40g.nevcal.com




___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 463: Exception-catching expressions

[Chris Angelico]

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 the outside. Either location will
solve most of the same problems (like precedence/associativity versus
multiple except clauses), but shrinking down to just the exception
list and default value makes it look very different. It looks like
what's inside should be an expression, which it isn't. What's the
advantage of this form? What's its key advantage over the
parens-around-the-whole-thing form?

ChrisA
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Start writing inlines rather than macros?

[Stephen J. Turnbull]

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
 > inline/static versions where necessary, as some sort of pre-compile
 > step?

To do that in general is a hard problem, unless you're a C compiler
that already supports inlining.  I'm not sure how easy it would be to
define rules that support the inlines Python demands for performance,
and yet makes function to macro conversion easy.

I think it makes much more sense to look at rewriting the macros by
hand so that they emulate the necessary amount of function semantics
(eg, providing argument type-checking in debug builds, not mutating
arguments unless passed by reference, evaluating arguments exactly
once, etc).  XEmacs has a lot of these for precisely the reason this
thread started (plus the recognition at the time we started this
practice that a number of our platforms could not be trusted to inline
certain performance-critical routines).  They're spelled using the
same conventions as functions, so macros that don't obey those rules
stick out.

Then these function-like macros could be #ifdef'd with the inline
functions, with some (automated) comparison testing on appropriate
benchmarks by building with and without -dDONT_TRUST_INLINE.  And then
beta-testing by defaulting to #undef DONT_TRUST_INLINE.  Then wait for
cries of pain -- if none, remove the dead #ifdef branches in the last
beta or so.

Yes, this involves a certain amount of work, but I think it's bounded.
There should be no extra maintenance of the #ifdef'd parts compared to
the maintenance required to fix bugs resulting from change from macro
semantics to inline semantics anyway, unless changing the macros is
mistake-prone -- which will be recognized immediately.

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 463: Exception-catching expressions

[Glenn Linderman]

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 proposed
syntax didn't have parens around the outside. Either location will
solve most of the same problems (like precedence/associativity versus
multiple except clauses), but shrinking down to just the exception
list and default value makes it look very different. It looks like
what's inside should be an expression, which it isn't. What's the
advantage of this form? What's its key advantage over the
parens-around-the-whole-thing form?


Key advantage to me is that if a function call or other expression may 
produce multiple exceptions, the syntax doesn't require repeating the 
"except" over and over.  By not repeating the except over and over, 
there is less ambiguity about what expression the Exception-lists apply 
to, when there is more than one Exception list in the expression.  
Whereas the current PEP syntax has ambiguity regarding how to interpret  
a-expr except except-list-b: b-expr except except-list-c: c-expr (does 
the 2nd except apply to a-expr or b-expr?), without parentheses, and, as 
far as I am concerned, even with the parentheses, this syntax makes it 
very clear that each of the Exception-lists apply to a-expr.


Key advantage to others may be that because the : is within the () [and 
the leading ( is quite nearby, making it obvious], it is less likely to 
be considered a statement boundary, and more easily explained as a 
special type of list syntax... not _really_ a list, because it is really 
code to be executed somewhat sequentially rather than data, and lists 
don't have : ... and not _really_ a dict constant, which does have :, 
because the Exception is not _really_ a key, but the syntax can draw on 
analogies with the dict constant syntax which will help people remember 
it, and even sort of understand that there is a pair-wise relationship 
between the Exception-list and the expression after the :, without 
repeating the except over and over.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com