(Hi, I'm a first-time poster. I was inspired by Raymond Hettinger's keynote
at PyCon CA to look at new PEPs and comment on them. Hopefully, I'm not
committing any faux-pas in my post!)
1) I don't think this proposal sufficiently handles falsy values.
What is the expected value of x in the following?
x = exists(0) else 1
Since the PEP specifically states that exists() is to check that the input
is not None, as a user, I would expect x == 0. However, from my
interpretation, it appears that the value 0 would still be directly
evaluated for truthiness and we would get x == 1.
I don't fully get what the purpose of __then__ and __else__ are meant to
be, but it seems like instead of this:
type(_lhs).__then__(_lhs) if _lhs else type(_lhs).__else__(_lhs, RHS)
you would want:
LHS if type(_lhs).__then__(_lhs) else RHS
Where __then__ returns a simple True/False result. (Maybe the name __then__
doesn't make sense in that case.)
2) My initial reaction was that `else` doesn't belong in an expression, but
I guess there's already precedent for that. (I actually wasn't aware of the
`x if y else z` expression until I read this PEP!)
I'm already not a fan of the overloading of else in the cases of for/else
and try/else. (Are there other uses? It's a hard thing to search on
Google...) Now, we're going to have `else`s that aren't anchored to other
statements. You've always known that an `else` belonged to the preceding
if/for/try at the same level of indentation. (Or in the same expression.)
Is there a chance of a missing colon silently changing the meaning of code?
if foo():
a = 1
else
bar()
(Probably not...)
Are two missing spaces too outrageous?
x = yiffoo() else bar()
I'm not 100% sure, but I think that a current parser would see that as a
syntax error very early, as opposed to having to wait for it to try to find
'yiffoo' at run-time.
3) Towards the end, you propose some very Perl-like syntax:
print(some_expensive_query()) if verbosity > 2
This seems completely unrelated to the rest of the PEP, and will likely
invite people to propose an `unless` operator if implemented. (Followed by
an `until` statement.) :)
While it does read more naturally like English, it seems superfluous in a
programming language.
4) The proposal shows how it fixes some common pain points:
value = missing(obj) else obj.field.of.interest
value = missing(obj) else obj["field"]["of"]["interest"]
But it doesn't address very similar ones:
missing(obj) else missing(obj.field) else missing(obj.field.of) else
obj.field.of.interest
obj.get('field', {}).get('of', {}).get('interest')
(The first example shows how it would be handled with the PEP in its
current state.)
Maybe these are too far out of scope, I'm not sure. They feel very similar
to me though.
I hope these are useful comments and not too nit-picky.
Thanks,
Ryan Fox
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
