Mailman 3 February 2009 - Python-ideas

Revised revised PEP on yield-from
by Greg Ewing Feb. 13, 2009

Feb. 13, 2009

Third draft of the PEP, incorporating throw() and close() handling, and other feedback that I have received. PEP: XXX Title: Syntax for Delegating to a Subgenerator Version: $Revision$ Last-Modified: $Date$ Author: Gregory Ewing <greg.ewing(a)canterbury.ac.nz> Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 13-Feb-2009 Python-Version: 2.7 Post-History: Abstract ======== A syntax is proposed to allow a generator to easily delegate part of its operations to another generator, the subgenerator interacting directly with the main generator's caller for as long as it runs. Additionally, the subgenerator is allowed to return with a value, and the value is made available to the delegating generator. The new syntax also opens up some opportunities for optimisation when one generator re-yields values produced by another. Proposal ======== The following new expression syntax will be allowed in the body of a generator: :: yield from <expr> where <expr> is an expression evaluating to an iterable, from which an iterator is extracted. The effect is to run the iterator to exhaustion, during which time it behaves as though it were communicating directly with the caller of the generator containing the ``yield from`` expression (the "delegating generator"). In detail: * Any values that the iterator yields are passed directly to the caller. * Any values sent to the delegating generator using ``send()`` are sent directly to the iterator. (If the iterator does not have a ``send()`` method, values sent in are ignored.) * Calls to the ``throw()`` method of the delegating generator are forwarded to the iterator. (If the iterator does not have a ``throw()`` method, the thrown-in exception is raised in the delegating generator.) * If the delegating generator's ``close()`` method is called, the iterator is finalised before finalising the delegating generator. The value of the ``yield from`` expression is the first argument to the ``StopIteration`` exception raised by the iterator when it terminates. Additionally, generators will be allowed to execute a ``return`` statement with a value, and that value will be passed as an argument to the ``StopIteration`` exception. Formal Semantics ---------------- The statement :: result = yield from expr is semantically equivalent to :: _i = iter(expr) try: _u = _i.next() _v = yield while 1: try: _v = yield _u except Exception, _e: if hasattr(_i, 'throw'): _i.throw(_e) else: raise else: if hasattr(_i, 'send'): _u = _i.send(_v) else: _u = _i.next() except StopIteration, _e: _a = _e.args if len(_a) > 0: result = _a[0] else: result = None finally: if hasattr(_i, 'close'): _i.close() Rationale ========= A Python generator is a form of coroutine, but has the limitation that it can only yield to its immediate caller. This means that a piece of code containing a ``yield`` cannot be factored out and put into a separate function in the same way as other code. Performing such a factoring causes the called function to itself become a generator, and it is necessary to explicitly iterate over this second generator and re-yield any values that it produces. If yielding of values is the only concern, this is not very arduous and can be performed with a loop such as :: for v in g: yield v However, if the subgenerator is to interact properly with the caller in the case of calls to ``send()``, ``throw()`` and ``close()``, things become considerably more complicated. As the formal expansion presented above illustrates, the necessary code is very longwinded, and it is tricky to handle all the corner cases correctly. In this situation, the advantages of a specialised syntax should be clear. Generators as Threads --------------------- A motivating use case for generators being able to return values concerns the use of generators to implement lightweight threads. When using generators in that way, it is reasonable to want to spread the computation performed by the lightweight thread over many functions. One would like to be able to call a subgenerator as though it were an ordinary functions, passing it parameters and receiving a returned value. Using the proposed syntax, a statement such as :: y = f(x) where f is an ordinary function, can be transformed into an equivalent delegation call :: y = yield from g(x) where g is a generator, and the behaviour of the resulting code can be reasoned about by thinking of it as a function that can be suspended. It is also reasonable to expect that if an exception is thrown into the lightweight thread from outside using ``throw()``, it should first be raised in the innermost generator where the thread is suspended, and propagate outwards from there; and that if the lightweight thread is terminated from outside by calling ``close()``, the chain of active generators should be finalised from the innermost outwards. Syntax ------ The particular syntax proposed has been chosen as suggestive of its meaning, while not introducing any new keywords and clearly standing out as being different from a plain ``yield``. Optimisations ------------- Using a specialised syntax opens up possibilities for optimisation when there is a long chain of generators. Such chains can arise, for instance, when recursively traversing a tree structure. The overhead of passing ``next()`` calls and yielded values down and up the chain can cause what ought to be an O(n) operation to become O(n\*\*2). A possible strategy is to add a slot to generator objects to hold a generator being delegated to. When a ``next()`` or ``send()`` call is made on the generator, this slot is checked first, and if it is nonempty, the generator that it references is resumed instead. If it raises StopIteration, the slot is cleared and the main generator is resumed. This would reduce the delegation overhead to a chain of C function calls involving no Python code execution. A possible enhancement would be to traverse the whole chain of generators in a loop and directly resume the one at the end, although the handling of StopIteration is more complicated then. Criticisms ========== Under this proposal, the value of a ``yield from`` expression would be derived in a very different way from that of an ordinary ``yield`` expression. This suggests that some other syntax not containing the word ``yield`` might be more appropriate, but no alternative has so far been proposed, other than ``call``, which has already been rejected by the BDFL. It has been suggested that some mechanism other than ``return`` in the subgenerator should be used to establish the value returned by the ``yield from`` expression. However, this would interfere with the goal of being able to think of the subgenerator as a suspendable function, since it would not be able to return values in the same way as other functions. The use of an argument to StopIteration to pass the return value has been criticised as an "abuse of exceptions", without any concrete justification of this claim. In any case, this is only one suggested implementation; another mechanism could just as well be used to achieve the desired result, namely that the return value of the subgenerator appears as the value of the ``yield from`` expression. Alternative Proposals ===================== Proposals along similar lines have been made before, some using the syntax ``yield *`` instead of ``yield from``. While ``yield *`` is more concise, it could be argued that it looks too similar to an ordinary ``yield`` and the difference might be overlooked when reading code. To the author's knowledge, previous proposals have focused only on yielding values, and thereby suffered from the criticism that the two-line for-loop they replace is not sufficiently tiresome to write to justify a new syntax. By dealing with sent values as well as yielded ones, this proposal provides considerably more benefit. Copyright ========= This document has been placed in the public domain. .. Local Variables: mode: indented-text indent-tabs-mode: nil sentence-end-double-space: t fill-column: 70 coding: utf-8 End: -- Greg

