On 4/16/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
I actually have half a patch for this (and the keyword-only argument thing, and some other generalizations of *seq and **mapping) lying around. Since it isn't going in before 2.6 anyway, I wasn't planning on doing anything with it until 2.5 is well and done. (I mostly started it to get to know the AST; PEP 308 and 328 have since done the job.) I dunno if I count as an 'old-timer', but I'm sure I can convince some of you real old fogies that it's a good idea. :)
Absolutely a good idea (and also how I've generally done it in the past myself.) Besides, code is easy, a PEP is a heck of a lot of work. It still has to be done, it just won't have to be wasted so often.
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.
I actually have half a patch for this (and the keyword-only argument thing, and some other generalizations of *seq and **mapping) lying around. Since it isn't going in before 2.6 anyway, I wasn't planning on doing anything with it until 2.5 is well and done. (I mostly started it to get to know the AST; PEP 308 and 328 have since done the job.) I dunno if I count as an 'old-timer', but I'm sure I can convince some of you real old fogies that it's a good idea. :)
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.
Absolutely a good idea (and also how I've generally done it in the past myself.) Besides, code is easy, a PEP is a heck of a lot of work. It still has to be done, it just won't have to be wasted so often.
--
Thomas Wouters <[EMAIL PROTECTED]>
Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
_______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
