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 exce
> 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
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
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 ag
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
> 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
_
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
> 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
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 Stroust
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 i
ne Samsung Galaxy.
Message d'origine De : Amber Yust Date
: 06/01/2019 09:07 (GMT+01:00) À : Simon Cc :
python-ideas@python.org Objet : 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
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 ra
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
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)
>
> >>> "in
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")
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)
>
> >>> "inv
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 c
17 matches
Mail list logo