2 2

Proto-PEP on a 'yield from' statement
by Greg Ewing Feb. 13, 2009

Feb. 13, 2009

Comments are invited on the following proto-PEP. PEP: XXX Title: Syntax for Delegating to a Subgenerator Version: $Revision$ Last-Modified: $Date$ Author: Gregory Ewing <greg.ewing(a)canterbury.ac.nz> Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 13-Feb-2009 Python-Version: 2.7 Post-History: Abstract ======== A syntax is proposed to allow a generator to easily delegate part of its operations to another generator, with the subgenerator yielding directly to the delegating generator's caller and receiving values sent to the delegating generator using send(). Additionally, the subgenerator is allowed to return with a value and the value is made available to the delegating generator. The new syntax also opens up some opportunities for optimisation when one generator re-yields values produced by another. Proposal ======== The following new expression syntax will be allowed in the body of a generator: :: yield from <expr> where <expr> is an expression evaluating to an iterator. The effect is to run the iterator to exhaustion, with any values that it yields being passed directly to the caller of the generator containing the ``yield from`` expression (the "delegating generator"), and any values sent to the delegating generator using ``send()`` being sent directly to the iterator. (If the iterator does not have a ``send()`` method, values sent in are ignored.) The value of the ``yield from`` expression is the first argument to the ``StopIteration`` exception raised by the iterator when it terminates. Additionally, generators will be allowed to execute a ``return`` statement with a value, and that value will be passed as an argument to the ``StopIteration`` exception. Formal Semantics ---------------- The statement :: result = yield from iterator is semantically equivalent to :: _i = iterator try: _v = _i.next() while 1: if hasattr(_i, 'send'): _v = _i.send(_v) else: _v = _i.next() except StopIteration, _e: _a = _e.args if len(_a) > 0: result = _a[0] else: result = None Rationale ========= A Python generator is a form of coroutine, but has the limitation that it can only yield to its immediate caller. This means that a piece of code containing a ``yield`` cannot be factored out and put into a separate function in the same way as other code. Performing such a factoring causes the called function to itself become a generator, and it is necessary to explicitly iterate over this second generator and re-yield any values that it produces. If yielding of values is the only concern, this is not very arduous and can be performed with a loop such as :: for v in g: yield v However, if the subgenerator is to receive values sent to the outer generator using ``send()``, it is considerably more complicated. As the formal expansion presented above illustrates, the necessary code is very longwinded, and it is tricky to handle all the corner cases correctly. In this case, the advantages of a specialised syntax should be clear. The particular syntax proposed has been chosen as suggestive of its meaning, while not introducing any new keywords and clearly standing out as being different from a plain ``yield``. Furthermore, using a specialised syntax opens up possibilities for optimisation when there is a long chain of generators. Such chains can arise, for instance, when recursively traversing a tree structure. The overhead of passing ``next()`` calls and yielded values down and up the chain can cause what ought to be an O(n) operation to become O(n\*\*2). A possible strategy is to add a slot to generator objects to hold a generator being delegated to. When a ``next()`` or ``send()`` call is made on the generator, this slot is checked first, and if it is nonempty, the generator that it references is resumed instead. If it raises StopIteration, the slot is cleared and the main generator is resumed. This would reduce the delegation overhead to a chain of C function calls involving no Python code execution. A possible enhancement would be to traverse the whole chain of generators in a loop and directly resume the one at the end, although the handling of StopIteration is more complicated then. Alternative Proposals ===================== Proposals along similar lines have been made before, some using the syntax ``yield *`` instead of ``yield from``. While ``yield *`` is more concise, it could be argued that it looks too similar to an ordinary ``yield`` and the difference might be overlooked when reading code. To the author's knowledge, previous proposals have focused only on yielding values, and thereby suffered from the criticism that the two-line for-loop they replace is not sufficiently tiresome to write to justify a new syntax. By dealing with sent values as well as yielded ones, this proposal provides considerably more benefit. Copyright ========= This document has been placed in the public domain. .. Local Variables: mode: indented-text indent-tabs-mode: nil sentence-end-double-space: t fill-column: 70 coding: utf-8 End: -- Greg

