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 wa
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 p
In article <53070a8a.8080...@hastings.org>,
Larry Hastings 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, which is what
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 falla
On 02/21/2014 01:30 AM, Ned Deily wrote:
In article <53070a8a.8080...@hastings.org>,
Larry Hastings 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.or
On Fri, 21 Feb 2014 00:36:09 -0800
Ethan Furman 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 still new, b
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 wrote:
> >> As before you'll find the results here:
> >>
> >> http://midwinter.com/~larry/3.4.status/
> > Status says that:
> >
> > eef78
On Fri, 21 Feb 2014 02:06:07 -0800
Larry Hastings 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 python-{tim
On 21 February 2014 13:15, Chris Angelico wrote:
> 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
On 21 February 2014 20:29, Antoine Pitrou wrote:
> On Fri, 21 Feb 2014 00:36:09 -0800
> Ethan Furman 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
On 21 February 2014 11:35, Nick Coghlan 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
> justifie
On Fri, Feb 21, 2014 at 10:35 PM, Nick Coghlan wrote:
> On 21 February 2014 13:15, Chris Angelico 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 seen :)
It is? Wow... I'm not
On Fri, Feb 21, 2014 at 11:37 PM, Paul Moore wrote:
> On 21 February 2014 11:35, Nick Coghlan 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 th
On 21 February 2014 22:42, Chris Angelico 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 block, so hav
In article <5307250f.3040...@hastings.org>,
Larry Hastings 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 pyth
On 21 February 2014 22:42, Chris Angelico wrote:
> On Fri, Feb 21, 2014 at 10:35 PM, Nick Coghlan wrote:
>> On 21 February 2014 13:15, Chris Angelico wrote:
>>> PEP: 463
>>> Title: Exception-catching expressions
>> Great work on this Chris - this is one of the best researched and
>> justified Py
On Fri, 21 Feb 2014 14:15:59 +1100
Chris Angelico 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 individually w
On 21 February 2014 22:42, Chris Angelico 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 optional. Pyt
My 2 cents worth:
On 21/02/2014 12:42, Chris Angelico wrote:
On Fri, Feb 21, 2014 at 10:35 PM, Nick Coghlan 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 praise indeed" -
On 22 February 2014 00:03, Eli Bendersky wrote:
> On Thu, Feb 20, 2014 at 7:15 PM, Chris Angelico wrote:
>>
>> PEP: 463
>> Title: Exception-catching expressions
>> Version: $Revision$
>> Last-Modified: $Date$
>> Author: Chris Angelico
>> Status: Draft
>> Type: Standards Track
>> Content-Type: te
On Fri, Feb 21, 2014 at 8:52 AM, Antoine Pitrou wrote:
> On Fri, 21 Feb 2014 14:15:59 +1100
> Chris Angelico 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 a
On Fri, Feb 21, 2014 at 6:28 AM, Nick Coghlan wrote:
> On 22 February 2014 00:03, Eli Bendersky wrote:
> > On Thu, Feb 20, 2014 at 7:15 PM, Chris Angelico
> wrote:
> >>
> >> PEP: 463
> >> Title: Exception-catching expressions
> >> Version: $Revision$
> >> Last-Modified: $Date$
> >> Author: Chri
On 22 February 2014 00:22, Rob Cliffe 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 time expecting an
> ex
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 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
*defined*, for exa
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
https://mail.p
On Fri, Feb 21, 2014 at 6:46 AM, Nick Coghlan wrote:
> On 22 February 2014 00:37, Eli Bendersky 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
On Sat, 22 Feb 2014 00:28:01 +1000
Nick Coghlan 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 exception class
On 22 February 2014 00:44, Eli Bendersky 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 regarding conditio
On Sat, Feb 22, 2014 at 12:53 AM, Nick Coghlan wrote:
> On 21 February 2014 22:42, Chris Angelico 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
On Sat, Feb 22, 2014 at 1:59 AM, Chris Angelico 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 the parens and
On 22 February 2014 00:59, Chris Angelico wrote:
> On Sat, Feb 22, 2014 at 12:53 AM, Nick Coghlan wrote:
>> The deferral currently has this snippet:
>>
>> """In order to ensure compatibility with future versions, ensure that
>> any consecutive except operators are parenthesized to guarantee the
>
On 22 February 2014 00:50, Antoine Pitrou wrote:
> On Sat, 22 Feb 2014 00:28:01 +1000
> Nick Coghlan 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 th
On Sat, Feb 22, 2014 at 1:50 AM, Antoine Pitrou wrote:
> On Sat, 22 Feb 2014 00:28:01 +1000
> Nick Coghlan wrote:
>>
>> Neither of these objections addresses the problems with the status quo,
>> though:
>>
>> - the status quo encourages overbroad exception handling (as
>> illustrated by examples
On Fri, Feb 21, 2014 at 9:49 AM, Eli Bendersky wrote:
> On Fri, Feb 21, 2014 at 6:46 AM, Nick Coghlan wrote:
>
>> On 22 February 2014 00:37, Eli Bendersky wrote:
>> > This goes against anything I understand about how exceptions should and
>> > should not be used.
>>
>> I think you're thinking o
On Sat, Feb 22, 2014 at 1:03 AM, Eli Bendersky 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 case IMHO t
On Sat, Feb 22, 2014 at 1:22 AM, Rob Cliffe 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 to the 2 lines lini
On Sat, Feb 22, 2014 at 1:34 AM, Brett Cannon wrote:
> While I like the general concept, I agree that it looks too much like a
> crunched statement; the use of the colon is a non-starter for me. I'm sure
> I'm not the only one whose brain has been trained to view a colon in Python
> to mean "state
On Sat, Feb 22, 2014 at 2:19 AM, Brett Cannon 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
> exceptions. Unfort
On Sat, 22 Feb 2014 02:12:04 +1100
Chris Angelico 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 "except:" syn
[re: "as" clause]
On Fri, Feb 21, 2014 at 6:20 AM, Nick Coghlan 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 wrote:
> On Sat, Feb 22, 2014 at 1:50 AM, Antoine Pitrou wrote:
>> On Sat, 22 Feb 2014 00:28:01 +1000
>> Nick Coghlan wrote:
>>>
>>> Neither of these objections addresses the problems with the status quo,
>>> though:
>>>
>>> - the status quo encou
On Fri, Feb 21, 2014 at 8:19 AM, Brett Cannon 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
> exceptions.
Exact
On Fri, Feb 21, 2014 at 8:27 AM, Chris Angelico 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 as long as th
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 wit
On Sat, Feb 22, 2014 at 3:46 AM, Eric Snow 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 better for recording su
On Sat, 22 Feb 2014 02:52:59 +1100
Chris Angelico wrote:
> On Sat, Feb 22, 2014 at 1:34 AM, Brett Cannon wrote:
> > While I like the general concept, I agree that it looks too much like a
> > crunched statement; the use of the colon is a non-starter for me. I'm sure
> > I'm not the only one whos
On Sat, Feb 22, 2014 at 4:32 AM, Antoine Pitrou 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 already chec
On Fri, Feb 21, 2014 at 9:32 AM, Antoine Pitrou wrote:
> On Sat, 22 Feb 2014 02:52:59 +1100
> Chris Angelico wrote:
>
> > On Sat, Feb 22, 2014 at 1:34 AM, Brett Cannon wrote:
> > > While I like the general concept, I agree that it looks too much like a
> > > crunched statement; the use of the c
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 statemen
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 An
On 22 February 2014 02:03, Chris Angelico 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 possibility of futur
On Fri, Feb 21, 2014 at 7:42 AM, Nick Coghlan 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 bodies consist almos
Nick Coghlan wrote:
On 21 February 2014 13:15, Chris Angelico wrote:
Generator expressions require parentheses, unless they would be
strictly redundant. Ambiguities with except expressions could be
resolved in the same way, forcing nested except-in-except trees to be
correctly parenthesized
On 2/21/2014 5:06 PM, Greg Ewing wrote:
> Nick Coghlan wrote:
>> On 21 February 2014 13:15, Chris Angelico wrote:
>>
>>> Generator expressions require parentheses, unless they would be
>>> strictly redundant. Ambiguities with except expressions could be
>>> resolved in the same way, forcing nes
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 ne
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, forc
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 equivalen
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
thoug
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 do
On 22 February 2014 10:29, 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 "N
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 s
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
___
Python-
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 bou
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 unlik
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 con
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 t
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 wit
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 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 some exten
Hi,
2014-02-21 4:15 GMT+01:00 Chris Angelico :
> 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 simple case "e
On Fri, Feb 21, 2014 at 6:48 PM, Yury Selivanov 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 LookupError:
>
On Fri, Feb 21, 2014 at 7:07 PM, Victor Stinner
wrote:
>> Consider this example of a two-level cache::
>> for key in sequence:
>> x = (lvl1[key] except KeyError: (lvl2[key] except KeyError: f(key)))
>> # do something with x
>
> ... but I don't like when it is used to build comp
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 wrote:
>> * seq[index] - no way to handle a bounds error
>
> We can add 'list.get(index, default)' method, similar to
> 'Mapping.get'. It's far more easier than introducing new
> syntax.
That fixes it for the list. Square brackets notation works for
On Sat, Feb 22, 2014 at 9:06 AM, Greg Ewing wrote:
> Nick Coghlan wrote:
>>
>> On 21 February 2014 13:15, Chris Angelico wrote:
>>
>>> Generator expressions require parentheses, unless they would be
>>> strictly redundant. Ambiguities with except expressions could be
>>> resolved in the same way
On Sat, Feb 22, 2014 at 10:29 AM, Greg Ewing
wrote:
> Antoine Pitrou wrote:
>
>>>lst = [1, 2]
>>>value = lst[2] except IndexError: "No value"
>>
>>
>> the gain in concision is counterbalanced by a loss in
>> readability,
>
>
> This version might be more readable:
>
>value = lst[2] exce
On Sat, Feb 22, 2014 at 12:10 PM, Glenn Linderman wrote:
> Here's a challenge: There has been a big thread about None versus (SQL)
> Null. Show how an except: expression can help the DB API more easily convert
> from using None to using a new Null singleton, and you'll have a winner :)
Heh! I'm n
Antoine Pitrou writes:
> On Thu, 20 Feb 2014 10:24:16 +0900
> "Stephen J. Turnbull" 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 conflict
On Sat, Feb 22, 2014 at 12:55 PM, Greg Ewing
wrote:
> Steven D'Aprano wrote:
>
>> result = computation(
>> int(arg) except ValueError: abort("Invalid int")
>> )
>>
>> Actually, not quite so nice as I first thought, since you're relying on
>> the side-effects o
On Sat, Feb 22, 2014 at 1:07 PM, Victor Stinner
wrote:
> At the first read, I'm unable to understand this long expression. At
> the second read, I'm still unable to see which instruction will be
> executed first: lvl1[key] or lvl2[key]?
>
> The advantage of the current syntax is that the control f
On Sat, Feb 22, 2014 at 3:04 PM, Chris Angelico wrote:
> On Sat, Feb 22, 2014 at 1:07 PM, Victor Stinner
> wrote:
>> At the first read, I'm unable to understand this long expression. At
>> the second read, I'm still unable to see which instruction will be
>> executed first: lvl1[key] or lvl2[key]
On 2/21/2014, 10:42 PM, Chris Angelico wrote:
On Sat, Feb 22, 2014 at 6:04 AM, Yury Selivanov wrote:
* seq[index] - no way to handle a bounds error
We can add 'list.get(index, default)' method, similar to
'Mapping.get'. It's far more easier than introducing new
syntax.
That fixes it for the
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 thi
On Sat, Feb 22, 2014 at 4:01 PM, Steven D'Aprano wrote:
> (Chris, I think that ought to go in the motivation section of the PEP.)
Added to my draft, and here's the peps diff:
diff -r c52a2ae3d98e pep-0463.txt
--- a/pep-0463.txt Fri Feb 21 23:27:51 2014 -0500
+++ b/pep-0463.txt Sat Feb 22 16:33:3
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
On 2/21/2014 7:57 PM, Chris Angelico wrote:
On Sat, Feb 22, 2014 at 12:10 PM, Glenn Linderman wrote:
Here's a challenge: There has been a big thread about None versus (SQL)
Null. Show how an except: expression can help the DB API more easily convert
from using None to using a new Null singleton
Steven D'Aprano writes:
> On Fri, Feb 21, 2014 at 02:04:45PM -0500, Yury Selivanov wrote:
>
> > Inconvenience of dict[] raising KeyError was solved by
> > introducing the dict.get() method. And I think that
> >
> > dct.get('a', 'b')
> >
> > is 1000 times better than
> >
> > dct['a'] e
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 fractional-s
96 matches
Mail list logo
