Re: [Python-Dev] PEP 463: Exception-catching expressions

On Thu, Mar 13, 2014 at 07:54:18AM +1100, Chris Angelico wrote: > On Thu, Mar 13, 2014 at 7:26 AM, "Martin v. Löwis" wrote: > > I think you (or someone) first needs to find a BDFL delegate. > > Traditionally, with syntax changes, there is a good chance that Guido > > doesn't want to delegate at al

Re: [Python-Dev] PEP 463: Exception-catching expressions

On Thu, Mar 13, 2014 at 7:26 AM, "Martin v. Löwis" wrote: > I think you (or someone) first needs to find a BDFL delegate. > Traditionally, with syntax changes, there is a good chance that Guido > doesn't want to delegate at all, so ask him whether he wants to delegate > or not. He beat you to it;

Re: [Python-Dev] PEP 463: Exception-catching expressions

Am 12.03.14 04:58, schrieb Chris Angelico: > On Wed, Mar 12, 2014 at 2:20 PM, Ethan Furman wrote: >> I sure hope this is accepted. I could have used it at least a half-dozen >> times in the last week -- which is more often than I would have used the >> ternary-if! :) > > Where do we go from her

Re: [Python-Dev] PEP 463: Exception-catching expressions

On Tue Mar 11 2014 at 11:59:23 PM, Chris Angelico wrote: > On Wed, Mar 12, 2014 at 2:20 PM, Ethan Furman wrote: > > I sure hope this is accepted. I could have used it at least a half-dozen > > times in the last week -- which is more often than I would have used the > > ternary-if! :) > > Where

Re: [Python-Dev] PEP 463: Exception-catching expressions

On Wed, Mar 12, 2014 at 2:20 PM, Ethan Furman wrote: > I sure hope this is accepted. I could have used it at least a half-dozen > times in the last week -- which is more often than I would have used the > ternary-if! :) Where do we go from here? I've not made any edits for some time - no materi

Re: [Python-Dev] PEP 463: Exception-catching expressions

I sure hope this is accepted. I could have used it at least a half-dozen times in the last week -- which is more often than I would have used the ternary-if! :) -- ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mail

Re: [Python-Dev] PEP 463: Exception-catching expressions

Steven D'Aprano wrote: Return the value for key if key is in the dictionary, else default. If default is not given, it defaults to None, so that this method never raises a KeyError. I think that's supposed to mean that it won't raise KeyError as a result of the key not being in the

Re: [Python-Dev] PEP 463: Exception-catching expressions

On 3/5/2014 8:15 PM, Steven D'Aprano wrote: On Wed, Mar 05, 2014 at 12:57:03PM -0800, Thomas Wouters wrote: On Thu, Feb 27, 2014 at 1:29 PM, Chris Angelico wrote: +Had this facility existed early in Python's history, there would have been +no need to create dict.get() and related methods;

Re: [Python-Dev] PEP 463: Exception-catching expressions

On Wed, Mar 05, 2014 at 12:57:03PM -0800, Thomas Wouters wrote: > On Thu, Feb 27, 2014 at 1:29 PM, Chris Angelico wrote: > > > +Had this facility existed early in Python's history, there would have been > > +no need to create dict.get() and related methods; > > > FWIW, after experimenting and s

Re: [Python-Dev] PEP 463: Exception-catching expressions

On Thu, Mar 6, 2014 at 12:03 PM, Thomas Wouters wrote: > PEP update pushed (changeset 59653081cdf6.) > Thanks for that! ChrisA ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://m

Re: [Python-Dev] PEP 463: Exception-catching expressions

On Wed, Mar 5, 2014 at 4:28 PM, Chris Angelico wrote: > On Thu, Mar 6, 2014 at 7:57 AM, Thomas Wouters wrote: > > All in all I believe I will continue to prefer specific methods for > specific > > use-cases; I'm -0 on the idea of an except-expression, -0 on the syntax > with > > the mandatory pa

Re: [Python-Dev] PEP 463: Exception-catching expressions

On Thu, Mar 6, 2014 at 7:57 AM, Thomas Wouters wrote: > All in all I believe I will continue to prefer specific methods for specific > use-cases; I'm -0 on the idea of an except-expression, -0 on the syntax with > the mandatory parentheses around the whole thing (and so far -1 on any of > the othe

Re: [Python-Dev] PEP 463: Exception-catching expressions

On Thu, Mar 6, 2014 at 7:57 AM, Thomas Wouters wrote: > On Thu, Feb 27, 2014 at 1:29 PM, Chris Angelico wrote: >> >> +Had this facility existed early in Python's history, there would have >> been >> +no need to create dict.get() and related methods; > > > FWIW, after experimenting and some consid

Re: [Python-Dev] PEP 463: Exception-catching expressions

