Pythonification of the asterisk-based collection packing/unpacking syntax

Evan Driscoll edriscoll at wisc.edu
Sun Dec 18 14:47:46 EST 2011


On 12/18/2011 2:36, Steven D'Aprano wrote:
> The barrier to new keywords in Python is very high. Not going to
> happen for something that already has perfectly good syntax already
> familiar to Python and Ruby programmers. Might else well try to get C
> and Java to stop using "..." (ellipses).
I agree to some extent; I did say my suggestion was somewhat an effort
in brainstorming. (Though I would point out that, if you accept the
premise of this PEP suggestion, "perfectly good" only sort of applies.)

> The burden is that you complicate the compiler and reduce the pool of 
> useful names available to the programmer. To be useful, the keywords need 
> to be short, meaningful and memorable -- which means they're already used 
> in code, which you will break needlessly.
OTOH, it wouldn't be the first time it was done. For instance, 'with'.

> With operators that otherwise would be illegal, the programmer doesn't 
> need to learn about varargs until they need to. With keywords, the 
> programmer needs to learn "you can't use varargs or kwargs as variable 
> names" practically from day 1.
Yes, but it's not exactly a hard lesson. I can't think of any time where
you'd have ambiguous syntax, so misuse could always produce a good error
message. And keyword highlighting is something that basically all
editors can do well... so unless you're opposed to using an editor more
advanced than Notepad, you'll type in "varargs", it'll turn purple or
whatever, and you'll go "oh that's a keyword."


> So you're not just adding keywords, you're adding new syntax: something 
> which looks like a function call, but isn't a function call.
Well, almost by definition these proposals consider adding syntax.

> I'm going to pose the same question to you I have already posed to Eelco: 
> in your proposal, what happens if the caller has shadowed the list built-
> in? Does argument l become a built-in list, or does it become whatever 
> type list is currently bound to?
>
> Some more questions:
>
> Can varargs accepted arbitrary callables, or only a fixed set of known 
> types?
>
> How does this differ from what can be done with annotations?
These are questions I don't feel I can answer very well. I was giving my
thoughts on what I would do or consider doing with the proposal assuming
the fundamental idea is sound. Whether it should be accepted at all is a
matter for someone else. :-)

Evan


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 552 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/python-list/attachments/20111218/fc64b285/attachment-0001.sig>


More information about the Python-list mailing list