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 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
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
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
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
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
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
On Thu, Feb 27, 2014 at 1:29 PM, Chris Angelico ros...@gmail.com 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
On Thu, Mar 6, 2014 at 7:57 AM, Thomas Wouters tho...@python.org wrote:
On Thu, Feb 27, 2014 at 1:29 PM, Chris Angelico ros...@gmail.com 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
On Thu, Mar 6, 2014 at 7:57 AM, Thomas Wouters tho...@python.org 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
On Wed, Mar 5, 2014 at 4:28 PM, Chris Angelico ros...@gmail.com wrote:
On Thu, Mar 6, 2014 at 7:57 AM, Thomas Wouters tho...@python.org 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
On Thu, Mar 6, 2014 at 12:03 PM, Thomas Wouters tho...@python.org 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
On Wed, Mar 05, 2014 at 12:57:03PM -0800, Thomas Wouters wrote:
On Thu, Feb 27, 2014 at 1:29 PM, Chris Angelico ros...@gmail.com 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
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 ros...@gmail.com wrote:
+Had this facility existed early in Python's history, there would have been
+no need to create dict.get() and
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
On Fri, Feb 28, 2014 at 6:38 PM, Glenn Linderman v+pyt...@g.nevcal.com 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
On 2/28/2014 12:41 AM, Chris Angelico wrote:
On Fri, Feb 28, 2014 at 6:38 PM, Glenn Linderman v+pyt...@g.nevcal.com 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
On Fri, Feb 28, 2014 at 1:30 AM, Glenn Linderman v+pyt...@g.nevcal.comwrote:
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 =
On Fri, Feb 28, 2014 at 8:30 PM, Glenn Linderman v+pyt...@g.nevcal.com 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
On 28 February 2014 21:46, Chris Angelico ros...@gmail.com wrote:
On Fri, Feb 28, 2014 at 8:30 PM, Glenn Linderman v+pyt...@g.nevcal.com
wrote:
Are there any other expressions that allow parens around a part of the
expression, without the stuff inside them becoming a completely
separate
On Fri, Feb 28, 2014 at 11:51 PM, Nick Coghlan ncogh...@gmail.com 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
On 28 February 2014 23:07, Chris Angelico ros...@gmail.com wrote:
On Fri, Feb 28, 2014 at 11:51 PM, Nick Coghlan ncogh...@gmail.com 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
On Fri, Feb 28, 2014 at 11:51 PM, Nick Coghlan ncogh...@gmail.com 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
On Sat, Mar 1, 2014 at 12:24 AM, Nick Coghlan ncogh...@gmail.com 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
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
On Sat, Mar 1, 2014 at 12:24 PM, Glenn Linderman v+pyt...@g.nevcal.com 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
On 21 Feb 2014, at 16:52, Chris Angelico ros...@gmail.com wrote:
On Sat, Feb 22, 2014 at 1:34 AM, Brett Cannon br...@python.org 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
On Thu, Feb 27, 2014 at 7:44 PM, Ronald Oussoren ronaldousso...@mac.com 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.
On 27 Feb 2014, at 11:09, Chris Angelico ros...@gmail.com wrote:
On Thu, Feb 27, 2014 at 7:44 PM, Ronald Oussoren ronaldousso...@mac.com
wrote:
What about (also mentioned in the PEP)?
value = (expr except Exception try default)
This seems to read nicely, although “try” is at a
On Thu, Feb 27, 2014 at 9:44 PM, Ronald Oussoren ronaldousso...@mac.com 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
On 27 February 2014 20:44, Ronald Oussoren ronaldousso...@mac.com wrote:
On 27 Feb 2014, at 11:09, Chris Angelico ros...@gmail.com wrote:
On Thu, Feb 27, 2014 at 7:44 PM, Ronald Oussoren ronaldousso...@mac.com
wrote:
What about (also mentioned in the PEP)?
value = (expr except Exception
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
On Fri, Feb 28, 2014 at 6:36 AM, Glenn Linderman v+pyt...@g.nevcal.com 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,
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 Fri, Feb 28, 2014 at 8:29 AM, Chris Angelico ros...@gmail.com 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
On 28 Feb 2014 05:56, Chris Angelico ros...@gmail.com wrote:
On Fri, Feb 28, 2014 at 6:36 AM, Glenn Linderman v+pyt...@g.nevcal.com
wrote:
+1
f() except ((TypeError, AttributeError): No value)
is a nice extension to the idea of
value = expr except (
Exception1:
On Fri, Feb 28, 2014 at 1:12 PM, Glenn Linderman v+pyt...@g.nevcal.com 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
On 2/27/2014 7:46 PM, Chris Angelico wrote:
On Fri, Feb 28, 2014 at 1:12 PM, Glenn Linderman v+pyt...@g.nevcal.com 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,
On 22/02/2014 21:26, Tim Delaney wrote:
On 23 February 2014 02:29, Nick Coghlan ncogh...@gmail.com
mailto:ncogh...@gmail.com wrote:
On 22 Feb 2014 22:15, Stephen J. Turnbull step...@xemacs.org
mailto:step...@xemacs.org wrote:
Antoine Pitrou writes:
Chris Angelico
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']
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
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
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
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?
With
On Tue, Feb 25, 2014 at 11:27 AM, Jim J. Jewett jimjjew...@gmail.com 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.
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
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
The
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,2,3])
On Feb 23, 2014 7:52 PM, Stefan Behnel 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 used
as part of an expression.
[...]
This currently
On 02/23/2014 11:26 AM, Thomas Wouters wrote:
On Feb 23, 2014 7:52 PM, Stefan Behnel stefan...@behnel.de
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
On Mon, Feb 24, 2014 at 6:26 AM, Thomas Wouters tho...@python.org 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
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]
On Mon, Feb 24, 2014 at 7:51 AM, Ethan Furman et...@stoneleaf.us 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
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
On Sat, 22 Feb 2014 15:57:02 +0900
Stephen J. Turnbull step...@xemacs.org 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
On Fri, 21 Feb 2014 09:37:29 -0800
Guido van Rossum gu...@python.org 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
On Sat, 22 Feb 2014 16:12:27 +0900
Stephen J. Turnbull step...@xemacs.org 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
On Fri, 21 Feb 2014 19:49:20 -0700
Eric Snow ericsnowcurren...@gmail.com wrote:
On Fri, Feb 21, 2014 at 7:07 PM, Victor Stinner
victor.stin...@gmail.com wrote:
Consider this example of a two-level cache::
for key in sequence:
x = (lvl1[key] except KeyError: (lvl2[key] except
On Sat, Feb 22, 2014 at 8:20 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Sat, 22 Feb 2014 16:12:27 +0900
Stephen J. Turnbull step...@xemacs.org wrote:
Note in support: I originally thought that get methods would be more
efficient, but since Nick pointed out that haveattr is implemented
On Sat, 22 Feb 2014 20:29:27 +1100
Chris Angelico ros...@gmail.com 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.
On Sat, Feb 22, 2014 at 8:58 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Sat, 22 Feb 2014 20:29:27 +1100
Chris Angelico ros...@gmail.com wrote:
Which means that, fundamentally, EAFP is the way to do it. So if PEP
463 expressions had existed from the beginning, hasattr() probably
On Fri, Feb 21, 2014 at 7:46 PM, Chris Angelico ros...@gmail.com wrote:
On Sat, Feb 22, 2014 at 9:06 AM, Greg Ewing greg.ew...@canterbury.ac.nz
wrote:
Nick Coghlan wrote:
On 21 February 2014 13:15, Chris Angelico ros...@gmail.com wrote:
Generator expressions require parentheses,
On Sat, 22 Feb 2014 21:09:07 +1100
Chris Angelico ros...@gmail.com wrote:
On Sat, Feb 22, 2014 at 8:58 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Sat, 22 Feb 2014 20:29:27 +1100
Chris Angelico ros...@gmail.com wrote:
Which means that, fundamentally, EAFP is the way to do it. So if
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
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 generate no
On Sat, Feb 22, 2014 at 9:17 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Sat, 22 Feb 2014 21:09:07 +1100
Chris Angelico ros...@gmail.com wrote:
On Sat, Feb 22, 2014 at 8:58 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Sat, 22 Feb 2014 20:29:27 +1100
Chris Angelico ros...@gmail.com
On Sat, 22 Feb 2014 22:13:58 +1100
Chris Angelico ros...@gmail.com 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)
On Sat, Feb 22, 2014 at 10:27 PM, Antoine Pitrou solip...@pitrou.net 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
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 whatever the
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 else would you
Antoine Pitrou writes:
On Sat, 22 Feb 2014 22:13:58 +1100
Chris Angelico ros...@gmail.com 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
On 2/22/2014 6:27 AM, Antoine Pitrou wrote:
On Sat, 22 Feb 2014 22:13:58 +1100
Chris Angelico ros...@gmail.com 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
On Sat, Feb 22, 2014 at 11:14 PM, Stephen J. Turnbull
step...@xemacs.org wrote:
Antoine Pitrou writes:
On Sat, 22 Feb 2014 22:13:58 +1100
Chris Angelico ros...@gmail.com wrote:
hasattr(x,y) - (x.y or True except AttributeError: False)
But it's not the same. hasattr() returns a
On 22 Feb 2014 22:15, Stephen J. Turnbull step...@xemacs.org wrote:
Antoine Pitrou writes:
On Sat, 22 Feb 2014 22:13:58 +1100
Chris Angelico ros...@gmail.com wrote:
hasattr(x,y) - (x.y or True except AttributeError: False)
But it's not the same. hasattr() returns a boolean, not an
On Fri, Feb 21, 2014 at 8:41 PM, Greg Ewing greg.ew...@canterbury.ac.nzwrote:
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
On Sat, Feb 22, 2014 at 4:13 AM, Antoine Pitrou solip...@pitrou.net wrote:
On Fri, 21 Feb 2014 09:37:29 -0800
Guido van Rossum gu...@python.org 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
On 22/02/2014 16:36, Brett Cannon wrote:
On Sat, Feb 22, 2014 at 4:13 AM, Antoine Pitrou solip...@pitrou.net
mailto:solip...@pitrou.net wrote:
On Fri, 21 Feb 2014 09:37:29 -0800
Guido van Rossum gu...@python.org mailto:gu...@python.org wrote:
I'm put off by the ':' syntax
On 23 February 2014 02:29, Nick Coghlan ncogh...@gmail.com wrote:
On 22 Feb 2014 22:15, Stephen J. Turnbull step...@xemacs.org wrote:
Antoine Pitrou writes:
Chris Angelico ros...@gmail.com wrote:
hasattr(x,y) - (x.y or True except AttributeError: False)
But it's not the same.
Stephen J. Turnbull step...@xemacs.org 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
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
On Sat, Feb 22, 2014 at 2:08 AM, Thomas Wouters tho...@python.org 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.)
On Sun, Feb 23, 2014 at 11:00 AM, Thomas Wouters tho...@python.org wrote:
On Sat, Feb 22, 2014 at 2:08 AM, Thomas Wouters tho...@python.org 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
On 2014-02-23 00:09, Chris Angelico wrote:
On Sun, Feb 23, 2014 at 11:00 AM, Thomas Wouters tho...@python.org
wrote:
On Sat, Feb 22, 2014 at 2:08 AM, Thomas Wouters tho...@python.org
wrote:
(FWIW, I have a working patch without tests that allows all of
these, I'll upload it tonight so
On 23 February 2014 11:11, MRAB pyt...@mrabarnett.plus.com wrote:
On 2014-02-23 00:09, Chris Angelico wrote:
On Sun, Feb 23, 2014 at 11:00 AM, Thomas Wouters tho...@python.org
wrote:
On Sat, Feb 22, 2014 at 2:08 AM, Thomas Wouters tho...@python.org
wrote:
(FWIW, I have a working patch
On 21 February 2014 13:15, Chris Angelico ros...@gmail.com wrote:
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
On 21 February 2014 11:35, Nick Coghlan ncogh...@gmail.com wrote:
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.
Great work on this Chris - this is one of the best researched and
On Fri, Feb 21, 2014 at 10:35 PM, Nick Coghlan ncogh...@gmail.com wrote:
On 21 February 2014 13:15, Chris Angelico ros...@gmail.com wrote:
PEP: 463
Title: Exception-catching expressions
Great work on this Chris - this is one of the best researched and
justified Python syntax proposals I've
On Fri, Feb 21, 2014 at 11:37 PM, Paul Moore p.f.mo...@gmail.com wrote:
On 21 February 2014 11:35, Nick Coghlan ncogh...@gmail.com wrote:
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
On 21 February 2014 22:42, Chris Angelico ros...@gmail.com wrote:
It'd be a backward-incompatible change, but it's more likely to be
what people expect. The general assumption of with ... as ... is
that the thing should be used inside the block, and should be finished
with when you exit the
On Fri, 21 Feb 2014 14:15:59 +1100
Chris Angelico ros...@gmail.com wrote:
A number of functions and methods have parameters which will cause
them to return a specified value instead of raising an exception. The
current system is ad-hoc and inconsistent, and requires that each
function be
On 21 February 2014 22:42, Chris Angelico ros...@gmail.com wrote:
People can already write:
if (x if y else z):
without the parens, and it works. Readability suffers when the same
keyword is used twice (here if rather than the colon, but same
difference), yet the parens are considered
My 2 cents worth:
On 21/02/2014 12:42, Chris Angelico wrote:
On Fri, Feb 21, 2014 at 10:35 PM, Nick Coghlan ncogh...@gmail.com wrote:
Great work on this Chris - this is one of the best researched and
justified Python syntax proposals I've seen :)
Hear, hear! (Praise from the praiseworthy is
On 22 February 2014 00:03, Eli Bendersky eli...@gmail.com wrote:
On Thu, Feb 20, 2014 at 7:15 PM, Chris Angelico ros...@gmail.com wrote:
PEP: 463
Title: Exception-catching expressions
Version: $Revision$
Last-Modified: $Date$
Author: Chris Angelico ros...@gmail.com
Status: Draft
Type:
On Fri, Feb 21, 2014 at 8:52 AM, Antoine Pitrou solip...@pitrou.net wrote:
On Fri, 21 Feb 2014 14:15:59 +1100
Chris Angelico ros...@gmail.com wrote:
A number of functions and methods have parameters which will cause
them to return a specified value instead of raising an exception. The
On Fri, Feb 21, 2014 at 6:28 AM, Nick Coghlan ncogh...@gmail.com wrote:
On 22 February 2014 00:03, Eli Bendersky eli...@gmail.com wrote:
On Thu, Feb 20, 2014 at 7:15 PM, Chris Angelico ros...@gmail.com
wrote:
PEP: 463
Title: Exception-catching expressions
Version: $Revision$
On 22 February 2014 00:37, Eli Bendersky eli...@gmail.com wrote:
This goes against anything I understand about how exceptions should and
should not be used.
I think you're thinking of a language that isn't Python - we use
exceptions for control flow all over the place (it's how hasattr() is
On Fri, Feb 21, 2014 at 6:46 AM, Nick Coghlan ncogh...@gmail.com wrote:
On 22 February 2014 00:37, Eli Bendersky eli...@gmail.com wrote:
This goes against anything I understand about how exceptions should and
should not be used.
I think you're thinking of a language that isn't Python - we
On Sat, 22 Feb 2014 00:28:01 +1000
Nick Coghlan ncogh...@gmail.com wrote:
Neither of these objections addresses the problems with the status quo,
though:
- the status quo encourages overbroad exception handling (as
illustrated by examples in the PEP)
I don't get this. Using the proper
On 22 February 2014 00:44, Eli Bendersky eli...@gmail.com wrote:
True, but at least you still have to explicitly try...except... which takes
a toll on the code so isn't taken lightly. Adding except into expressions, I
fear, will proliferate this usage much more.
The same fears were raised
On Sat, Feb 22, 2014 at 12:53 AM, Nick Coghlan ncogh...@gmail.com wrote:
On 21 February 2014 22:42, Chris Angelico ros...@gmail.com wrote:
People can already write:
if (x if y else z):
without the parens, and it works. Readability suffers when the same
keyword is used twice (here if rather
On Sat, Feb 22, 2014 at 1:59 AM, Chris Angelico ros...@gmail.com wrote:
I've spent the better part of the last hour debating this in my head.
It's basically a question of simplicity versus future flexibility:
either keep the syntax clean and deny the multiple-except-clause
option, or mandate
1 - 100 of 161 matches
Mail list logo
