We're now up to 66 cherry-picks. 75%+ of those are asyncio changes.
Hopefully I won't have to redo the cherry-picking from scratch again, I
can just pile more picks on top of the ones I've got.
As before you'll find the results here:
http://midwinter.com/~larry/3.4.status/
//arry/
On 2/21/2014 2:06 AM, anju Tiwari wrote:
I have two version of python 2.4 and 2.7.
By default python version is 2.4 . I want to install need to install
some rpm
which needs python 2.7 interpreter. how can I enable 2.7 interpreter for
only those
packages which are requiring python 2.7, I don’t
Greetings, all!
Larry asked me to bring this to PyDev, so here it is.
The issues involved are:
http://bugs.python.org/issue20534 - already in RC1
http://bugs.python.org/issue20653 - hoping to get cherry-picked
Background
==
When I put Enum together, my knowledge of pickle and its
In article 53070a8a.8080...@hastings.org,
Larry Hastings la...@hastings.org wrote:
As before you'll find the results here:
http://midwinter.com/~larry/3.4.status/
Status says that:
eef7899ea7ab Doc: do not rely on checked-out Sphinx toolchain from
svn.python.org anymore
is unmerged,
Am 20.02.2014 02:24, schrieb Stephen J. Turnbull:
[ ... ]
Sure, but it *doesn't* help in knowing which ones are *correctly*
addressed. These *are* ambitious changes; some of the remaining bugs
may be very deep. The obvious fixes may do more harm than good. Ie,
more eyes is (a) mostly a
On 02/21/2014 01:30 AM, Ned Deily wrote:
In article 53070a8a.8080...@hastings.org,
Larry Hastings la...@hastings.org wrote:
As before you'll find the results here:
http://midwinter.com/~larry/3.4.status/
Status says that:
eef7899ea7ab Doc: do not rely on checked-out Sphinx toolchain
On Fri, 21 Feb 2014 00:36:09 -0800
Ethan Furman et...@stoneleaf.us wrote:
Discussion
==
Is there a valid reason to not allow a user to modify how their enums are
pickled?
If not, should we put the change in RC2 / Final? The main reason I'm pushing
for this is that Enum is
2014-02-21 11:06 Larry Hastings napisał(a):
On 02/21/2014 01:30 AM, Ned Deily wrote:
In article 53070a8a.8080...@hastings.org,
Larry Hastings la...@hastings.org wrote:
As before you'll find the results here:
http://midwinter.com/~larry/3.4.status/
Status says that:
On Fri, 21 Feb 2014 02:06:07 -0800
Larry Hastings la...@hastings.org wrote:
Whoopsie! My local branch is actually correct. But! I effectively did
this in my automation:
% hg clone 3.4 python-{time}
% cd python-{time}
% rm -rf .hg* .bzr* .git*
% cd ..
% tar cvfz
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 20:29, Antoine Pitrou solip...@pitrou.net wrote:
On Fri, 21 Feb 2014 00:36:09 -0800
Ethan Furman et...@stoneleaf.us wrote:
Discussion
==
Is there a valid reason to not allow a user to modify how their enums are
pickled?
If not, should we put the change in RC2
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
In article 5307250f.3040...@hastings.org,
Larry Hastings la...@hastings.org wrote:
Whoopsie! My local branch is actually correct. But! I effectively did
this in my automation:
% hg clone 3.4 python-{time}
% cd python-{time}
% rm -rf .hg* .bzr* .git*
% cd ..
% tar
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:22, Rob Cliffe rob.cli...@btinternet.com wrote:
Thanks for looking into this Nick.
I confess I don't entirely understand the technical argument (my
understanding breaks down at the subexpressions can't see the class level
variables, but I don't want to waste anybody's
On Feb 21, 2014, at 12:36 AM, Ethan Furman wrote:
If not, should we put the change in RC2 / Final? The main reason I'm pushing
for this is that Enum is still new, but after 3.4.0 is cut we then have to
deal with backwards compatibility issues.
I concur this should be cherry picked. Let's not
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
Sorry folks, that was meant to go to python-ideas, not python-dev.
I've been so used to the PEP 463 threads being on python-ideas, I
missed that this was the python-dev one :)
Cheers,
Nick.
___
Python-Dev mailing list
Python-Dev@python.org
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
On 22 February 2014 00:59, Chris Angelico ros...@gmail.com wrote:
On Sat, Feb 22, 2014 at 12:53 AM, Nick Coghlan ncogh...@gmail.com wrote:
The deferral currently has this snippet:
In order to ensure compatibility with future versions, ensure that
any consecutive except operators are
On 22 February 2014 00:50, Antoine Pitrou solip...@pitrou.net wrote:
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
On Sat, Feb 22, 2014 at 1:50 AM, Antoine Pitrou solip...@pitrou.net wrote:
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
On Fri, Feb 21, 2014 at 9:49 AM, Eli Bendersky eli...@gmail.com wrote:
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
On Sat, Feb 22, 2014 at 1:03 AM, Eli Bendersky eli...@gmail.com wrote:
Chris, while I also commend you for the comprehensive PEP, I'm -1 on the
proposal, for two main reasons:
1. Many proposals suggest new syntax to gain some succinctness. Each has to
be judged for its own merits, and in this
On Sat, Feb 22, 2014 at 1:22 AM, Rob Cliffe rob.cli...@btinternet.com wrote:
Small point: in one of your examples you give a plug for the PEP note the
DRY improvement.
I would suggest that similarly
perhaps in your Lib/tarfile.py:2198 example you point out the increase
in readability due
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 the only one whose brain has been trained to view a colon in Python
On Sat, Feb 22, 2014 at 2:19 AM, Brett Cannon br...@python.org wrote:
I understand you are arguing that a try expression will lead to people just
doing `something() except Exception: None` or whatever and that people will
simply get lazy and not think about what they are doing with their
On Sat, 22 Feb 2014 02:12:04 +1100
Chris Angelico ros...@gmail.com wrote:
Overbroad exception handling comes in two ways. One is simply catching
Exception or BaseException when a narrower class would be better, and
that's not addressed by this PEP (except insofar as it does not have a
bare
[re: as clause]
On Fri, Feb 21, 2014 at 6:20 AM, Nick Coghlan ncogh...@gmail.com wrote:
It's probably OK to leave it in the deferred section and just note the
difficulty of implementing it in a backwards compatible way, since
we're *not* going to be introducing a closure.
Agreed.
-eric
On Fri, Feb 21, 2014 at 8:12 AM, Chris Angelico ros...@gmail.com wrote:
On Sat, Feb 22, 2014 at 1:50 AM, Antoine Pitrou solip...@pitrou.net wrote:
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,
On Fri, Feb 21, 2014 at 8:19 AM, Brett Cannon br...@python.org wrote:
I understand you are arguing that a try expression will lead to people just
doing `something() except Exception: None` or whatever and that people will
simply get lazy and not think about what they are doing with their
On Fri, Feb 21, 2014 at 8:27 AM, Chris Angelico ros...@gmail.com wrote:
It doesn't need to save a huge number of lines. Just like lambda and
the if/else expression, it's there as a tool - if it makes your code
easier to read, it's a good too, and if it makes it harder, then don't
use it.
And
ACTIVITY SUMMARY (2014-02-14 - 2014-02-21)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open4558 (+34)
closed 27937 (+62)
total 32495 (+96)
Open issues
On Sat, Feb 22, 2014 at 3:46 AM, Eric Snow ericsnowcurren...@gmail.com wrote:
Be sure to capture in the PEP (within reason) a summary of concerns
and rebuttals/acquiescence. Eli's, Brett's, and Antoine's concerns
likely reflect what others are thinking as well. The PEP and its
result will be
On Sat, 22 Feb 2014 02:52:59 +1100
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
On Sat, Feb 22, 2014 at 4:32 AM, Antoine Pitrou solip...@pitrou.net wrote:
value = (expr except Exception then default)
+0.5
But I'm aware it requires reserving then as a keyword, which might
need a prior SyntaxWarning.
There are no instances of then used as a name in the Python stdlib,
I
On Fri, Feb 21, 2014 at 9:32 AM, Antoine Pitrou solip...@pitrou.net wrote:
On Sat, 22 Feb 2014 02:52:59 +1100
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
On 02/20/2014 07:15 PM, Chris Angelico wrote:
PEP: 463
Title: Exception-catching expressions
[snip]
Deferred sub-proposals
==
Multiple except clauses
---
An examination of use-cases shows that this is not needed as often as
it would be with the
Thank you for writing this PEP, Chris. I'm impressed by the
quality of this PEP, and how you handled the discussion on
python-ideas.
I initially liked this idea, however, after reading the PEP
in detail, my vote is: -1 on the current syntax; -1 on the
whole idea.
On 2/20/2014, 10:15 PM, Chris
On 22 February 2014 02:03, Chris Angelico ros...@gmail.com wrote:
Oops, hit the wrong key and sent that half-written.
... and simply require that the statement form be used. But the
whelming opinion of python-dev seems to be in favour of the parens
anyway, and since they give us the
On Fri, Feb 21, 2014 at 7:42 AM, Nick Coghlan ncogh...@gmail.com wrote:
It's a relatively arcane scoping rule that only matters if you have
non-trivial logic at class scope. The vast majority of Python
programmers will never have to care, because they do the typical thing
and their class
Nick Coghlan wrote:
On 21 February 2014 13:15, Chris Angelico ros...@gmail.com wrote:
Generator expressions require parentheses, unless they would be
strictly redundant. Ambiguities with except expressions could be
resolved in the same way, forcing nested except-in-except trees to be
On 2/21/2014 5:06 PM, Greg Ewing wrote:
Nick Coghlan wrote:
On 21 February 2014 13:15, Chris Angelico ros...@gmail.com wrote:
Generator expressions require parentheses, unless they would be
strictly redundant. Ambiguities with except expressions could be
resolved in the same way, forcing
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] except No value if IndexError
since it puts the normal and exceptional values next
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 expressions could be
resolved in the same way,
Nick Coghlan wrote:
As Chris later noted, you likely *could* still implement expression
local name binding for an except expression without a full closure, it
would just be rather difficult.
I'm still not convinced it would be all *that* difficult.
Seems to me it would be semantically
Eli Bendersky wrote:
For instance, it is sometime non-trivial to know which exceptions some
function may throw. When you write a try...raise statement, you think
hard about covering all the bases. In an expression you're unlikely to,
Speak for yourself. I don't think I would put any less
On 02/21/2014 03:29 PM, 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] except No value if IndexError
It does
On 22 February 2014 10:29, Greg Ewing greg.ew...@canterbury.ac.nz 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]
21.02.2014 18:37, Guido van Rossum wrote:
I'm put off by the ':' syntax myself (it looks to me as if someone
forgot a newline somewhere)
As I mentioned at python-ideas I believe that parens neutralize,
at least to some extent, that unfortunate statement-ish flavor
of the colon.
This one has
Chris Angelico wrote:
it wouldn't be that big a deal to completely reject multiple except
clauses and simply require that the
(rest of original post truncated)
Oh, no! The PSU has gotten wind of this proposal and doesn't
like it!
--
Greg
___
On 2/21/2014 3:29 PM, 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] except No value if IndexError
since it
On 02/21/2014 11:04 AM, Yury Selivanov wrote:
On 2/20/2014, 10:15 PM, Chris Angelico wrote:
* list.pop() - no way to return a default
We can fix that in 3.5.
How many are you going to fix? How are you going to fix the routines you
don't control?
* seq[index] - no way to handle a bounds
On Sat, Feb 22, 2014 at 01:15:13PM +1300, Greg Ewing wrote:
Eli Bendersky wrote:
For instance, it is sometime non-trivial to know which exceptions some
function may throw. When you write a try...raise statement, you think
hard about covering all the bases. In an expression you're unlikely
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), but how would it handle nested exceptions?
Hmmm, probably not very well,
On 2/21/2014, 7:42 PM, Ethan Furman wrote:
On 02/21/2014 11:04 AM, Yury Selivanov wrote:
On 2/20/2014, 10:15 PM, Chris Angelico wrote:
* list.pop() - no way to return a default
We can fix that in 3.5.
How many are you going to fix? How are you going to fix the
routines you don't
On 02/21/2014 05:21 PM, Steven D'Aprano wrote:
On Sat, Feb 22, 2014 at 01:15:13PM +1300, Greg Ewing wrote:
With an except expression, it could be written:
result = computation(int(arg)
except ValueError: abort(Invalid int))
Nice example! Except I'd lay the code out a bit better
On Fri, Feb 21, 2014 at 04:42:36PM -0800, Ethan Furman wrote:
This is not just about better handling of [missing] default values, but of
better exception handling. This PEP adds the ability to use a scalpel
instead of a sledge hammer.
Beautifully said!
--
Steven
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 of abort() rather than returning a value.
Yeah, while I was writing
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 different exceptions from
the tried expression with
Hi,
This is my first year in gsoc. I have been working with python and
django from quite a time. One of the Gsoc proposed ideas drew my attention
and i would surely like to work on that.
I would like to work for creating a extension for idle to integrate
PEP8, what are the prerequisites . I
On Fri, Feb 21, 2014 at 6:06 PM, Jan Kaliszewski z...@chopin.edu.pl wrote:
21.02.2014 18:37, Guido van Rossum wrote:
I'm put off by the ':' syntax myself (it looks to me as if someone
forgot a newline somewhere)
As I mentioned at python-ideas I believe that parens neutralize,
at least to
Hi,
2014-02-21 4:15 GMT+01:00 Chris Angelico ros...@gmail.com:
PEP: 463
Title: Exception-catching expressions
Nice PEP. Good luck, it's really hard to modify the language. Be
prepared to get many alternatives, criticisms, and suggestions. Good
luck to handle them :-) Here is mine.
I like the
On Fri, Feb 21, 2014 at 6:48 PM, Yury Selivanov yselivanov...@gmail.com wrote:
This new syntax won't magically fix all the code either.
But it may let people write code like this:
# I'm sorry, I really can't read this.
logging.info(Message shown to user: %s,((cache[k]
except
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 KeyError: f(key)))
# do something with x
... but I don't like when it is
Hi Navneet,
This is my first year in gsoc. I have been working with python and django
from quite a time. One of the Gsoc proposed ideas drew my attention and i
would surely like to work on that.
I would like to work for creating a extension for idle to integrate
PEP8, what are the
On Sat, Feb 22, 2014 at 6:04 AM, Yury Selivanov yselivanov...@gmail.com 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
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, unless they would be
strictly redundant. Ambiguities with except expressions could
On Sat, Feb 22, 2014 at 10:29 AM, Greg Ewing
greg.ew...@canterbury.ac.nz 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]
On Sat, Feb 22, 2014 at 12:10 PM, Glenn Linderman v+pyt...@g.nevcal.com 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
Antoine Pitrou writes:
On Thu, 20 Feb 2014 10:24:16 +0900
Stephen J. Turnbull step...@xemacs.org wrote:
The argument that a read-only, no cherrypicking by committers repo
is nothing but a better tarball is valid, but as I say, AFAICS the
expected gain is pretty marginal. The
On Sat, Feb 22, 2014 at 12:55 PM, Greg Ewing
greg.ew...@canterbury.ac.nz 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
On Sat, Feb 22, 2014 at 1:07 PM, Victor Stinner
victor.stin...@gmail.com 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
On Sat, Feb 22, 2014 at 3:04 PM, Chris Angelico ros...@gmail.com wrote:
On Sat, Feb 22, 2014 at 1:07 PM, Victor Stinner
victor.stin...@gmail.com 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
On 2/21/2014, 10:42 PM, Chris Angelico wrote:
On Sat, Feb 22, 2014 at 6:04 AM, Yury Selivanov yselivanov...@gmail.com 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.
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.
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~
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 think that
On Sat, Feb 22, 2014 at 4:01 PM, Steven D'Aprano st...@pearwood.info 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
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 an
On 2/21/2014 7:57 PM, Chris Angelico wrote:
On Sat, Feb 22, 2014 at 12:10 PM, Glenn Linderman v+pyt...@g.nevcal.com 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
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'] except KeyError:
Victor has asked me to cherry-pick 180e4b678003:
http://bugs.python.org/issue20320 (original issue)
http://hg.python.org/cpython/rev/180e4b678003/ (checkin into trunk)
http://bugs.python.org/issue20646 (cherry-pick request)
This revision changes the rounding behavior of
95 matches
Mail list logo
