Hi Andy,
What you propose is essentially the "try .. catch .. in" construct as
described for Standard ML in:
https://pdfs.semanticscholar.org/b24a/60f84b296482769bb6752feeb3d93ba6aee8.pdf
Something similar for Clojure is at:
https://github.com/rufoa/try-let
So clearly this is something more peo
On 23.06.2017 03:02, Cameron Simpson wrote:
How about something like this?
try:
val = bah[5]
except IndexError:
# handle your expected exception here
else:
foo(val)
That is the kind of refactor to which I alluded in the paragraph
above. Doing that a lot tends
On 23 June 2017 at 15:20, Sven R. Kunze wrote:
> On 23.06.2017 03:02, Cameron Simpson wrote:
>
>
> How about something like this?
>
>try:
>val = bah[5]
>except IndexError:
># handle your expected exception here
>else:
>foo(val)
>
>
> That is the kind of refactor
Hi Stephan,
On Fri, Jun 23, 2017 at 6:23 AM, Stephan Houben
wrote:
> Hi Andy,
>
> What you propose is essentially the "try .. catch .. in" construct as
> described for Standard ML in:
>
It's not really a proposal. It's existing syntax. I was suggesting a way
to implement the example that would
Everyone, please be upfront when proposing any ideas if you refuse to
implement your own idea yourself. It's implicit that if you have an idea to
discuss here that you are serious enough about it to see it happen, so if
that's not the case then do say so in your first email (obviously if your
circu
On 2017-06-23 09:49, Brett Cannon wrote:
Everyone, please be upfront when proposing any ideas if you refuse to
implement your own idea yourself. It's implicit that if you have an idea
to discuss here that you are serious enough about it to see it happen,
so if that's not the case then do say so i
2017-06-23 17:09 GMT+02:00 Andy Dirnberger :
> It's not really a proposal. It's existing syntax.
Wow! I have been using Python since 1.5.2 and I never knew this.
This is not Guido's famous time machine in action, by any chance?
Guess there's some code to refactor using this construct now...
St
"to put it succinctly" -- IMO we shouldn't discuss features without giving
thought to their implementation.
On Fri, Jun 23, 2017 at 11:28 AM, Brendan Barnwell
wrote:
> On 2017-06-23 09:49, Brett Cannon wrote:
>
>> Everyone, please be upfront when proposing any ideas if you refuse to
>> implement
On Fri, Jun 23, 2017 at 09:29:23AM +1000, Cameron Simpson wrote:
> On 23Jun2017 06:55, Steven D'Aprano wrote:
> >On Thu, Jun 22, 2017 at 10:30:57PM +0200, Sven R. Kunze wrote:
> >>We usually teach our newbies to catch exceptions as narrowly as
> >>possible, i.e. MyModel.DoesNotExist instead of a p
On 23 June 2017 at 19:28, Brendan Barnwell wrote:
> So to put it succinctly, as someone who's found discussion on this list
> interesting and valuable, I think there is value in having discussion about
> "what would Python be like if this idea were implemented" even if we never
> get very far with
+1
I'm quite active in the CoffeeScript community, but am also on a ton of
medication that ultimately means I won't implement much of what I suggest
doing, but the core devs understand the situation well enough to respond
accordingly.
It really does help when people know what they can reasonably
On 24Jun2017 05:02, Steven D'Aprano wrote:
On Fri, Jun 23, 2017 at 09:29:23AM +1000, Cameron Simpson wrote:
On 23Jun2017 06:55, Steven D'Aprano wrote:
>On Thu, Jun 22, 2017 at 10:30:57PM +0200, Sven R. Kunze wrote:
>>We usually teach our newbies to catch exceptions as narrowly as
>>possible, i
On 23Jun2017 11:48, Nick Coghlan wrote:
On 23 June 2017 at 09:29, Cameron Simpson wrote:
This is so common that I actually keep around a special hack:
def prop(func):
''' The builtin @property decorator lets internal AttributeErrors
escape.
While that can support properties t
It has been brought to my attention that some people found this email as
sounding rather angry. I was frustrated (and there is more to this specific
issue than what everyone is seeing publicly), but I didn't meant for it to
come off as angry, and for that I apologize.
On Fri, 23 Jun 2017 at 09:49
On 2017-06-23 23:56, Cameron Simpson wrote:
On 24Jun2017 05:02, Steven D'Aprano wrote:
[snip]
I think the concept of a "shallow exception" is ill-defined, and to the
degree that it is defined, it is *dangerous*: a bug magnet waiting to
strike.
What do you mean by "directly raised from the su
On 23Jun2017 15:59, Paul Moore wrote:
On 23 June 2017 at 15:20, Sven R. Kunze wrote:
On 23.06.2017 03:02, Cameron Simpson wrote:
How about something like this?
try:
val = bah[5]
except IndexError:
# handle your expected exception here
else:
foo(val)
That is the
On 23Jun2017 20:30, Stephan Houben wrote:
2017-06-23 17:09 GMT+02:00 Andy Dirnberger :
It's not really a proposal. It's existing syntax.
Wow! I have been using Python since 1.5.2 and I never knew this.
This is not Guido's famous time machine in action, by any chance?
Guess there's some code t
Cameron Simpson wrote:
Alas, no. It is existing syntax in Standard ML, not in Python.
But Python doesn't need it, because try-except-else covers
the same thing.
--
Greg
___
Python-ideas mailing list
[email protected]
https://mail.python.org/mai
Cameron Simpson wrote:
try:
foo(bah[5])
except IndexError as e:
... infer that there is no bah[5] ...
One can easily want, instead, some kind of "shallow except", which would
catch exceptions only if they were directly raised from the surface
code;
The problem I see with
Cameron Simpson wrote:
A shallow catch would effectively need to mean "the exceptions uppermost
traceback frame referers to one of the program lines in the try/except
suite". Which would work well for lists and other builtin types. And
might be insufficient for a duck-type with python-coded d
On Fri, 23 Jun 2017 at 13:10 Paul Moore wrote:
> On 23 June 2017 at 19:28, Brendan Barnwell wrote:
> > So to put it succinctly, as someone who's found discussion on this list
> > interesting and valuable, I think there is value in having discussion
> about
> > "what would Python be like if this
21 matches
Mail list logo
