On Wed, Jan 1, 2020, at 21:49, Andrew Barnert wrote:
> On Jan 1, 2020, at 13:23, Random832 <random...@fastmail.com> wrote:
> >
> > Neither of these constructs seems to be particularly useful outside the
> > other one,
>
> Yes, and you already quoted me as saying that.
I think I read "not proposing them separately" as meaning you weren't
submitting two independent proposals, not that they couldn't be used separately
if (both) accepted, and it'd be weird for them not to if they're syntactically
independent like this.
> > which suggests to me they should not be orthogonal in the way you have
> > proposed. Is there a good reason for wanting them to be, or do you just see
> > that as the best way to get a nice looking syntax?
>
> What I’m trying to do is get a nice looking syntax *with the smallest
> possible set of changes*. And I think these are candidates for that set.
>
> I’m not actually proposing either or both at this point.
Yeah, sorry, I used the word "proposing" because I couldn't think of a good
near-synonym that meant something more informal.
Mainly, you had mentioned you felt like "if try" had a 'smell' to it but
couldn't figure out what it is, and I was trying help identify that, and...
well, after thinking about it more, I realized - "if try" may not have many
uses, but "if not try" has a million: any code of the form
try:
x
except:
y
where x is an expression could be written as
if not try x:
y
And therein lies the problem - it's a construct for catching exceptions with no
provision for declaring what kind of exception is caught. You may have only
envisioned it for ValueError, but it'd be weird for something that *looks* so
general to be limited in that way.
Incidentally, it turns out that unpacking with the := operator is syntactically
problematic-- (a, b := 1, 2) is currently equivalent to (a, (b := 1), 2).
Without the outer parentheses it's a syntax error both in an if statement and
otherwise, but I'd find it extremely surprising for adding parentheses to
radically change the meaning in this way if both forms are valid.
I don't want to hijack your thread, but I've thought of something that may be
an alternative. An "as" expression that returns a boolean [and so could be used
as-is with if/while] could be useful for this and for the cases other people
mentioned (ranges, type checking without necessarily requiring an awkward
"type[...]" construct, etc)
Consider something like
if (x, y, z) := vec as ?, 0, ?: # if y == 0
or simply
if tup as ?, <0 # if len(tup) == 2 and tup[1] < 0
If an element in the comparison list is ?, it would not be compared at all. If
it is a type [perhaps any object with an __instancecheck__, to allow ABCs and
perhaps some future effort at algebraic types], it is checked with isinstance.
If it is None, it is checked with `is`. If it is any other object [maybe want a
way to do truthy/falsy checks?] compare with ==. Or an explicit comparison
operator can be used, or two along with a ?-placeholder (a <= ? < b).
What do you think?
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/5U477JJGNNNR2243KKZSXIDQ2LVF6KCN/
Code of Conduct: http://python.org/psf/codeofconduct/