On Thu, Feb 27, 2014 at 1:29 PM, Chris Angelico wrote: > +Had this facility existed early in Python's history, there would have been > +no need to create dict.get() and related methods; FWIW, after experimenting and some consideration I've come to the conclusion that this is incorrect. 'd[k] ex

Re: [Python-Dev] PEP 463: Exception-catching expressions

On Sat, Mar 1, 2014 at 12:24 PM, Glenn Linderman wrote: > You are overlooking that the keyword except provides exactly the connotation > of lazy evaluation, so if this is your only reason for preferring the lambda > syntax, you just erased it :) Statements are always executed sequentially. That's

Re: [Python-Dev] PEP 463: Exception-catching expressions

On 2/28/2014 4:51 AM, Nick Coghlan wrote: The preferred notation in the PEP most resembles the existing lambda use case, with "except" instead of "lambda", an exception handling spec instead of an argument list and an additional leading expression: (expr except Exception: default) Lots of

Re: [Python-Dev] PEP 463: Exception-catching expressions

On Sat, Mar 1, 2014 at 12:24 AM, Nick Coghlan wrote: > Yeah, that works. You may also want to add a "common objections" > section to explicitly cover the "but colons introduce suites" > objection. That would provide a space to explicitly list all of the > current "not introducing a suite" use case

Re: [Python-Dev] PEP 463: Exception-catching expressions

On Fri, Feb 28, 2014 at 11:51 PM, Nick Coghlan wrote: >>> > Are there any other expressions that allow parens around a part of the >>> > expression, without the stuff inside them becoming a completely >>> > separate sub-expression? > > Also generator expressions and most uses of yield or yield fro

Re: [Python-Dev] PEP 463: Exception-catching expressions

On 28 February 2014 23:07, Chris Angelico wrote: > On Fri, Feb 28, 2014 at 11:51 PM, Nick Coghlan wrote: >> So I think that on balance, I actually do prefer your current >> proposal. That said, I do think this is a variant worth discussing >> explicitly in the PEP, if only to remind people that t

Re: [Python-Dev] PEP 463: Exception-catching expressions

On Fri, Feb 28, 2014 at 11:51 PM, Nick Coghlan wrote: > So I think that on balance, I actually do prefer your current > proposal. That said, I do think this is a variant worth discussing > explicitly in the PEP, if only to remind people that there's > definitely precedent for using a colon to sepa

Re: [Python-Dev] PEP 463: Exception-catching expressions

On 28 February 2014 21:46, Chris Angelico wrote: > On Fri, Feb 28, 2014 at 8:30 PM, Glenn Linderman > wrote: >> > Are there any other expressions that allow parens around a part of the >> > expression, without the stuff inside them becoming a completely >> > separate sub-expression? >> >> Sure.

Re: [Python-Dev] PEP 463: Exception-catching expressions

On Fri, Feb 28, 2014 at 8:30 PM, Glenn Linderman wrote: > > Are there any other expressions that allow parens around a part of the > > expression, without the stuff inside them becoming a completely > > separate sub-expression? > > > Sure. Function invocation. You can claim (and it is accurate) t

Re: [Python-Dev] PEP 463: Exception-catching expressions

On Fri, Feb 28, 2014 at 1:30 AM, Glenn Linderman wrote: > > value = expr except ( > Exception1: default1, > Exception2: default2, > Exception3: default3, >) > > except that to get the pairing aspect of some parameters for a function call, > you use = instead of :,

Re: [Python-Dev] PEP 463: Exception-catching expressions

On 2/28/2014 12:41 AM, Chris Angelico wrote: On Fri, Feb 28, 2014 at 6:38 PM, Glenn Linderman wrote: Whereas the current PEP syntax has ambiguity regarding how to interpret a-expr except except-list-b: b-expr except except-list-c: c-expr (does the 2nd except apply to a-expr or b-expr?), without

Re: [Python-Dev] PEP 463: Exception-catching expressions

On Fri, Feb 28, 2014 at 6:38 PM, Glenn Linderman wrote: > Whereas the current PEP syntax has ambiguity regarding how to interpret > a-expr except except-list-b: b-expr except except-list-c: c-expr (does the > 2nd except apply to a-expr or b-expr?), without parentheses, and, as far as > I am concer

Re: [Python-Dev] PEP 463: Exception-catching expressions

On 2/27/2014 7:46 PM, Chris Angelico wrote: On Fri, Feb 28, 2014 at 1:12 PM, Glenn Linderman wrote: Yes. But the point is really the location of the (), sorry if my "nice extension" comment is throwing you off that track. Ah! I see. We touched on this syntax on -ideas, but at the time, the p

Re: [Python-Dev] PEP 463: Exception-catching expressions

