Suggestions for 2002

[Tim Peters]

[Raymond Hettinger]
> Suggestion #1:   Issue a dubious syntax warning for multiple
> assignments where there are overlaps between the assigned-to
> variables:
>
> >>> a = ['cat','dog']
> >>> i = 1
> >>> i, a[i] = 0, 'boo'
> >>> a
> ['boo', 'dog']        # not ['cat','boo'] which was expected

Adjust your expectations -- "left to right" is a sacred rule in Python
(albeit still undocumented <wink>).  You might get PyChecker to warn about
this, but it's unlikely to get into the core.

> ...
> Suggestion #2:  Add new built-in functions:  xmap, xfilter, and xzip.
>
> The new generators and iterators make lazy evaluation the
> norm in Python 2.2 except for the functional constructs.
> There is no reason why they can't be lazy also -- generating
> output only when needed, consuming inputs only when
> needed , and allowing for potentially infinite input streams.

This will require a PEP and much debate; the number of gimmicks that *could*
be added here is huge.  You've already discovered it's easy to write things
of this nature in Python, and that will make it a hard sell.  People
interested in this should prototype their dreams in pure-Python libraries
and let the community decide which vision rocks loudest (hey, mixing 3
metaphors in 3 words is a special talent <wink>).

> ...
> Suggestion #3:  Allow 'yield' with no return value.

No chance.  Use "yield None" when you want to yield None.  It's more likely
that a plain "yield" is a case where the programmer forgot to supply a value
than that they deliberately intended to yield None.  Requiring the "yield
None" spelling thus makes the intent unmistakable for everyone, while
catching one kind of error at compile-time.  Well-written Python 1.5.2 that
explicitly intends to *return* None also does an explicit "return None";
here we had a chance to require best practice from the start, and did so
deliberately.

> Suggestion #4:
>
> Add a yield-like keyword 'accept' which suspends execution
> just like 'yield' but creates an object with two methods
> .submit() and .flush() which can take arguments and feed them
> into 'accept'.  Flush returns and raises a StopStream exception.
>
> 'yield' suspends execution and sends back a value.
> 'accept' suspends execution and waits to take-in a value.
> 'yield' makes it easy to write lazy producers.
> 'accept' makes it easy to write steam-like, lazy consumers.

Neil Schemenauer spent a good chunk of time playing with stuff "like this"
when first implementing generators, but eventually dropped it as too little
bang for the highly-more-convoluted buck.  I expect more in this area will
eventually get done, but can't predict what it will look like in the end.
Keep playing with it!

> ...
> Now I'll be quiet until 2003,

Na, we won't hold you to that.