Re: [Python-Dev] PEP 463: Exception-catching expressions
On Tue Mar 11 2014 at 11:59:23 PM, Chris Angelico ros...@gmail.com wrote: On Wed, Mar 12, 2014 at 2:20 PM, Ethan Furman et...@stoneleaf.us 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 ros...@gmail.com 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 ros...@gmail.com 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 br...@python.org 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 ros...@gmail.com wrote: On Thu, Mar 13, 2014 at 2:14 AM, Brett Cannon br...@python.org 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 ba...@python.org 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 ros...@gmail.com 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 jeremy.kl...@gmail.com Date: Wed, Mar 12, 2014 at 10:27 AM Subject: Re: [Python-Dev] Requesting pronouncement on PEP 463: Exception-catching expressions To: Chris Angelico ros...@gmail.com On Wed, Mar 12, 2014 at 10:05 AM, Chris Angelico ros...@gmail.com 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 br...@python.org wrote: On Wed, Mar 12, 2014 at 11:16 AM, Chris Angelico ros...@gmail.com wrote: On Thu, Mar 13, 2014 at 2:14 AM, Brett Cannon br...@python.org 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 ros...@gmail.com 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 ros...@gmail.com 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 ros...@gmail.com wrote: On Mon, Mar 10, 2014 at 1:16 PM, Jim J. Jewett jimjjew...@gmail.com 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 et...@stoneleaf.us 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 gu...@python.org 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 ba...@python.org 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 mar...@v.loewis.de 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 Designhttp://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 tsea...@palladion.com 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