On Fri, Feb 28, 2014 at 1:12 PM, Glenn Linderman wrote: > Yes. But the point is really the location of the (), sorry if my "nice > extension" comment is throwing you off that track. Ah! I see. We touched on this syntax on -ideas, but at the time, the proposed syntax didn't have parens around th

Re: [Python-Dev] PEP 463: Exception-catching expressions

On 2/27/2014 3:40 PM, Chris Angelico wrote: On Fri, Feb 28, 2014 at 10:33 AM, Nick Coghlan wrote: On 28 Feb 2014 05:56, "Chris Angelico" wrote: On Fri, Feb 28, 2014 at 6:36 AM, Glenn Linderman wrote: +1 f() except ((TypeError, AttributeError): "No value") is a nice extension to the i

Re: [Python-Dev] PEP 463: Exception-catching expressions

On Fri, Feb 28, 2014 at 10:33 AM, Nick Coghlan wrote: > > On 28 Feb 2014 05:56, "Chris Angelico" wrote: >> >> On Fri, Feb 28, 2014 at 6:36 AM, Glenn Linderman >> wrote: >> > +1 >> > >> > f() except ((TypeError, AttributeError): "No value") >> > >> > is a nice extension to the idea of >> > >>

Re: [Python-Dev] PEP 463: Exception-catching expressions