6 15

Revised PEP on yield-from expression
by Greg Ewing Feb. 13, 2009

Feb. 13, 2009

Here's a revision of the PEP incorporating the corrections posted earlier. There is also a new section titled "Generators as Threads" providing additional motivation. PEP: XXX Title: Syntax for Delegating to a Subgenerator Version: $Revision$ Last-Modified: $Date$ Author: Gregory Ewing <greg.ewing(a)canterbury.ac.nz> Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 13-Feb-2009 Python-Version: 2.7 Post-History: Abstract ======== A syntax is proposed to allow a generator to easily delegate part of its operations to another generator, with the subgenerator yielding directly to the delegating generator's caller and receiving values sent to the delegating generator using send(). Additionally, the subgenerator is allowed to return with a value and the value is made available to the delegating generator. The new syntax also opens up some opportunities for optimisation when one generator re-yields values produced by another. Proposal ======== The following new expression syntax will be allowed in the body of a generator: :: yield from <expr> where <expr> is an expression evaluating to an iterable, from which an iterator is extracted. The effect is to run the iterator to exhaustion, with any values that it yields being passed directly to the caller of the generator containing the ``yield from`` expression (the "delegating generator"), and any values sent to the delegating generator using ``send()`` being sent directly to the iterator. (If the iterator does not have a ``send()`` method, values sent in are ignored.) The value of the ``yield from`` expression is the first argument to the ``StopIteration`` exception raised by the iterator when it terminates. Additionally, generators will be allowed to execute a ``return`` statement with a value, and that value will be passed as an argument to the ``StopIteration`` exception. Formal Semantics ---------------- The statement :: result = yield from expr is semantically equivalent to :: _i = iter(expr) try: _v = yield _i.next() while 1: if hasattr(_i, 'send'): _v = yield _i.send(_v) else: _v = yield _i.next() except StopIteration, _e: _a = _e.args if len(_a) > 0: result = _a[0] else: result = None Rationale ========= A Python generator is a form of coroutine, but has the limitation that it can only yield to its immediate caller. This means that a piece of code containing a ``yield`` cannot be factored out and put into a separate function in the same way as other code. Performing such a factoring causes the called function to itself become a generator, and it is necessary to explicitly iterate over this second generator and re-yield any values that it produces. If yielding of values is the only concern, this is not very arduous and can be performed with a loop such as :: for v in g: yield v However, if the subgenerator is to receive values sent to the outer generator using ``send()``, it is considerably more complicated. As the formal expansion presented above illustrates, the necessary code is very longwinded, and it is tricky to handle all the corner cases correctly. In this case, the advantages of a specialised syntax should be clear. Generators as Threads --------------------- A motivating use case for generators being able to return values concerns the use of generators to implement lightweight threads. When using generators in that way, it is reasonable to want to spread the computation performed by the lightweight thread over many functions. One would like to be able to call subgenerators as though they were ordinary functions, passing them parameters and receiving a returned value. Using the proposed syntax, a function call such as :: y = f(x) where f is an ordinary function, can be transformed into an equivalent generator call :: y = yield from g(x) where g is a generator. Syntax ------ The particular syntax proposed has been chosen as suggestive of its meaning, while not introducing any new keywords and clearly standing out as being different from a plain ``yield``. Optimisations ------------- Using a specialised syntax opens up possibilities for optimisation when there is a long chain of generators. Such chains can arise, for instance, when recursively traversing a tree structure. The overhead of passing ``next()`` calls and yielded values down and up the chain can cause what ought to be an O(n) operation to become O(n\*\*2). A possible strategy is to add a slot to generator objects to hold a generator being delegated to. When a ``next()`` or ``send()`` call is made on the generator, this slot is checked first, and if it is nonempty, the generator that it references is resumed instead. If it raises StopIteration, the slot is cleared and the main generator is resumed. This would reduce the delegation overhead to a chain of C function calls involving no Python code execution. A possible enhancement would be to traverse the whole chain of generators in a loop and directly resume the one at the end, although the handling of StopIteration is more complicated then. Alternative Proposals ===================== Proposals along similar lines have been made before, some using the syntax ``yield *`` instead of ``yield from``. While ``yield *`` is more concise, it could be argued that it looks too similar to an ordinary ``yield`` and the difference might be overlooked when reading code. To the author's knowledge, previous proposals have focused only on yielding values, and thereby suffered from the criticism that the two-line for-loop they replace is not sufficiently tiresome to write to justify a new syntax. By dealing with sent values as well as yielded ones, this proposal provides considerably more benefit. Copyright ========= This document has been placed in the public domain. .. Local Variables: mode: indented-text indent-tabs-mode: nil sentence-end-double-space: t fill-column: 70 coding: utf-8 End: -- Greg

