Thomas Güttler Lists writes:
> Example:
>
>
> status = backend.transmit_data()
>
> But later you want to add something to the [API's return value].
Common Lisp has this feature. There, it's called "multiple values".
The called function uses a special form that creates a multiple va
Hello,
I'd like to discuss an idea I had to shorten the syntax for the common case of
having a try/except/finally/else block where all of the following conditions
are met:
* There is only one except block, no finally or else
* The exception is not captured in the except block, i.e. `except KeyE
Any discussion of except expressions should reference PEP 463 and respond
to the arguments there.
https://www.python.org/dev/peps/pep-0463/
On Sun, Jan 27, 2019, 3:52 AM Alex Shafer via Python-ideas <
python-ideas@python.org wrote:
> Hello,
>
> I'd like to discuss an idea I had to shorten the sy
Stephen J. Turnbull wrote:
Common Lisp has this feature.
Lua also has something like this, but it's more built-in. The syntax
looks deceptively similar to tuple packing and unpacking in Python,
but it's magical. I wouldn't like to see that kind of magic in
Python.
--
Greg
Aren't the arguments for accepting PEP 463 basically the same as the
arguments for accepting assignment expressions? The current syntax is
painfully verbose and people use inefficient and ad hoc constructions to
get around it. Better to have a language feature to support the way that
people actuall
On Sun, Jan 27, 2019 at 07:21:36PM -0800, Ben Rudiak-Gould wrote:
> If Guido wrote that rejection of PEP 463 then I can't help thinking that he
> changed his perspective between then and PEP 572 and might have
> accepted PEP 463 if it had been proposed more recently.
Maybe, maybe not, but either
On Mon, Jan 28, 2019 at 02:52:54PM +1100, Steven D'Aprano wrote:
> Maybe, maybe not, but either way Michael's advice that any discussion
> about try/except expressions should respond to the points raised in PEP
> 463.
Oops, incomplete sentence... I meant that Michael's advice to respond to
the
Steven D'Aprano writes:
> (By the way, since Guido's retirement as BDFL, any major proposal
> doesn't have to just convince him, but a committee of people (as
> yet unselected).
I don't read the governance PEPs that way, FWIW. A major proposal
needs to convince "Python Dev", as summarized, in
