3 ms·

I'll disagree with you here. In Python `*` is already a extremely popular symbol for expanding and there's no usage conflict between expand and numeric multipli

I'll disagree with you here. In Python `*` is already a extremely popular symbol for expanding and there's no usage conflict between expand and numeric multiplication. This change gels really nicely with the rest of expand ecosystem. I think it's much more beautiful and convenient than your JS example which in all honesty looks necessary cluttered and ugly.

jakear 6y ago
But there’s no expanding happening here? So why take a token that’s immediately recognizable as either “expanding” or “muliplying-ish” and extend it to mean “or enforcing named parameters and not expanding”? > cluttered and ugly I won’t argue with you about visuals because I don’t think they’re all that important. But, I think it’s undeniable that reusing the same syntactic concepts across different semantic use cases is quite a lot more logically clean & beautiful than introducing new syntax that other HN commenters with past python experience can’t even understand. If someone sees the JS named parameter syntax at a declaration and has any JS experience, they’ll almost certainly figure out what to do - if someone sees the asterisk, even with Python experience, they’ll think “what the heck is this asterisk?” And again, the other commenters on this thread are clear evidence that this is indeed as unintuitive as I describe.
- masklinn 6y ago
  > But there’s no expanding happening here? There's a collection of 0 arguments. the "∗" was introduced specifically as a shortcut for: def foo(a, *ignore, b): if ignore: raise TypeError forgoing the name simply signals to the language that it should collect nothing. It's a logical extension of the assumption that anything which follows `∗arg` is a keyword-only parameter.
- jessedhillon 6y ago
  *args creates a catch-all variadic function parameter called `args` which matches all positional parameters not heretofore assigned * (same operator, without a name following) indicates that no more positional parameters may be matched after this point They are close enough cognitively to warrant reuse IMO.

jakear 6y ago

But there’s no expanding happening here? So why take a token that’s immediately recognizable as either “expanding” or “muliplying-ish” and extend it to mean “or enforcing named parameters and not expanding”? > cluttered and ugly I won’t argue with you about visuals because I don’t think they’re all that important. But, I think it’s undeniable that reusing the same syntactic concepts across different semantic use cases is quite a lot more logically clean & beautiful than introducing new syntax that other HN commenters with past python experience can’t even understand. If someone sees the JS named parameter syntax at a declaration and has any JS experience, they’ll almost certainly figure out what to do - if someone sees the asterisk, even with Python experience, they’ll think “what the heck is this asterisk?” And again, the other commenters on this thread are clear evidence that this is indeed as unintuitive as I describe.

masklinn 6y ago
> But there’s no expanding happening here? There's a collection of 0 arguments. the "∗" was introduced specifically as a shortcut for: def foo(a, *ignore, b): if ignore: raise TypeError forgoing the name simply signals to the language that it should collect nothing. It's a logical extension of the assumption that anything which follows `∗arg` is a keyword-only parameter.
jessedhillon 6y ago
*args creates a catch-all variadic function parameter called `args` which matches all positional parameters not heretofore assigned * (same operator, without a name following) indicates that no more positional parameters may be matched after this point They are close enough cognitively to warrant reuse IMO.