1 0

Re: [Python-ideas] Proto-PEP on a 'yield from' statement
by Greg Ewing Feb. 13, 2009

Feb. 13, 2009

Mike Meyer wrote: > While you're working on that, you might consider dealing with the > behavior of StopIteration exceptions. They're odd enough before this > gets added; it's not at all clear to me what's going on with them > here. I'm not sure what I should add. The PEP is written on the assumption that the reader understands how iterators and generators currently work, including StopIteration. Given that, I think it ought to be fairly clear how StopIteration is being used in the proposal. It's not much different from what you would do if you wanted to iterate over an iterator manually, without using a for-loop: try: while 1: x = myiter.next() ... except StopIteration: pass The only difference is that instead of ignoring the StopIteration instance itself, we use it to carry the return value of the generator. I don't think the PEP is the right place to put tutorial information about the current StopIteration mechanism. -- Greg

1 0

String formatting and namedtuple
by Lie Ryan Feb. 11, 2009

Feb. 11, 2009

I've been experimenting with namedtuple, it seems that string formatting doesn't recognize namedtuple as mapping. from collections import namedtuple Nt = namedtuple('Nt', ['x', 'y']) nt = Nt(12, 32) print 'one = %(x)s, two = %(y)s' % nt # output should be: one = 12, two = 32 currently, it is possible to use nt._asdict() as a workaround, but I think it will be easier and more intuitive to be able to use namedtuple directly with string interpolation Sorry, if this issue has been discussed before.

