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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4