Re: [Python-ideas] Possible PEP regarding the use of the continue keyword in try/except blocks
On 1/7/19 3:38 PM, Barry wrote: > >> On 7 Jan 2019, at 03:06, Richard Damon wrote: >> >> For something like reading options from a config file, I would use a >> call that specifies the key and a value to use if the key isn't present, >> and inside that function I might use a try to handle any exception >> caused when processing the key, and it could return the default. > Most config file APIs I have used have has_section and has_key type functions > that remove the need to catch exceptions. > > What config file API are you using htat is missing this? > > Barry > I was talking about if I was to roll my own, I would start by calling a function I was writing with the key / default value, and it might have a try block so any error that threw an exception would cause it to fall back to the default value. The OP is obviously obviously thinking of something a bit off standard, or he would just be using a standard config reader, and not need this. Maybe the issue is parsing the data from the config line into some internal format, and wanting to catch bad values, like a line that said "nfiles = 42balloons" that throws when it is expecting just a number. -- Richard Damon ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Possible PEP regarding the use of the continue keyword in try/except blocks
> On 7 Jan 2019, at 03:06, Richard Damon wrote: > > For something like reading options from a config file, I would use a > call that specifies the key and a value to use if the key isn't present, > and inside that function I might use a try to handle any exception > caused when processing the key, and it could return the default. Most config file APIs I have used have has_section and has_key type functions that remove the need to catch exceptions. What config file API are you using htat is missing this? Barry ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Possible PEP regarding the use of the continue keyword in try/except blocks
On 1/7/2019 10:15 AM, Chris Angelico wrote: On Mon, Jan 7, 2019 at 11:11 PM Oscar Benjamin wrote: On Mon, 7 Jan 2019 at 09:27, Chris Angelico wrote: On Mon, Jan 7, 2019 at 7:11 PM Anders Hovmöller wrote: This proposal is basically about introducing goto to the language. A bit hyperbolic but I agree that it has the same problem as goto. But the specific suggested solution is not something we should be restricted so rigidly to in this discussion. One could for example see another solution to the same problem: with supress_raise(TypeError, ValueError): do_the_things() I have no idea how to actually implement this though and it's also a bad idea but I think we should first find the best idea to solve the underlying pain point then talk about rejecting or supporting that. You mean like this? https://docs.python.org/3/library/contextlib.html#contextlib.suppress That doesn't do what the OP requested. It suppresses errors from the outside but doesn't resume execution in the block so e.g.: a = b = None with suppress(ValueError): a = float(str_a) b = float(str_b) The OP wants the the b= line to execute even if the a= line raises an exception. True, but what the OP actually asked for is basically impossible. And at least you can write: with suppress(ValueError): a = float(str_a) with suppress(ValueError): b = float(str_b) which is a heap less noisy than the explicit try/except. I think the OP was asking for a construct to automatically wrap every statement in a suppress context manager. Which is probably possible, but I think a bad idea. As a third party solution, maybe some creative AST manipulations could do the trick if someone were so inclined. Eric ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Possible PEP regarding the use of the continue keyword in try/except blocks
On Mon, Jan 7, 2019 at 11:11 PM Oscar Benjamin wrote: > > On Mon, 7 Jan 2019 at 09:27, Chris Angelico wrote: > > > > On Mon, Jan 7, 2019 at 7:11 PM Anders Hovmöller wrote: > > > > > > > > > > This proposal is basically about introducing goto to the language. > > > > > > A bit hyperbolic but I agree that it has the same problem as goto. But > > > the specific suggested solution is not something we should be restricted > > > so rigidly to in this discussion. One could for example see another > > > solution to the same problem: > > > > > > with supress_raise(TypeError, ValueError): > > >do_the_things() > > > > > > I have no idea how to actually implement this though and it's also a bad > > > idea but I think we should first find the best idea to solve the > > > underlying pain point then talk about rejecting or supporting that. > > > > > > > You mean like this? > > > > https://docs.python.org/3/library/contextlib.html#contextlib.suppress > > That doesn't do what the OP requested. It suppresses errors from the > outside but doesn't resume execution in the block so e.g.: > > a = b = None > with suppress(ValueError): > a = float(str_a) > b = float(str_b) > > The OP wants the the b= line to execute even if the a= line raises an > exception. > True, but what the OP actually asked for is basically impossible. And at least you can write: with suppress(ValueError): a = float(str_a) with suppress(ValueError): b = float(str_b) which is a heap less noisy than the explicit try/except. ChrisA ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Possible PEP regarding the use of the continue keyword in try/except blocks
On Mon, 7 Jan 2019 at 09:27, Chris Angelico wrote: > > On Mon, Jan 7, 2019 at 7:11 PM Anders Hovmöller wrote: > > > > > > > This proposal is basically about introducing goto to the language. > > > > A bit hyperbolic but I agree that it has the same problem as goto. But the > > specific suggested solution is not something we should be restricted so > > rigidly to in this discussion. One could for example see another solution > > to the same problem: > > > > with supress_raise(TypeError, ValueError): > >do_the_things() > > > > I have no idea how to actually implement this though and it's also a bad > > idea but I think we should first find the best idea to solve the underlying > > pain point then talk about rejecting or supporting that. > > > > You mean like this? > > https://docs.python.org/3/library/contextlib.html#contextlib.suppress That doesn't do what the OP requested. It suppresses errors from the outside but doesn't resume execution in the block so e.g.: a = b = None with suppress(ValueError): a = float(str_a) b = float(str_b) The OP wants the the b= line to execute even if the a= line raises an exception. -- Oscar ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Possible PEP regarding the use of the continue keyword in try/except blocks
> You mean like this? > > https://docs.python.org/3/library/contextlib.html#contextlib.suppress Hah. Exactly. Maybe that is what the OP wanted in the first place? It's always surprising how much stuff is in the standard lib even after all these years! Thanks for this. / Anders ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Possible PEP regarding the use of the continue keyword in try/except blocks
On Mon, Jan 7, 2019 at 7:11 PM Anders Hovmöller wrote: > > > > This proposal is basically about introducing goto to the language. > > A bit hyperbolic but I agree that it has the same problem as goto. But the > specific suggested solution is not something we should be restricted so > rigidly to in this discussion. One could for example see another solution to > the same problem: > > with supress_raise(TypeError, ValueError): >do_the_things() > > I have no idea how to actually implement this though and it's also a bad idea > but I think we should first find the best idea to solve the underlying pain > point then talk about rejecting or supporting that. > You mean like this? https://docs.python.org/3/library/contextlib.html#contextlib.suppress ChrisA ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Possible PEP regarding the use of the continue keyword in try/except blocks
> This proposal is basically about introducing goto to the language. A bit hyperbolic but I agree that it has the same problem as goto. But the specific suggested solution is not something we should be restricted so rigidly to in this discussion. One could for example see another solution to the same problem: with supress_raise(TypeError, ValueError): do_the_things() I have no idea how to actually implement this though and it's also a bad idea but I think we should first find the best idea to solve the underlying pain point then talk about rejecting or supporting that. / Anders ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Possible PEP regarding the use of the continue keyword in try/except blocks
I think the main issue is this: exception handling is already problematic with its nonlocal transfer of control. Making it bidirectional makes code even more difficult to understand. State will change "under your feet" without any syntactic clue. In "The Design and Evolution of C++" Bjarne Stroustroup quotes an engineer working on a large system using such a feature extensively ; they ended up having to rewrite every single occurrence of it because it introduced a huge amounts of bugs. This is the reason C++ does not support resume semantics. Newer languages go in the direction of avoiding exceptions altogether, not adding more intricate control flow directives. This proposal is basically about introducing goto to the language. Elazar בתאריך יום ב׳, 7 בינו׳ 2019, 5:07, מאת Richard Damon < rich...@damon-family.org>: > On 1/6/19 9:54 PM, simon.bordeyne wrote: > > I knew that you can just chain try/except blocks, and it's how I do it > > now, but the example I provided wasn't very realistic. > > > > Take for example the initialization of a class from a config file, > > config file which may or may not have certain keys in it. With many > > keys, it is very inconvenient to chain try/except blocks to handle > > every possible case. Having the continue keyword would prove useful to > > put several error prone lines of code into a single try block, and > > have the execution continue as normal at tge statement after the > > statement errored out > > > > > For something like reading options from a config file, I would use a > call that specifies the key and a value to use if the key isn't present, > and inside that function I might use a try to handle any exception > caused when processing the key, and it could return the default. > > For your case, it is hard to imagine what you could put in the except > block to handle the error, as you have no idea which key threw the > error, so you have no idea which key needs to be fixed. > > Also, what happens if the exception is thrown inside a function that is > called, do you return to the next line of that function, or the next > line after the function call? > > What happens if the exception happens inside a loop (that is inside the > try)? Do you just go to the next instruction in the loop and continue > looping? > > -- > Richard Damon > > ___ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Possible PEP regarding the use of the continue keyword in try/except blocks
On 1/6/19 9:54 PM, simon.bordeyne wrote: > I knew that you can just chain try/except blocks, and it's how I do it > now, but the example I provided wasn't very realistic. > > Take for example the initialization of a class from a config file, > config file which may or may not have certain keys in it. With many > keys, it is very inconvenient to chain try/except blocks to handle > every possible case. Having the continue keyword would prove useful to > put several error prone lines of code into a single try block, and > have the execution continue as normal at tge statement after the > statement errored out > > For something like reading options from a config file, I would use a call that specifies the key and a value to use if the key isn't present, and inside that function I might use a try to handle any exception caused when processing the key, and it could return the default. For your case, it is hard to imagine what you could put in the except block to handle the error, as you have no idea which key threw the error, so you have no idea which key needs to be fixed. Also, what happens if the exception is thrown inside a function that is called, do you return to the next line of that function, or the next line after the function call? What happens if the exception happens inside a loop (that is inside the try)? Do you just go to the next instruction in the loop and continue looping? -- Richard Damon ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Possible PEP regarding the use of the continue keyword in try/except blocks
There is already a much simpler way of doing this:
> try:
> i = int("string")
> except ValueError as e:
> print(e)
> print("continued on")
> j = int(9.0)
>
> The point of the 'try' block is to encapsulate the code you want to *stop*
> executing if an exception is raised. If you want code to be run regardless
> of whether an exception is raised, move it past the try-except.
>
To be fair, I suspect the issue was there were two calls to int() there
that might raise a ValueError, and the OP wanted to catch them with one
except, so you would need to do somethign like:
try:
i = int("string")
except ValueError as e:
print(e)
print("continued on")
try:
j = int(9.0)
except ValueError as e:
print(e)
Which can seem a bit verbose, but in fact, there are a number of ways one
might want to proceed with/without an error, and the current except,
finally, else options cover them all in a clearly defined way.
-CHB
>
> ~Amber
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR(206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
chris.bar...@noaa.gov
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Possible PEP regarding the use of the continue keyword in try/except blocks
On Sat, Jan 5, 2019 at 4:39 PM Simon wrote:
> I propose to be able to use the continue keyword to continue the execution
> of the try block even when an error is handled. The above could then be
> changed to :
>
>
> try:
> i = int("string")
> print("continued on")
> j = int(9.0)
> except ValueError as e:
> print(e)
> continue
>
> >>> "invalid literal for int() with base 10: 'string'"
> >>> "continued on"
>
There is already a much simpler way of doing this:
try:
i = int("string")
except ValueError as e:
print(e)
print("continued on")
j = int(9.0)
The point of the 'try' block is to encapsulate the code you want to *stop*
executing if an exception is raised. If you want code to be run regardless
of whether an exception is raised, move it past the try-except.
~Amber
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Possible PEP regarding the use of the continue keyword in try/except blocks
On Sun., 6 Jan. 2019, 13:39 Simon
> I was writing some python code earlier, and I noticed that in a code that
> looks somwhat like this one :
>
> try:
> i = int("string")
> print("continued on")
> j = int(9.0)
> except ValueError as e:
> print(e)
>
> >>> "invalid literal for int() with base 10: 'string'"
>
> this code will handle the exception, but the code in the try block will
> not continue.
>
> I propose to be able to use the continue keyword to continue the execution
> of the try block even when an error is handled. The above could then be
> changed to :
>
In terms of implementation, I think continue would be problematic
while true:
try:
x = foo()
return x
except:
continue
is already valid code. You'd need some way of disambiguating, either a
keyword or parameter to continue. Both of which would require a very big
benefit for us to do, given the ecosystem impact that such things have.
> try:
> i = int("string")
> print("continued on")
> j = int(9.0)
> except ValueError as e:
> print(e)
> continue
>
> >>> "invalid literal for int() with base 10: 'string'"
> >>> "continued on"
>
Exception handling is not internally line orientated, so this proposed
resume functionality doesn't map exactly. But if the following in the same
way as what you envision:
def handle(f, *args):
try:
return f(*args)
except ValueError as e:
print(e)
i = handle( int, "string")
handle(print, "continued on")
j = handle(int, 9.0)
Then I have to say I'm not sure what you are trying to solve. Is it the
verbosity? Is it the flow control?
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Possible PEP regarding the use of the continue keyword in try/except blocks
On Sun, Jan 06, 2019 at 01:38:33AM +0100, Simon wrote:
> I propose to be able to use the continue keyword to continue the execution
> of the try block even when an error is handled. The above could then be
> changed to :
>
>
> try:
> i = int("string")
> print("continued on")
> j = int(9.0)
> except ValueError as e:
> print(e)
> continue
>
> >>> "invalid literal for int() with base 10: 'string'"
> >>> "continued on"
That's literally what the except clause is intended for, not the body of
the try block.
try:
i = int("string")
except ValueError as e:
print(e)
print("continued on")
j = int(9.0)
Putting the error handler in the try block is a serious problem for two
reasons:
(1) What if an error *doesn't* occur? The error handler occurs anyway:
try:
i = int("1234") # This succeeds.
# and then immediately runs the error handler... oops!
print("continued on")
j = int(9.0)
except ValueError as e:
print(e)
continue
(2) And what happens if the error handler raises an error? The exception
is raised, the except clause is called, the continue statement jumps
back to the same block of code that just failed and will fail again. And
again. And again. Forever.
--
Steve
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Possible PEP regarding the use of the continue keyword in try/except blocks
On 1/5/19 7:38 PM, Simon wrote:
>
> I was writing some python code earlier, and I noticed that in a code
> that looks somwhat like this one :
>
> try:
> i = int("string")
> print("continued on")
> j = int(9.0)
> except ValueError as e:
> print(e)
>
> >>> "invalid literal for int() with base 10: 'string'"
>
> this code will handle the exception, but the code in the try block
> will not continue.
>
> I propose to be able to use the continue keyword to continue the
> execution of the try block even when an error is handled. The above
> could then be changed to :
>
>
> try:
> i = int("string")
> print("continued on")
> j = int(9.0)
> except ValueError as e:
> print(e)
> continue
>
> >>> "invalid literal for int() with base 10: 'string'"
> >>> "continued on"
>
How would you tell it where to continue? Why would it be the next
statement? If you want that then you just need to do it like:
try:
i = int("string")
except ValueError as e:
print(e)
print("continued on")
j = int(9.0)
i.e. the try block is the program segment that either executes
successful, or your exception routine recovers from the error and sets
things up to continue from there.
--
Richard Damon
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