On 28 Feb 2014 05:56, "Chris Angelico" wrote: > > On Fri, Feb 28, 2014 at 6:36 AM, Glenn Linderman wrote: > > +1 > > > > f() except ((TypeError, AttributeError): "No value") > > > > is a nice extension to the idea of > > > > value = expr except ( > > Exception1: default1, > >

Re: [Python-Dev] PEP 463: Exception-catching expressions

On Fri, Feb 28, 2014 at 8:29 AM, Chris Angelico wrote: > @@ -43,6 +43,34 @@ > > * statistics.mean(data) - no way to handle an empty iterator > > +Had this facility existed early in Python's history, there would have been > +no need to create dict.get() and related methods; the one obvious way to

Re: [Python-Dev] PEP 463: Exception-catching expressions

I've added another utility script to my PEP draft repo: https://github.com/Rosuav/ExceptExpr/blob/master/replace_except_expr.py It's built out of some pretty horrendous hacks, it makes some assumptions about code layout (eg spaces for indentation, and a try/except block never has anything else on

Re: [Python-Dev] PEP 463: Exception-catching expressions

On Fri, Feb 28, 2014 at 6:36 AM, Glenn Linderman wrote: > +1 > > f() except ((TypeError, AttributeError): "No value") > > is a nice extension to the idea of > > value = expr except ( > Exception1: default1, > Exception2: default2, > Exception3: default3, >) > >

Re: [Python-Dev] PEP 463: Exception-catching expressions

On 2/27/2014 4:57 AM, Nick Coghlan wrote: The way I get the colon in the proposed syntax to make sense to my brain is to view it as being more like the colon in a dictionary key:value pair than it is like the one that introduces a suite or the body of a lambda expression: (lst[2] except {In

Re: [Python-Dev] PEP 463: Exception-catching expressions

On 27 February 2014 20:44, Ronald Oussoren wrote: > > On 27 Feb 2014, at 11:09, Chris Angelico wrote: > >> On Thu, Feb 27, 2014 at 7:44 PM, Ronald Oussoren >> wrote: >>> What about (also mentioned in the PEP)? >>> >>> value = (expr except Exception try default) >>> >>> This seems to read nicel

Re: [Python-Dev] PEP 463: Exception-catching expressions

On Thu, Feb 27, 2014 at 9:44 PM, Ronald Oussoren wrote: >> expr except Exception try default # "try" indicates the initial expr, >> not the default > > I didn’t parse the expression this way at all, but quite naturally parsed is > as “use expr, and try using default if expr raises Exception” and

Re: [Python-Dev] PEP 463: Exception-catching expressions

On 27 Feb 2014, at 11:09, Chris Angelico wrote: > On Thu, Feb 27, 2014 at 7:44 PM, Ronald Oussoren > wrote: >> What about (also mentioned in the PEP)? >> >> value = (expr except Exception try default) >> >> This seems to read nicely, although “try” is at a completely different >> position

Re: [Python-Dev] PEP 463: Exception-catching expressions

On Thu, Feb 27, 2014 at 7:44 PM, Ronald Oussoren wrote: > What about (also mentioned in the PEP)? > > value = (expr except Exception try default) > > This seems to read nicely, although “try” is at a completely different > position than it is in the equivalent try statement. > > I like the gene

Re: [Python-Dev] PEP 463: Exception-catching expressions

On 21 Feb 2014, at 16:52, Chris Angelico wrote: > On Sat, Feb 22, 2014 at 1:34 AM, Brett Cannon wrote: >> While I like the general concept, I agree that it looks too much like a >> crunched statement; the use of the colon is a non-starter for me. I'm sure >> I'm not the only one whose brain has

Re: [Python-Dev] PEP 463: Exception-catching expressions

On Tue, Feb 25, 2014 at 11:27 AM, Jim J. Jewett wrote: > This also makes me wonder whether the cost of a subscope > (for exception capture) could be limited to when an > exception actually occurs, and whether that might lower > the cost enough to make the it a good tradeoff. > > def myfunc1(a,

Re: [Python-Dev] PEP 463: Exception-catching expressions

Greg Ewing suggested: >> This version might be more readable: >> >> value = lst[2] except "No value" if IndexError Ethan Furman asked: > It does read nicely, and is fine for the single, non-nested, case > (which is probably the vast majority), but how would > it handle nested exceptions?

Re: [Python-Dev] PEP 463: Exception-catching expressions

Yury Selivanov wrote: > I think the Motivation section is pretty weak. I have normally wished for this when I was (semi- interactively) exploring a weakly structured dataset. Often, I start with a string, split it into something hopefully like records, and then start applying filters and tran

Re: [Python-Dev] PEP 463: Exception-catching expressions

On 22/02/2014 02:08, Glenn Linderman wrote: On 2/21/2014 5:06 PM, Jan Kaliszewski wrote: Or even (still being my favorite): msg = seq[i] except (IndexError: "nothing") This syntax actually has a benefit: the parenthesized syntax after except could become a list, to allow handling diffe

Re: [Python-Dev] PEP 463: Exception-catching expressions

On 21/02/2014 23:36, Ethan Furman wrote: On 02/21/2014 02:26 PM, Eric V. Smith wrote: On 2/21/2014 5:06 PM, Greg Ewing wrote: On 21 February 2014 13:15, Chris Angelico wrote: Generator expressions require parentheses, unless they would be strictly redundant. Ambiguities with except expressi

Re: [Python-Dev] PEP 463: Exception-catching expressions

Some of your points have been answered by others, I'll try to avoid repetition. On 21/02/2014 19:04, Yury Selivanov wrote: [snip] Inconvenience of dict[] raising KeyError was solved by introducing the dict.get() method. And I think that dct.get('a', 'b') is 1000 times better than dct['a'] e

Re: [Python-Dev] PEP 463: Exception-catching expressions

On 22/02/2014 21:26, Tim Delaney wrote: On 23 February 2014 02:29, Nick Coghlan > wrote: On 22 Feb 2014 22:15, "Stephen J. Turnbull" mailto:step...@xemacs.org>> wrote: > Antoine Pitrou writes: > > Chris Angelico mailto:ros...@gmail.com>> wrote:

Re: [Python-Dev] PEP 463: Exception-catching expressions

On Mon, Feb 24, 2014 at 7:51 AM, Ethan Furman wrote: >> Yes. Augmented assignment is still assignment, so a statement. The only >> way to parse that is as >> >> x /= (y except ZeroDivisionError: 1) > > > Well, that is certainly not what I would have expected. I can see that you'd want to have tha

Re: [Python-Dev] PEP 463: Exception-catching expressions

23.02.2014 19:51, Stefan Behnel wrote: I see a risk of interfering with in-place assignment operators, e.g. x /= y except ZeroDivisionError: 1 might not do what one could expect, because (as I assume) it would behave differently from x = x / y except ZeroDivisionError: 1 [snip] Pl

Re: [Python-Dev] PEP 463: Exception-catching expressions

On Mon, Feb 24, 2014 at 6:26 AM, Thomas Wouters wrote: >> I see a risk of interfering with in-place assignment operators, e.g. >> >> x /= y except ZeroDivisionError: 1 >> >> might not do what one could expect, because (as I assume) it would behave >> differently from >> >> x = x / y except

Re: [Python-Dev] PEP 463: Exception-catching expressions

On 02/23/2014 11:26 AM, Thomas Wouters wrote: On Feb 23, 2014 7:52 PM, "Stefan Behnel" mailto:stefan...@behnel.de>> wrote: Chris Angelico, 21.02.2014 04:15: > Just as PEP 308 introduced a means of value-based conditions in an > expression, this system allows exception-based conditions to be us

Re: [Python-Dev] PEP 463: Exception-catching expressions

On Feb 23, 2014 7:52 PM, "Stefan Behnel" wrote: > > Chris Angelico, 21.02.2014 04:15: > > Just as PEP 308 introduced a means of value-based conditions in an > > expression, this system allows exception-based conditions to be used > > as part of an expression. > > [...] > > This currently works:: >

Re: [Python-Dev] PEP 463: Exception-catching expressions

Stefan Behnel, 23.02.2014 19:51: > Cython has typed > assignments, so a straight forward idea would be to handle TypeErrors in > assignments like this: > > cdef str s > s = x except TypeError: str(x) Similar code in Python would be this: from array import array x = array('i', [1,

Re: [Python-Dev] PEP 463: Exception-catching expressions

Chris Angelico, 21.02.2014 04:15: > Just as PEP 308 introduced a means of value-based conditions in an > expression, this system allows exception-based conditions to be used > as part of an expression. > [...] > This currently works:: > > lst = [1, 2, None, 3] > value = lst[2] or "No value

Re: [Python-Dev] PEP 463: Exception-catching expressions

On Sun, 23 Feb 2014, Nick Coghlan wrote: Note that mandatory parentheses means we can duck the precedence question entirely, which I count as another point in favour of requiring them :) Careful, if you take that too far then Python 4 will have to be Scheme. ;-) Isaac Morland

Re: [Python-Dev] PEP 463: Exception-catching expressions

On 23 February 2014 11:11, MRAB wrote: > On 2014-02-23 00:09, Chris Angelico wrote: >> On Sun, Feb 23, 2014 at 11:00 AM, Thomas Wouters >> wrote: >>> On Sat, Feb 22, 2014 at 2:08 AM, Thomas Wouters >>> wrote: (FWIW, I have a working patch without tests that allows all of these, I'

Re: [Python-Dev] PEP 463: Exception-catching expressions

On 2014-02-23 00:09, Chris Angelico wrote: > On Sun, Feb 23, 2014 at 11:00 AM, Thomas Wouters > wrote: >> On Sat, Feb 22, 2014 at 2:08 AM, Thomas Wouters >> wrote: >>> >>> (FWIW, I have a working patch without tests that allows all of >>> these, I'll upload it tonight so people can play with it.

Re: [Python-Dev] PEP 463: Exception-catching expressions

On Sun, Feb 23, 2014 at 11:00 AM, Thomas Wouters wrote: > On Sat, Feb 22, 2014 at 2:08 AM, Thomas Wouters wrote: >> >> (FWIW, I have a working patch without tests that allows all of these, I'll >> upload it tonight so people can play with it. Oh, and FWIW, currently I'm +0 >> on the idea, -0 on t

Re: [Python-Dev] PEP 463: Exception-catching expressions

On Sat, Feb 22, 2014 at 2:08 AM, Thomas Wouters wrote: > > > (FWIW, I have a working patch without tests that allows all of these, I'll > upload it tonight so people can play with it. Oh, and FWIW, currently I'm > +0 on the idea, -0 on the specific syntax.) > http://bugs.python.org/issue20739 is

Re: [Python-Dev] PEP 463: Exception-catching expressions

Antoine Pitrou writes: > Sure, but complaining about inefficiencies without asserting their > significance is not very useful. Since you completely missed the point of my post, I'll explain. I was in no way complaining about inefficiencies. My point was precisely the opposite: to the extent t

Re: [Python-Dev] PEP 463: Exception-catching expressions

"Stephen J. Turnbull" writes: > Ethan Furman writes: > > On 02/21/2014 07:46 PM, Chris Angelico wrote: > > > > > > but not this: > > > > > > value = expr except Exception: default except Exception: default > > > > This should be the way it works. Nothing is gained in readability > > by t

Re: [Python-Dev] PEP 463: Exception-catching expressions

On 23 February 2014 02:29, Nick Coghlan wrote: > On 22 Feb 2014 22:15, "Stephen J. Turnbull" wrote: > > Antoine Pitrou writes: > > > Chris Angelico wrote: > > > > hasattr(x,"y") <-> (x.y or True except AttributeError: False) > > > But it's not the same. hasattr() returns a boolean, not an ar

Re: [Python-Dev] PEP 463: Exception-catching expressions

On 22/02/2014 16:36, Brett Cannon wrote: On Sat, Feb 22, 2014 at 4:13 AM, Antoine Pitrou > wrote: On Fri, 21 Feb 2014 09:37:29 -0800 Guido van Rossum mailto:gu...@python.org>> wrote: > I'm put off by the ':' syntax myself (it looks to me as if someo

Re: [Python-Dev] PEP 463: Exception-catching expressions

On Sat, Feb 22, 2014 at 4:13 AM, Antoine Pitrou wrote: > On Fri, 21 Feb 2014 09:37:29 -0800 > Guido van Rossum wrote: > > I'm put off by the ':' syntax myself (it looks to me as if someone > forgot a > > newline somewhere) but 'then' feels even weirder (it's been hard-coded in > > my brain as me

Re: [Python-Dev] PEP 463: Exception-catching expressions

On Fri, Feb 21, 2014 at 8:41 PM, Greg Ewing wrote: > Ethan Furman wrote: > >> On 02/21/2014 03:29 PM, Greg Ewing wrote: >> >> value = lst[2] except "No value" if IndexError >>> >> >> It does read nicely, and is fine for the single, non-nested, case (which >> is probably the vast majority), bu

Re: [Python-Dev] PEP 463: Exception-catching expressions

On 22 Feb 2014 22:15, "Stephen J. Turnbull" wrote: > > Antoine Pitrou writes: > > On Sat, 22 Feb 2014 22:13:58 +1100 > > Chris Angelico wrote: > > > > hasattr(x,"y") <-> (x.y or True except AttributeError: False) > > > But it's not the same. hasattr() returns a boolean, not an arbitrary > >

Re: [Python-Dev] PEP 463: Exception-catching expressions

On Sat, Feb 22, 2014 at 11:14 PM, Stephen J. Turnbull wrote: > Antoine Pitrou writes: > > On Sat, 22 Feb 2014 22:13:58 +1100 > > Chris Angelico wrote: > > > > hasattr(x,"y") <-> (x.y or True except AttributeError: False) > > > But it's not the same. hasattr() returns a boolean, not an arbitra

Re: [Python-Dev] PEP 463: Exception-catching expressions

On 2/22/2014 6:27 AM, Antoine Pitrou wrote: > On Sat, 22 Feb 2014 22:13:58 +1100 > Chris Angelico wrote: >> Lib/inspect.py:1350: >> return sys._getframe(1) if hasattr(sys, "_getframe") else None >> becomes >> return (sys._getframe(1) except AttributeError: None) > > May hide a bug if sys

Re: [Python-Dev] PEP 463: Exception-catching expressions

Antoine Pitrou writes: > On Sat, 22 Feb 2014 22:13:58 +1100 > Chris Angelico wrote: > > hasattr(x,"y") <-> (x.y or True except AttributeError: False) > But it's not the same. hasattr() returns a boolean, not an arbitrary > value. I think he meant hasattr(x,"y") <-> (x.y and True exce

Re: [Python-Dev] PEP 463: Exception-catching expressions

On sam., 2014-02-22 at 20:54 +0900, Stephen J. Turnbull wrote: > Antoine Pitrou writes: > > On sam., 2014-02-22 at 19:29 +0900, Stephen J. Turnbull wrote: > > > Antoine Pitrou writes: > > > > > > > Well, the only way to know that a key (or attribute) exists is to do > > > > the lookup. What

Re: [Python-Dev] PEP 463: Exception-catching expressions

Antoine Pitrou writes: > On sam., 2014-02-22 at 19:29 +0900, Stephen J. Turnbull wrote: > > Antoine Pitrou writes: > > > > > Well, the only way to know that a key (or attribute) exists is to do > > > the lookup. What else would you suggest? > > > > Do the lookup at the C level (or whatev

Re: [Python-Dev] PEP 463: Exception-catching expressions

On Sat, Feb 22, 2014 at 10:27 PM, Antoine Pitrou wrote: > Yeah, none of these examples makes a convincing case that hasattr() is > useless, IMO. I'm not trying to make the case that it's useless. I'm trying to show that, if it didn't exist, all of these would be written some other way, and the ca

Re: [Python-Dev] PEP 463: Exception-catching expressions

On Sat, 22 Feb 2014 22:13:58 +1100 Chris Angelico wrote: > > > > Well, can you propose the corresponding except-expression? > > It's hard to do hasattr itself without something messy - the best I > can come up with is this: > > hasattr(x,"y") <-> (x.y or True except AttributeError: False) But i

Re: [Python-Dev] PEP 463: Exception-catching expressions

On Sat, Feb 22, 2014 at 9:17 PM, Antoine Pitrou wrote: > On Sat, 22 Feb 2014 21:09:07 +1100 > Chris Angelico wrote: >> On Sat, Feb 22, 2014 at 8:58 PM, Antoine Pitrou wrote: >> > On Sat, 22 Feb 2014 20:29:27 +1100 >> > Chris Angelico wrote: >> >> >> >> Which means that, fundamentally, EAFP is t

Re: [Python-Dev] PEP 463: Exception-catching expressions

On sam., 2014-02-22 at 19:29 +0900, Stephen J. Turnbull wrote: > Antoine Pitrou writes: > > > Well, the only way to know that a key (or attribute) exists is to do > > the lookup. What else would you suggest? > > Do the lookup at the C level (or whatever the implementation language > is) and gen

Re: [Python-Dev] PEP 463: Exception-catching expressions

Antoine Pitrou writes: > Well, the only way to know that a key (or attribute) exists is to do > the lookup. What else would you suggest? Do the lookup at the C level (or whatever the implementation language is) and generate no exception, of course. That's what would make it possibly more effic

Re: [Python-Dev] PEP 463: Exception-catching expressions

On Sat, 22 Feb 2014 21:09:07 +1100 Chris Angelico wrote: > On Sat, Feb 22, 2014 at 8:58 PM, Antoine Pitrou wrote: > > On Sat, 22 Feb 2014 20:29:27 +1100 > > Chris Angelico wrote: > >> > >> Which means that, fundamentally, EAFP is the way to do it. So if PEP > >> 463 expressions had existed from

Re: [Python-Dev] PEP 463: Exception-catching expressions

On Fri, Feb 21, 2014 at 7:46 PM, Chris Angelico wrote: > On Sat, Feb 22, 2014 at 9:06 AM, Greg Ewing > wrote: > > Nick Coghlan wrote: > >> > >> On 21 February 2014 13:15, Chris Angelico wrote: > >> > >>> Generator expressions require parentheses, unless they would be > >>> strictly redundant.

Re: [Python-Dev] PEP 463: Exception-catching expressions

On Sat, Feb 22, 2014 at 8:58 PM, Antoine Pitrou wrote: > On Sat, 22 Feb 2014 20:29:27 +1100 > Chris Angelico wrote: >> >> Which means that, fundamentally, EAFP is the way to do it. So if PEP >> 463 expressions had existed from the beginning, hasattr() probably >> wouldn't have been written - peop

Re: [Python-Dev] PEP 463: Exception-catching expressions

On Sat, 22 Feb 2014 20:29:27 +1100 Chris Angelico wrote: > > Which means that, fundamentally, EAFP is the way to do it. So if PEP > 463 expressions had existed from the beginning, hasattr() probably > wouldn't have been written - people would just use an > except-expression instead. Really? hasa

Re: [Python-Dev] PEP 463: Exception-catching expressions

On Sat, Feb 22, 2014 at 8:20 PM, Antoine Pitrou wrote: > On Sat, 22 Feb 2014 16:12:27 +0900 > "Stephen J. Turnbull" wrote: >> >> Note in support: I originally thought that "get" methods would be more >> efficient, but since Nick pointed out that "haveattr" is implemented >> by catching the except

Re: [Python-Dev] PEP 463: Exception-catching expressions

On Fri, 21 Feb 2014 19:49:20 -0700 Eric Snow wrote: > On Fri, Feb 21, 2014 at 7:07 PM, Victor Stinner > wrote: > >> Consider this example of a two-level cache:: > >> for key in sequence: > >> x = (lvl1[key] except KeyError: (lvl2[key] except KeyError: > >> f(key))) > >> # do

Re: [Python-Dev] PEP 463: Exception-catching expressions

On Sat, 22 Feb 2014 16:12:27 +0900 "Stephen J. Turnbull" wrote: > > Note in support: I originally thought that "get" methods would be more > efficient, but since Nick pointed out that "haveattr" is implemented > by catching the exception (Yikes! LBYL implemented by using EAFP!), I > assume that g

Re: [Python-Dev] PEP 463: Exception-catching expressions

On Sat, 22 Feb 2014 15:57:02 +0900 "Stephen J. Turnbull" wrote: > > try: > interpolable = func(key) > except TypeError: > interpolable = "not a string: %s" % key > except KeyError: > interpolable = "no such key: %s" % key > print("Some message that refers t

Re: [Python-Dev] PEP 463: Exception-catching expressions

On Fri, 21 Feb 2014 09:37:29 -0800 Guido van Rossum wrote: > I'm put off by the ':' syntax myself (it looks to me as if someone forgot a > newline somewhere) but 'then' feels even weirder (it's been hard-coded in > my brain as meaning the first branch of an 'if'). Would 'else' work rather than 't

Re: [Python-Dev] PEP 463: Exception-catching expressions

On 02/21/2014 10:57 PM, Stephen J. Turnbull wrote: Ethan Furman writes: On 02/21/2014 07:46 PM, Chris Angelico wrote: but not this: value = expr except Exception: default except Exception: default This should be the way it works. Nothing is gained in readability by turning a try with multi

Re: [Python-Dev] PEP 463: Exception-catching expressions

Steven D'Aprano writes: > On Fri, Feb 21, 2014 at 02:04:45PM -0500, Yury Selivanov wrote: > > > Inconvenience of dict[] raising KeyError was solved by > > introducing the dict.get() method. And I think that > > > > dct.get('a', 'b') > > > > is 1000 times better than > > > > dct['a'] e

Re: [Python-Dev] PEP 463: Exception-catching expressions

On 2/21/2014 7:57 PM, Chris Angelico wrote: On Sat, Feb 22, 2014 at 12:10 PM, Glenn Linderman wrote: Here's a challenge: There has been a big thread about None versus (SQL) Null. Show how an except: expression can help the DB API more easily convert from using None to using a new Null singleton

Re: [Python-Dev] PEP 463: Exception-catching expressions

Ethan Furman writes: > On 02/21/2014 07:46 PM, Chris Angelico wrote: > > > > but not this: > > > > value = expr except Exception: default except Exception: default > > This should be the way it works. Nothing is gained in readability > by turning a try with multiple except statements into

Re: [Python-Dev] PEP 463: Exception-catching expressions

On Sat, Feb 22, 2014 at 4:01 PM, Steven D'Aprano wrote: > (Chris, I think that ought to go in the motivation section of the PEP.) Added to my draft, and here's the peps diff: diff -r c52a2ae3d98e pep-0463.txt --- a/pep-0463.txt Fri Feb 21 23:27:51 2014 -0500 +++ b/pep-0463.txt Sat Feb 22 16:33:3

Re: [Python-Dev] PEP 463: Exception-catching expressions

On Fri, Feb 21, 2014 at 02:04:45PM -0500, Yury Selivanov wrote: > Inconvenience of dict[] raising KeyError was solved by > introducing the dict.get() method. And I think that > > dct.get('a', 'b') > > is 1000 times better than > > dct['a'] except KeyError: 'b' I don't think it is better. I thi

Re: [Python-Dev] PEP 463: Exception-catching expressions

On 02/21/2014 07:46 PM, Chris Angelico wrote: but not this: value = expr except Exception: default except Exception: default This should be the way it works. Nothing is gained in readability by turning a try with multiple except statements into an expression. -- ~Ethan~ __

Re: [Python-Dev] PEP 463: Exception-catching expressions

On 2/21/2014, 11:22 PM, Chris Angelico wrote: I've added a couple of paragraphs to my draft PEP: https://raw.github.com/Rosuav/ExceptExpr/master/pep-0463.txt If someone could please commit that version to the official repo? Or I can submit a diff against the peps repo if that would be easier.

Re: [Python-Dev] PEP 463: Exception-catching expressions

On 2/21/2014, 10:42 PM, Chris Angelico wrote: On Sat, Feb 22, 2014 at 6:04 AM, Yury Selivanov wrote: * seq[index] - no way to handle a bounds error We can add 'list.get(index, default)' method, similar to 'Mapping.get'. It's far more easier than introducing new syntax. That fixes it for the

Re: [Python-Dev] PEP 463: Exception-catching expressions

On Sat, Feb 22, 2014 at 3:04 PM, Chris Angelico wrote: > On Sat, Feb 22, 2014 at 1:07 PM, Victor Stinner > wrote: >> At the first read, I'm unable to understand this long expression. At >> the second read, I'm still unable to see which instruction will be >> executed first: lvl1[key] or lvl2[key]

Re: [Python-Dev] PEP 463: Exception-catching expressions

On Sat, Feb 22, 2014 at 1:07 PM, Victor Stinner wrote: > At the first read, I'm unable to understand this long expression. At > the second read, I'm still unable to see which instruction will be > executed first: lvl1[key] or lvl2[key]? > > The advantage of the current syntax is that the control f

Re: [Python-Dev] PEP 463: Exception-catching expressions

On Sat, Feb 22, 2014 at 12:55 PM, Greg Ewing wrote: > Steven D'Aprano wrote: > >> result = computation( >> int(arg) except ValueError: abort("Invalid int") >> ) >> >> Actually, not quite so nice as I first thought, since you're relying on >> the side-effects o

Re: [Python-Dev] PEP 463: Exception-catching expressions

On Sat, Feb 22, 2014 at 12:10 PM, Glenn Linderman wrote: > Here's a challenge: There has been a big thread about None versus (SQL) > Null. Show how an except: expression can help the DB API more easily convert > from using None to using a new Null singleton, and you'll have a winner :) Heh! I'm n

Re: [Python-Dev] PEP 463: Exception-catching expressions

On Sat, Feb 22, 2014 at 10:29 AM, Greg Ewing wrote: > Antoine Pitrou wrote: > >>>lst = [1, 2] >>>value = lst[2] except IndexError: "No value" >> >> >> the gain in concision is counterbalanced by a loss in >> readability, > > > This version might be more readable: > >value = lst[2] exce

Re: [Python-Dev] PEP 463: Exception-catching expressions

On Sat, Feb 22, 2014 at 9:06 AM, Greg Ewing wrote: > Nick Coghlan wrote: >> >> On 21 February 2014 13:15, Chris Angelico wrote: >> >>> Generator expressions require parentheses, unless they would be >>> strictly redundant. Ambiguities with except expressions could be >>> resolved in the same way

Re: [Python-Dev] PEP 463: Exception-catching expressions

On Sat, Feb 22, 2014 at 6:04 AM, Yury Selivanov wrote: >> * seq[index] - no way to handle a bounds error > > We can add 'list.get(index, default)' method, similar to > 'Mapping.get'. It's far more easier than introducing new > syntax. That fixes it for the list. Square brackets notation works for

  1   2   >