E
Eelco Hoogendoorn
Yes, that's just a strict keywordification of the * and ** symbols.
Well, its not quite the same in the sense that algebraic operators are
essentially part of 'natural language', or at least extremely widely
adopted. They have earned their own special symbols. Argument
packing/unpacking is a very specific thing; a small corner of a
particular programming language.
However, as seen in the light of python 3 head-tail syntax, perhaps the
above is not quite true, and one could argue that packing/unpacking of
collections is indeed a quite general concept, deserving of its own
symbols. Breaking uniformity with that use case would also be a bad
thing; ideally, a verbose alternative to all occurances of collection
packing/unpacking would be available.
That said, a more verbose and flexible syntax would be desirable there
too; as of now, the tail is always a list. I havnt read the discussions
leading up to those design decisions, but that seems like a compromise
to me; something like head,tuple(tail) = someiterable would be
preferrable there too, id say
The same argument could be made for eliminating the standard algebraic
+ operator and replacing it with a keyword "__add__". I don't think
that's worthwhile.
Well, its not quite the same in the sense that algebraic operators are
essentially part of 'natural language', or at least extremely widely
adopted. They have earned their own special symbols. Argument
packing/unpacking is a very specific thing; a small corner of a
particular programming language.
However, as seen in the light of python 3 head-tail syntax, perhaps the
above is not quite true, and one could argue that packing/unpacking of
collections is indeed a quite general concept, deserving of its own
symbols. Breaking uniformity with that use case would also be a bad
thing; ideally, a verbose alternative to all occurances of collection
packing/unpacking would be available.
That said, a more verbose and flexible syntax would be desirable there
too; as of now, the tail is always a list. I havnt read the discussions
leading up to those design decisions, but that seems like a compromise
to me; something like head,tuple(tail) = someiterable would be
preferrable there too, id say