[Python-Dev] Plea for function/method syntax sugar (PEP 318, with a different syntax)

Bob Ippolito bob at redivi.com
Thu Feb 19 11:18:20 EST 2004


On Feb 19, 2004, at 10:53 AM, Josiah Carlson wrote:

>
> [Bob Ippolito]
>
> [snip]
>> This evaluation order is Guido approved, though at least one person
>> wanted it to be the other way around
>
> I can understand the desire to have it both ways.  That is, while it
> makes sense to have functions applied in list-order, it also makes 
> sense
> to have the resulting function visually in the same order.
>
> [snip some examples, a few from PyObjC]
>
> From what I understand (please correct me if I am wrong), the entirety
> of the PEP seeks to fix the situation where someone wants to alter a
> defined function, the most common case (though I've never used it) in
> making a methods class or static (or really instancemethod and 
> function,
> if we check types in Python 2.3).

Yes, that's what it does, and that would be the common case.

> Now, Bob brings this up in the context of PyObjC, and generating ':'
> separated naming that PyObjC needs.  While I feel for him not wanting 
> to
> type, and even being pained to type so much, I've never needed to do 
> the
> sort of thing that the PEP or Bob offers, and don't know if it is a 
> real
> syntactic gain.  Certainly it makes convenient all of the examples that
> the PEP and Bob offer, but again, is the syntax and functionality
> necessarily clear?

It's not generating ':' separated naming that PyObjC needs.  The 
examples I specified were annotating the functions with type 
information, so that they could be called from Objective C properly .. 
"returnsAnInteger", "returnsVoidTakesAnInteger".  The metaclass for an 
ObjC-derived class makes sure all of the methods end up as selectors, 
but it can only provide "sensible defaults" for type information, and 
they are not always very sensible.

> Both the PEP and Bob offer that the order of invocation of the
> 'translations' could be reversed, and still make sense.  I think this 
> is
> an example of the syntax not being clear.

The common case doesn't need a list, just one function, so it's not 
likely to confuse anyone more than iter(iterable, sentinel) does.

 >>> [raiseex(1), raiseex(2)]
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
   File "<stdin>", line 2, in raiseex
ValueError: 1
 >>> cmp(raiseex(1), raiseex(2))
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
   File "<stdin>", line 2, in raiseex
ValueError: 1

I think that left to right evaluation makes the most sense, because 
that's what Python always does unless parentheses are involved... and 
that's the iteration order for sequence types.  I didn't really even 
consider the other way, until I saw that somebody else did.. and I'd be 
willing to guess that it was someone who has used a lot more 
lisp/scheme than I have ;)

-bob




More information about the Python-Dev mailing list