-
Notifications
You must be signed in to change notification settings - Fork 64
Alternative wildcard #145
Comments
I fully agree with all of it. And let's be clear: this one is not about the question what is objectively the best option, but rather about personal preferences.
I cannot detect any convincing or really grounded argument in any of the points brought forward against the use of Finally, concerning other languages: perhaps we should acknowledge that Python does not exist in empty space. Virtually everyone with at least intermediate coding skills will at the very least have seen other programming languages, maybe even used one. That basically all mainstream programming languages use a common vocabulary including |
Thanks for your points! I think we can explain this one to the SC in person with this. PS: There is one concern with not having wildcards at all: we have a rule disallowing |
It's that thing of being caught between a rock and a hard place, I am afraid: if we allow Don't get me wrong: if allowing |
For reference, an additional reason given for going against |
It's worth noting that (Sorry for intruding here; let me know if you'd rather I stop.) |
I am concerned that "case x, ?:" might look like there can be one or two elements. (Ditto.) |
In the SC-VC we ended up deciding to keep the existing |
I think I meant to label this as rejected (we're keeping |
Several SC members (at least 3) would prefer a different wildcard symbol than
_
, and their preferred symbol is?
.Some of the reasons heard include:
else:
instead ofcase _:
(orcase ?:
for that matter)_ = something(); print(_)
, which would make them believe thatcase _: print(_)
would be valid_
like an alias forgettext
or the last value printed by the REPLHonestly, while I still prefer
_
, I could live with?
if that was needed to get the SC's approval.UPDATE: In defense of copying from other languages: let's not unnecessarily invent where we can easily copy.
The text was updated successfully, but these errors were encountered: