3 ms·

On one of the threads, they suggest destructuring syntax. Taking that a bit further and ignoring backwards compatibility entirely: def foo([po1, po2], pk1

by ben509 8y ago

On one of the threads, they suggest destructuring syntax. Taking that a bit further and ignoring backwards compatibility entirely: def foo([po1, po2], pk1, pk2, *args, {kw1, kw2, kwd1=default, kwd2=default, **kw}): pass And it implies some obvious shortcuts: def all_pos_only[po1, po2, po3=default, *args]: pass def all_kw_only{kw1, kw2, kw3=default, **kw}: pass

gizmo385 8y ago
As a fan of Clojure, I would love for Python to get rid of most of strange and archaic (IMO) unpacking syntax and just switch wholesale to Clojure-style destructuring. In my opinion, it's a single solution for all of those problems and it ends up looking a lot cleaner. It's also just a lot easier to work with if you're trying to unpack a single value from a nested structure or define a flexible API.
js2 8y ago
If I ever saw this in real life: foo([po1, po2], pk1, pk2, *args, {kw1, kw2, kwd1=default, kwd2=default, **kw}) I'd think... that function is trying to do too much with its parameters and should be multiple functions. Now yes, I realize an author could already do that with ∗args and ∗∗kwds, but the fact that the author would need to handle the argument parsing is sufficient disincentive to prevent most people from doing so.
- ben509 8y ago
  But if you had to refactor the above function, you wouldn't have to reverse-engineer some argument parsing. You'd know how it must be called anywhere in the project, just by looking. And generally, I think the disincentive rationale is self-defeating: * the premise behind disincentive is you're dealing with someone who is (at least in the moment) careless * now they're going to have to write more code to do a thing they've set out to do * but we've already selected for an individual who is writing carelessly In this case, it can only work if extra argument checks are the last straw that causes this individual to say "enough" and refactor that function. For what my experience is worth, I think this is unlikely.

by ben509 8y ago

gizmo385 8y ago

As a fan of Clojure, I would love for Python to get rid of most of strange and archaic (IMO) unpacking syntax and just switch wholesale to Clojure-style destructuring. In my opinion, it's a single solution for all of those problems and it ends up looking a lot cleaner. It's also just a lot easier to work with if you're trying to unpack a single value from a nested structure or define a flexible API.

js2 8y ago

If I ever saw this in real life: foo([po1, po2], pk1, pk2, *args, {kw1, kw2, kwd1=default, kwd2=default, **kw}) I'd think... that function is trying to do too much with its parameters and should be multiple functions. Now yes, I realize an author could already do that with ∗args and ∗∗kwds, but the fact that the author would need to handle the argument parsing is sufficient disincentive to prevent most people from doing so.

ben509 8y ago
But if you had to refactor the above function, you wouldn't have to reverse-engineer some argument parsing. You'd know how it must be called anywhere in the project, just by looking. And generally, I think the disincentive rationale is self-defeating: * the premise behind disincentive is you're dealing with someone who is (at least in the moment) careless * now they're going to have to write more code to do a thing they've set out to do * but we've already selected for an individual who is writing carelessly In this case, it can only work if extra argument checks are the last straw that causes this individual to say "enough" and refactor that function. For what my experience is worth, I think this is unlikely.