On 4/15/06, Talin <[EMAIL PROTECTED]> 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/) _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
