[Python-3000] More wishful thinking

[Guido van Rossum]

On 4/15/06, Talin <talin at acm.org> wrote:
> Another grab-bag of language ideas / wishes. Some of these are
> items that have been raised before on other lists - I want to get them
> written down so that they can be rejected quickly :)
>
> 1) I don't know if this is already on the table, but I sure would like
> to be able to have more options as far as mixing positional and
> keyword arguments.

I agree. Please produce a patch that implements what you want.

> 2) A suggestion which I've seen others bring up before is the use of
> the * operator for tuple packing / unpacking operations, i.e.:
>
>     a, *b = (1, 2, 3)

I'm not keen on this one, so I'm not inviting you to write a patch.
But it's not terrible either; if some continent of old-timers agrees
to add it, it could happen.

> 2a) One particularly useful variation of *list (again, one which I have
> brought up before, as have others), is the "yield *" syntax. The primary
> use case is for chained generators, that is a generator that is yielding
> the output of multiple sub-generators.

This doesn't fly so well for the new generator API introduced in 2.5.
Also, the shortcut that you are hoping for won't happen; there are too
many reasons to keep the stack frames involved (like tracebacks).

A solution that would work for the new API extensions might be to add
an optional expression to the continue statement, which would pass
that value into the iterator using send(). If someone wants to produce
a patch for this we could do it in 2.6 or 3.0.

> 3) str.join should automatically stringify its arguments.

I'm on the fence about this one. In 2.x, a problem is that if a later
object is a unicode string, the earlier objects should be converted
using unicode() instead of str(). But in 3.0 we won't have this. I
suggest that someone write up a patch and then we'll look at how well
it works.

> 5) At one point, I was a big fan of reduce(), untill I realized that 99% of
> my use cases were just variations of str.join() :)
>
> Even so, I've always wondered if it would be possible to invent a
> "comprehension- style" syntax for reduce. I have absolutely no good
> ideas on this one, even though I've been pondering it for years...

There isn't one. But generator expressions actually were invented to
make this more feasible. The sum() builtin (like str().join(), max()
and any() etc.) is an example of an *accumulator* function which takes
an iterable and returns a single value. This pattern is easily
extended to other common accumulator idioms. Beyond that, a for loop
looks attractive...

> 6) [global regex matching state]

I already rejected this in a previous response to a later message in
this thread (trying to squash churn).

PS. IMPORTANT!

You may ask, "why does he ask for patches instead of PEPs suddenly?
why the reversal?"

This is because for some issues, code just speaks so much clearer than
words. The IETF requires working implementations before accepting an
RFC into the standards track. We chose not to do this for PEPs. But I
believe that PEPs written after the code has been written and tested
can be much clearer on corner cases.

We've had several important PEPs accepted recently that had to be
modified extensively after implementation attempts showed either holes
in the specs or choices that were less than optimal from an
implementation POV. (E.g. both PEP 342 and PEP 343 were adjusted after
the implementation.)

Most recently, we had at least half a dozen folks agree that it would
be a good idea to disallow iterating over strings in 3.0. But after
spending no more than an hour and a half of implementation effort I
came to realize that the approach is doomed. Reaching this conclusing
during PEP discussion would have cost much more time.

So, especially for things that I think *may* be worth while, I'm
proposing to write a patch first. The patches should be written againt
the p3yk (sic) branch, BTW.

We should still write PEPs too (unless the feature is so simple that
it can be described in a single line added to PEP 3100). Python 3000
PEPs need to be especially clear on the backwards compatibility
issues.

--
--Guido van Rossum (home page: http://www.python.org/~guido/)