On 2019-11-03 2:01 p.m., Andrew Barnert wrote:
On Nov 3, 2019, at 15:38, Soni L. <fakedme...@gmail.com> wrote:
>> > Or, C#'s throw is allowed in certain specific contexts (lambda bodies and conditional expressions) without being a general expression.
>> Just like, e.g., yield_expr is allowed in assignment statements without being a general expression, and generator_expr is allowed in a call with one arg without being a general expression. Obviously neither of those makes sense for raise (not that it would be ambiguous there, just that it would nearly always be completely useless), but maybe there are places that are, maybe including the same ones as in C#.
>
> counter-argument: foo = raise NIY
What is that a counter-argument to? The fact that it would nearly always be
completely useless to assign a raise?
I don’t know what NIY means here, but why couldn’t you write this as `raise
NIY`? Obviously nothing is getting assigned to `foo`.
If this is part of some rare but occasionally useful idiom where you’re, say,
forcing `foo` to be a local rather than a global by assigning to it, then I
think having to write it as `foo = (raise NIY)` seems reasonable.
At any rate, as I said, if it turns out that there are useful places to allow a
bare raise expression, and those places aren’t human- or parser-ambiguous, it’s
easy to add them later. If people are writing `foo = (raise NIY)` and finding
that the parens are often more confusing or intrusive than they are helpful,
they’ll complain, and the next version of Python will change assignment
statements to handle raise_expr just like they handle yield_expr. (Or, if
someone can make that case even without waiting for experience, it’ll come up
while bikeshedding a raise_expr PEP and can be added even in the initial
version.)
That was meant to be NYI (Not Yet Implemented), sorry. (feel free to
treat "NIY" as "Not Implemented Yet" :P)
It seems useful to me to have the local declared but not defined,
because you haven't got around to implementing what it calls/etc, but
you still know what to do with it. I generally tend to just `foo =
None`, but then you run the risk of that code path actually getting
silently taken and messing up program state. Then you spend hours
debugging what went wrong only to find out what happened.
In Rust, for example, one can do `let foo = unimplemented!();`. Ofc, one
could also do:
def unimplemented():
raise NYI
but having the "raise" in the assignment makes it easier for a human to
process - you can tell from "foo = raise NYI" that it's gonna raise an
error, whereas "foo = unimplemented()" could return a placeholder value
of some sort instead.
_______________________________________________
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/D5MWK5JUFALNEEJIRMKE4LDLEUNGBZIU/
Code of Conduct: http://python.org/psf/codeofconduct/
