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 do we go from here? I've not made any edits for some time - no > material edits for a good while - how do I request pronouncement? > You start a new email thread asking for pronouncement. Don't be surprised, though, if it is postponed until PyCon since the language summit is 4 weeks away. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Requesting pronouncement on PEP 463: Exception-catching expressions
On Wed, Mar 12, 2014 at 12:10 AM, Chris Angelico wrote: > PEP 463, Exception-catching expressions, is stable and I believe ready > for pronouncement. Drumroll please... > > http://www.python.org/dev/peps/pep-0463/ > > PEP: 463 > Title: Exception-catching expressions > Version: $Revision$ > Last-Modified: $Date$ > Author: Chris Angelico > Status: Draft > Type: Standards Track > Content-Type: text/x-rst > Created: 15-Feb-2014 > Python-Version: 3.5 > Post-History: 20-Feb-2014, 16-Feb-2014 > While I'm +0 on the idea, I'm -1 on the syntax; I just don't like having a colon in an expression. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Requesting pronouncement on PEP 463: Exception-catching expressions
On Thu, Mar 13, 2014 at 2:14 AM, Brett Cannon wrote: > While I'm +0 on the idea, I'm -1 on the syntax; I just don't like having a > colon in an expression. Which is why there are alternatives listed, and the best four of them (including the proposed one) ranked. ChrisA ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Requesting pronouncement on PEP 463: Exception-catching expressions
On Wed, Mar 12, 2014 at 11:16 AM, Chris Angelico wrote: > On Thu, Mar 13, 2014 at 2:14 AM, Brett Cannon wrote: > > While I'm +0 on the idea, I'm -1 on the syntax; I just don't like having > a > > colon in an expression. > > Which is why there are alternatives listed, and the best four of them > (including the proposed one) ranked. > `value = (expr except Exception then default)` would be fine with me. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Requesting pronouncement on PEP 463: Exception-catching expressions
On Mar 12, 2014, at 11:14 AM, Brett Cannon wrote: >While I'm +0 on the idea, I'm -1 on the syntax; I just don't like having a >colon in an expression. I'm -0 on the idea, mostly be cause it's never occurred to me to even need something like this, and because I don't personally think the existing spellings are deficient. It doesn't bother me that we have dict.get() for example. I'd also find the proposed syntax difficult to read if it was used more commonly than traditional try/except. That being said, the colon really bothers me, despite what is written in "Common objections". True, colons are used in places other than suite introduction, but with exception handling, colons *do* introduce a new suite, so its use here is jarring. There may also be tooling issues (e.g. editors, syntax colorizers, parsers, etc.). Anyway, put it on the language summit track and we can have a fun debate. :) -Barryu ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Requesting pronouncement on PEP 463: Exception-catching expressions
On Thu, Mar 13, 2014 at 2:44 AM, Barry Warsaw wrote: > That being said, the colon really bothers me, despite what is written in > "Common objections". True, colons are used in places other than suite > introduction, but with exception handling, colons *do* introduce a new suite, > so its use here is jarring. There may also be tooling issues (e.g. editors, > syntax colorizers, parsers, etc.). Tooling issues should already have been solved for lambda, but if you don't like the colon, go with one of the other options - Brett expressed support for 'then', which makes very good sense (it does require creating a new keyword, but it's a fairly safe one). ChrisA ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Requesting pronouncement on PEP 463: Exception-catching expressions
On 12 March 2014 16:05, Chris Angelico wrote: > Tooling issues should already have been solved for lambda, but if you > don't like the colon, go with one of the other options - Brett > expressed support for 'then', which makes very good sense (it does > require creating a new keyword, but it's a fairly safe one). As a data point, Vim's syntax highlighting works mostly fine out of the box for the "top 4" proposed syntaxes. The keyword versions have minor issues - "then" is not highlighted at all and "pass" is highlighted as "pythonStatement" which is slightly jarring. The punctuation-based variants just don't highlight the ":" or "->" which is fine. Making "then" a keyword in Vim's syntax wouldn't be too hard, you'd probably put it in class "pythonException" along with except, try, finally and raise (which seems a bit odd, but that's actually the only place then is used as a keyword, so it's right). Making "pass" highlight as a statement when used standalone or as an expression keyword in an except would be tricky (i.e., I wouldn't know how to do it :-)) The highlighting issue is jarring enough to put me off the "pass" option. Paul ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Fwd: Requesting pronouncement on PEP 463: Exception-catching expressions
[resending to list] -- Forwarded message -- From: Jeremy Kloth Date: Wed, Mar 12, 2014 at 10:27 AM Subject: Re: [Python-Dev] Requesting pronouncement on PEP 463: Exception-catching expressions To: Chris Angelico On Wed, Mar 12, 2014 at 10:05 AM, Chris Angelico wrote: > Tooling issues should already have been solved for lambda, but if you > don't like the colon, go with one of the other options - Brett > expressed support for 'then', which makes very good sense (it does > require creating a new keyword, but it's a fairly safe one). Just to note, if a token is desired, it could be treated as a pseudo-keyword much like 'as' was prior to 2.6 (or 2.5 with future 'with_statement'). That is, it is only treated as a keyword when parsing the expression defining its use. With that, the list of available "keywords" becomes much broader. -- Jeremy Kloth ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Requesting pronouncement on PEP 463: Exception-catching expressions
On 12 March 2014 15:21, Brett Cannon wrote: > > > > On Wed, Mar 12, 2014 at 11:16 AM, Chris Angelico wrote: > >> On Thu, Mar 13, 2014 at 2:14 AM, Brett Cannon wrote: >> > While I'm +0 on the idea, I'm -1 on the syntax; >> > > I just don't like having a >> > colon in an expression. >> > lambda: is an expression and has a colon in it. It would be weird to use except: without a colon IMHO, because we are already used to write except: with colon everywhere else... Which is why there are alternatives listed, and the best four of them >> (including the proposed one) ranked. >> > > `value = (expr except Exception then default)` would be fine with me. > Do we really need to introduce a new keyword 'then' ? I'm +1 on the original proposal (expr except Exception: default) -- Gustavo J. A. M. Carneiro Gambit Research "The universe is always one step beyond logic." -- Frank Herbert ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Requesting pronouncement on PEP 463: Exception-catching expressions
On Tue, Mar 11, 2014 at 9:10 PM, Chris Angelico wrote: > PEP 463, Exception-catching expressions, is stable and I believe ready > for pronouncement. Drumroll please... > > http://www.python.org/dev/peps/pep-0463/ > > PEP: 463 > Title: Exception-catching expressions > Version: $Revision$ > Last-Modified: $Date$ > Author: Chris Angelico > Status: Draft > Type: Standards Track > Content-Type: text/x-rst > Created: 15-Feb-2014 > Python-Version: 3.5 > Post-History: 20-Feb-2014, 16-Feb-2014 > > > Abstract > > > 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. > I want to reject this PEP. I think the proposed syntax is acceptable given the desired semantics, although it's still a bit jarring. It's probably no worse than the colon used with lambda (which echoes the colon used in a def just like the colon here echoes the one in a try/except) and definitely better than the alternatives listed. But the thing I can't get behind are the motivation and rationale. I don't think that e.g. dict.get() would be unnecessary once we have except expressions, and I disagree with the position that EAFP is better than LBYL, or "generally recommended" by Python. (Where do you get that? From the same sources that are so obsessed with DRY they'd rather introduce a higher-order-function than repeat one line of code? :-) This is probably the most you can get out of me as far as a pronouncement. Given that the language summit is coming up I'd be happy to dive deeper in my reasons for rejecting it there (if there's demand). I do think that (apart from never explaining those dreadful acronyms :-) this was a well-written and well-researched PEP, and I think you've done a great job moderating the discussion, collecting objections, reviewing alternatives, and everything else that is required to turn a heated debate into a PEP. Well done Chris (and everyone who helped), and good luck with your next PEP! -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Why not make frames? [was: Alternative forms [was: PEP 463: Exception-catching expressions]]
On Mon, 10 Mar 2014 14:26:14 +1100, Chris Angelico wrote: > On Mon, Mar 10, 2014 at 1:16 PM, Jim J. Jewett wrote: > > I don't claim that syntax is perfect. I do think it is less flawed > > than the no-parentheses (or external parentheses) versions: > > > > (expr1 except expr3 if expr2) > > expr1 except expr3 if expr2 > > > > because the tigher parentheses correctly indicate that expr2 and expr3 > > should be considered as a (what-to-do-in-case-of-error) group, which > > interacts (as a single unit) with the main expression. > > But it doesn't, really. The entire set of three expressions is a > single unit. You can't break out the bit inside the parens and give > that a name, like you can in most places where something "acts as a > single unit" to interact with something else. (Yes, there are special > cases, like the syntax for constructing slice objects that works only > inside square brackets. And you can't break out a function's > arguments, as a unit, into a single object (the nearest is > *args,**kw). I said most places, and I don't want to add more to the > special-case set.) Actually, function arguments almost aren't a special case any more: >>> import inspect >>> def a(a, b=2): ...print(a, b) ... >>> def b(c, d=3): ...print(c, d) ... >>> sa = inspect.signature(a) >>> print(sa) (a, b=2) >>> ba = sa.bind(1, 2) >>> b(*ba.args, **ba.kwargs) 1 2 Note: I said *almost* :) But the point is that we found that the fact that we couldn't give this thing in parens a name bothersome enough to partially fix it. --David ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Requesting pronouncement on PEP 463: Exception-catching expressions
On 03/12/2014 10:09 AM, Guido van Rossum wrote: I want to reject this PEP. [...] But the thing I can't get behind are the motivation and rationale. I don't think that e.g. dict.get() would be unnecessary once we have except expressions, and I disagree with the position that EAFP is better than LBYL [...] Does this mean a better motivation and rationale may cause you to change your mind? My motivation is for simpler, easier to read code: instead of a full-blown try/except block or a double-lookup into an indexable object I would much rather do: self.date = text_to_date(date, 'mdy') except ValueError: batch_date instead of: try: self.date = text_to_date(date, 'mdy') except ValueError: self.date = batch_date This is probably the most you can get out of me as far as a pronouncement. Given that the language summit is coming up I'd be happy to dive deeper in my reasons for rejecting it there (if there's demand). I would like to know, but I won't be at the language summit. I can wait until after, though -- I know time is in especially short supply until then. -- ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Requesting pronouncement on PEP 463: Exception-catching expressions
On Mar 12, 2014, at 10:40 AM, Ethan Furman wrote: >Does this mean a better motivation and rationale may cause you to change your >mind? > >My motivation is for simpler, easier to read code: instead of a full-blown >try/except block or a double-lookup into an indexable object I would much >rather do: > > self.date = text_to_date(date, 'mdy') except ValueError: batch_date > >instead of: > > try: > self.date = text_to_date(date, 'mdy') > except ValueError: > self.date = batch_date I have to challenge a couple of assertions here. First, that the exception expression is easier to read. I'm not sure it is. I suspect they will tend to be expressed on very long lines, much like ternary expressions are today. PEP 8 then would have you split them across multiple lines, which introduces parentheses or backslashes to accomplish. For ternary expressions, this can get ugly and for me sometimes draws me back to traditional if/else statements. Other times, ternaries can be worth it, but either way, it does (again for me) reduce the readability argument. Interestingly enough, where ternaries are most useful are in the same situations where I think exception expressions would be most useful, in the setting of a variable or attribute to one of two different values. In both branches of the conditional, the left hand side is the same target, and what differs is the value being assigned to the LHS. Looking over exception examples from a large code base, I find it rare (but not nonexistent) that exceptions are used in the same situation. But that could be because I'm so comfortable with .get() and other helpers. Ternary expressions seem more compelling. But there's definitely some overlap, which is perhaps why the colon seems so jarring to me. So the second assertion is that these will be common enough to warrant changing the language. Again, I'm not personally convinced. I echo Guido though: it is a well written PEP, and I commend Chris for navigating the python-dev/python-ideas gauntlet! That's an accomplishment even if the PEP is rejected. Cheers, -Barry ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 here? I've not made any edits for some time - no > material edits for a good while - how do I request pronouncement? 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. You should also add a section on the implementation status; it's unclear (to me) whether the proposed implementation actually matches the specification. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Requesting pronouncement on PEP 463: Exception-catching expressions
On Thu, Mar 13, 2014 at 4:09 AM, Guido van Rossum wrote: > But the thing I can't get behind are the motivation and rationale. I don't > think that e.g. dict.get() would be unnecessary once we have except > expressions, and I disagree with the position that EAFP is better than LBYL, > or "generally recommended" by Python. (Where do you get that? From the same > sources that are so obsessed with DRY they'd rather introduce a > higher-order-function than repeat one line of code? :-) Hmm. Not actually sure where I got it from, except [1] that I've heard it periodically advocated as a way to eliminate race conditions in multitasking situations and such (in the same way that stat-followed-by-open is vulnerable, so instead use try-open-except). > This is probably the most you can get out of me as far as a pronouncement. > Given that the language summit is coming up I'd be happy to dive deeper in > my reasons for rejecting it there (if there's demand). Geography prevents me from being there, but if anyone else asks and the answer can be written down, I'm probably not the only one who would read it with interest. > I do think that (apart from never explaining those dreadful acronyms :-) Hmm, I thought for some reason they were axiomatic Python, like "BDFL" and "IDLE". :) > this was a well-written and well-researched PEP, and I think you've done a > great job moderating the discussion, collecting objections, reviewing > alternatives, and everything else that is required to turn a heated debate > into a PEP. Well done Chris (and everyone who helped), and good luck with > your next PEP! Thanks! And yes, thank you to everyone who offered suggestions, kept the intelligent discussion going (it strayed a bit but never turned into a flame war), and especially to everyone who helped with wording and such. I'm only one person, and what seems patently obvious to me isn't always obvious to someone else. I have to say this PEP has been highly successful even without being accepted. The next time anyone asks, they can be pointed to the PEP, with its list of flawed syntax options. (The most common response, by far, was "Nice idea but I don't like the syntax" - for any syntax proposed.) Plus, it taught me how to use the ast module in research. I don't know when that'll come in handy, but Sherlock Holmes was right - all knowledge comes useful! But I'm not going to devote myself to another PEP *quite* yet. Decimal literals is in need of a champion, but I need to do other things, unless someone's going to employ me to champion PEPs full time :) (Hmm. That would be an interesting job title on the resume.) ChrisA [1] Pun intended. Sorry! ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Requesting pronouncement on PEP 463: Exception-catching expressions
On Thu, Mar 13, 2014 at 7:14 AM, Barry Warsaw wrote: > Interestingly enough, where ternaries are most useful are in the same > situations where I think exception expressions would be most useful, in the > setting of a variable or attribute to one of two different values. In both > branches of the conditional, the left hand side is the same target, and what > differs is the value being assigned to the LHS. > > Looking over exception examples from a large code base, I find it rare (but > not nonexistent) that exceptions are used in the same situation. But that > could be because I'm so comfortable with .get() and other helpers. Ternary > expressions seem more compelling. But there's definitely some overlap, which > is perhaps why the colon seems so jarring to me. When you say "looking over", do you mean with the Mk 1 Human Eyeball, or with the script from my research? https://github.com/Rosuav/ExceptExpr/blob/master/find_except_expr.py If you've used the script and have some stats to offer, I'd love to see them. So far, all I have is the stdlib, which isn't necessarily representative. Bear in mind, there isn't a .get() for every situation. You can use hasattr() in place of AttributeError, which isn't quite the same thing, but most of the OSError-raising APIs don't (as far as I know) offer a way to return a default instead of raising. So even if you do generally use dict.get(), there'll likely be some that the script would catch. ChrisA ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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; the PEP has now been rejected. :) > You should also add a section on the implementation status; it's unclear > (to me) whether the proposed implementation actually matches the > specification. Hmm. I left that sort of comment out, partly because both the proposal and the implementation were fluid. I also had a bit of trouble making everything work, and had to submit some more patches. So I'm not sure what would be counted as the reference implementation. ChrisA ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Requesting pronouncement on PEP 463: Exception-catching expressions
On 3/12/2014 1:44 PM, Chris Angelico wrote: unless someone's going to employ me to champion PEPs full time :) (Hmm. That would be an interesting job title on the resume.) It's available now -- www.pepboys.com :) Emile ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Requesting pronouncement on PEP 463: Exception-catching expressions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/12/2014 04:49 PM, Chris Angelico wrote: > You can use hasattr() in place of AttributeError I use: getattr(subject, attrname, default)? *all the time*. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMg060ACgkQ+gerLs4ltQ70IgCgi2HFt1DRWHaeIlwgjyf1UJiR 1uEAn0+pf2fS+USmesmXtV9O63jA93hq =fLq7 -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Requesting pronouncement on PEP 463: Exception-catching expressions
On Thu, Mar 13, 2014 at 8:37 AM, Tres Seaver wrote: > On 03/12/2014 04:49 PM, Chris Angelico wrote: >> You can use hasattr() in place of AttributeError > > I use: > > getattr(subject, attrname, default)? > > *all the time*. Umm, yeah, that one. Why did I think hasattr was the only way around that? Anyway, that just means I picked a bad example. There are others where you have to go for the full try/except. ChrisA ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Requesting pronouncement on PEP 463: Exception-catching expressions
On 13 March 2014 07:49, Chris Angelico wrote: > > Umm, yeah, that one. Why did I think hasattr was the only way around > that? Anyway, that just means I picked a bad example. There are others > where you have to go for the full try/except. You may have been thinking of item lookup on sequences. Attribute lookup can switch to getattr (at the cost of becoming more opaque to the compiler and static analysers), and mappings can fall back to get(), but there's no such alternative for sequences. Anyway - exemplary work on the PEP, even though Guido remained unconvinced. Not only does it become a useful resource if anyone else comes forward with a similar proposal, it becomes something we can point to and perhaps revisit next time someone asks for implicit exception handling to be added to yet another API :) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