6 11

String formatting and namedtuple
by Carl Johnson Feb. 11, 2009

Feb. 11, 2009

See if you can add a patch for this too: >>> print( 'one = {x}s, two = {y}s'.format(**nt)) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: format() argument after ** must be a mapping, not Nt

1 0

__data__
by spir Feb. 10, 2009

Feb. 10, 2009

Hello, I stepped on an issue recently that let me reconsider what we actually do and mean when subtyping, especially when deriving from built-in types. The issue basically is I need to add some information and behaviour to "base data" that can be of any type. (See PS for details.) When subtyping int, I mean instances of MyInt to basically "act as" an int. This does not mean, in fact, inheriting int's attributes. This means instead the integer specific operations to apply on a very special attribute instead of applying on the global object. For instance, if n is an instance of MyInt with a value of 2, then: * "print n" will print "2" instead of "<__main__.MyInt object at 0xb7d56ecc>" * "1 + n" will compute "2 + 1" instead of trying to add 1 to the object itself. Relevant method calls to the object are passed to an implicit data attribute. This concretely shows as the nice side-effect to avoid writing "n.data" (or "n.value") all the time. But in fact, from the user's point of view, an instance of a derived type such as MyInt basically *is* an int with some additional or some changed features. So that implicit indirection is not only nice: it really reflects the intention. In other words, an implicit indirection operates. This indirection is precisely what we need to explicitely write down when, instread of deriving from int, we simulate the built-in type's behaviour: class MyInt(object): def __init__(self, value): self.value = value def __add__(self, other): return self.value + other # or more precisely: int.__add__(self.value, other) def __str__(self): return str(self.value) Whatever their actual implementation, built-in types will target operations toward the real, basic, data item that represents the value. Ordinary inheritance instead does not cause objects to "act as" whatever base, silently indirecting relevant operations to an implicit data field -- if not explicitely written. There is no special data at all, and no specific behaviour targeted to that data. Moreover, as shown in the simulation case above, making a custom type does not imply any inheritance, rather it simply requires properly targeting relevant methods. There is *no base type*: there is *base data* instead -- which has its own type. Deriving to let instances "act as" base type instances, finally requires only to tell the interpreter which attribute holds the base data. Then, when a method is called on an instance, if ever this method is not defined for its type, nore for this very instance, the interpreter can (try and) apply it on the basic data instead. If ever deriving can actually work that way, then there is no reason to declare a parent class at definition time, thus forever closing what kind of data is allowed. The fictional code snippets below give the interpreter all the information it needs: class MyInt(object): # no specific base def __init__(self, value): int.__init__(self, value) class MyInt(object): __data__ = "value" def __init__(self, value): self.value = value class MyInt(object): def __init__(self, value): self.__data__ = value The first one has the drawback of allowing several base.__init__ calls (desirable feature?), obviously leading to method name clashes. Also, if ever the type is not predictable, we need to use an even more complicated syntax such as type(value).__init__(self,value) which by the way shows how redondant such a call is (value has to be uselessly specified twice). The second form simply tells which field is to be considered as holding hte base data, so that the interpreted can properly process indirection. The third version even simplierly stores the base data into a magic field name. In both cases, the absence of a __data__ attribute means there is no basic data, thus inheritance (from object or any base class or classes) and method call operate normally. Probably some will consider that the present way of achieving the same goal (combining inheritance with possible call to base.__init__ if needed) is simpler, clearer, etc... I will not argue on that point. Still, consider the following: class MyInt(int): def __init__(self, value): data = int(value) int.__init__(self, data) class MyInt(int): def __init__(self, value): data = int(value) super(MyInt, self).__init__(self, data)) class MyInt(object): __data__ = "data" def __init__(self, value): self.data = int(value) class MyInt(object): def __init__(self, value): self.__data__ = int(value) I find third and fourth versions self-commenting. The fourth one is simpler and straightforward, but the third one makes the existence of __data__ more obvious (so we know at first sight that this type is able to operate silent indirection). Moreover --this is the reason why I first had to study that point closer--, the present syntax requires the base type to be unique *and* known at design time. Which must not be. I do not know however if there are many use cases for flexible base types. Still, versions 3 and 4 allow it without any overload: __data__ (or data) can be of any type, and can even change at runtime: what's the point? Denis ------ la vita e estranya PS: use case. I started to write a kind of parser generator based on a grammar inspired by PEG (http://en.wikipedia.org/wiki/Parsing_expression_grammar), like pyparsing. The way I see it implies several requirements for the parse result type: -0- Basically, valid results of succesful matches can be "empty" (eg from optional or lookahead expression), "single" (simple string), or "sequential" (when generated from repetition or sequence patterns). -1- Each (sub)result knows its own "nature" (implemented as a reference to the pattern that generated it); so that when patterns contain choices the client codes does not need partially reparse the result, only to know what the result actually is -- which the parser has already determined! Moreover, the client code needs only to comprise minimal knowledge about the grammar, as long as the parser passes by all the information it has collected. -2- Global and partial results can be output in several practicle formats including a "treeView" that +/- represents the parse tree. -3- Results can be transformed to prepare further processing -- which may well be only final output. There are several standard methods needed for this (glue a result sequence into a single string, extract nested results, keep only the parse tree's leaves); results can also be converted (e.g. an int representation into an int) or changed in whatever manner using ad hoc functions: eventually result data can well be of custom types. (This is actually a very interesting feature: for instance when parsing wikitext, a "styled_text" result may instantiate a StyledText object as an abstract represention of it, that can e.g. write itself to a DB, another wiki lang, x/html... The conceptual nature of a result requires the object to implicitely indirect proper methods to the real result data it holds. For instance, the client code should be able to write an addition on a result if ever additioning this result has a sense, and this operation to be implicited applied on the underlying data. First and second points require a custom type with additional information and behaviour. Third point requires flexibility on the base type.

3 3

Allow lambda decorators
by Carl Johnson Feb. 10, 2009

Feb. 10, 2009

A few months back there was a discussion of how code like this gives "surprising" results because of the scoping rules: >>> def func_maker(): ... fs = [] ... for i in range(10): ... def f(): ... return i ... fs.append(f) ... return fs ... >>> [f() for f in func_maker()] [9, 9, 9, 9, 9, 9, 9, 9, 9, 9] Various syntax changes were proposed to get around this, but nothing ever came of it. Also recently, I tried to propose a new syntax to allow Ruby-like blocks in Python without sacrificing Python's indenting rules. My idea was that "@" would mean "placeholder for a function to be defined on the next line" like so: >>> sorted(range(10), key=@): ... def @(item): ... return -item ... [9, 8, 7, 6, 5, 4, 3, 2, 1, 0] Thinking about it some more, I've realized that the change I proposed is unnecessary, since we already have the decorator syntax. So, for example, the original function can be made to act with the "expected" scoping by using an each_in function defined as follows: >>> def each_in(seq): ... return lambda f: [f(item) for item in seq] ... >>> def func_maker(): ... @each_in(range(10)) ... def fs(i): ... def f(): ... return i ... return f ... return fs #Warning, fs is a list, not a function! ... >>> [f() for f in func_maker()] [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] On the one hand, I can imagine some people thinking this is decorator abuse, since the each_in decorator produces a list and not a function. If so, I suppose the lambda might be changed to >>> def each_in(seq): ... return lambda f: lambda: [f(item) for item in seq] ... >>> def func_maker(): ... @each_in(range(10)) ... def fs(i): ... def f(): ... return i ... return f ... return fs() #Warning, fs is a function, not a list ... >>> [f() for f in func_maker()] [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] In either version the important thing is that it provides a scoped version of a for-loop, which those from a C++ background might be more conditioned to expect. Possibly, such a function could be added to the functools or the itertools. It would be useful for when scoping issues arise, for example when adding a bunch of properties or attributes to a class. Thinking about it some more though, it's hard to see why such a trivial function is needed for the library. There's no reason it couldn't just be done as an inline lambda instead: >>> def func_maker(): ... @lambda f: [f(i) for i in range(10)] ... def fs(i): ... def f(): ... return i ... return f ... return fs #Warning, fs is a list, not a function! ... >>> [f() for f in func_maker()] [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] OK, actually there is one reason this couldn't be done as a lambda: >>> @lambda f: [f(i) for i in range(10)] File "<stdin>", line 1 @lambda f: [f(i) for i in range(10)] ^ SyntaxError: invalid syntax This is because the decorator grammar asks for a name, not an expression, as one (well, OK, me a couple months ago) might naively expect. decorator: '@' dotted_name [ '(' [arglist] ')' ] NEWLINE decorators: decorator+ decorated: decorators (classdef | funcdef) and not decorator: '@' test NEWLINE decorators: decorator+ decorated: decorators (classdef | funcdef) Changing the grammar would also allow for the rewriting of the sorted example given earlier: >>> @lambda key: sorted(range(10), key=key) ... def sorted_list(item): ... return -item ... >>> sorted_list [9, 8, 7, 6, 5, 4, 3, 2, 1, 0] Of course, the use of lambda decorator is strictly speaking unnecessary, >>> k = lambda key: sorted(range(10), key=key) >>> @k ... def sorted_list(item): ... return -item ... >>> del k >>> sorted_list [9, 8, 7, 6, 5, 4, 3, 2, 1, 0] But, I think I think that allowing lambda decorators would be convenient for a number of situations and it would give a simple answer to those asking for a multiline lambda or Ruby-like blocks. What do other people think? -- Carl

14 31

Making stars optional? (was: Making colons optional?)
by Bruce Leban Feb. 10, 2009

Feb. 10, 2009

In algebra, you don't have to put a multiplication sign in between two quantities that you want to multiply. I've seen beginning programmers write things like x = 3a + 4(b-c) instead of x = 3*a + 4*(b-c) Why should we require the stars when it's unambiguous what the first statement means? --- Bruce P.S. Pascal used words if ... then ... and while ... do ... and begin ... end. I like non-alpha symbols that stand out better, like colons, braces and indentation. I don't need a semicolon to tell me where the end of a line is. I only need something to tell me where the end of a line ISN'T and I handle that with prominent indentation.

10 13

Re: [Python-ideas] [Python-Dev] yield * (Re: Missing operator.call)
by Leif Walsh Feb. 10, 2009

Feb. 10, 2009

[+python-ideas -python-dev] On Sat, Feb 7, 2009 at 8:50 PM, <glyph(a)divmod.com> wrote: > has anyone considered the syntax 'yield from iterable'? i.e. > > def foo(): > yield 1 > yield 2 > > def bar(): > yield from foo() > yield from foo() > > list(bar()) -> [1, 2, 1, 2] > > I suggest this because (1) it's already what I say when I see the 'for' > construct, i.e. "foo then *yield*s all results *from* bar", and (2) no new > keywords are required. I still don't understand why such a construct is necessary. Is >>> for elt in iterable: >>> yield elt really all that bad? Maybe it's a little silly-looking, but at least it's easy to understand and not _that_ hard to type.... -- Cheers, Leif

6 11