On 5 Mar 2014 12:48, Larry Hastings la...@hastings.org wrote:
On 03/04/2014 03:59 PM, Barry Warsaw wrote:
I too would like an rc3, especially to see if issue 19021 can be fixed,
which
I suspect will hit a lot of people.
I talked to the other guys on the 3.4 team, and we're all willing to
Le 05/03/2014 03:46, Larry Hastings a écrit :
On 03/04/2014 03:59 PM, Barry Warsaw wrote:
I too would like an rc3, especially to see if issue 19021 can be fixed, which
I suspect will hit a lot of people.
I talked to the other guys on the 3.4 team, and we're all willing to do
an rc3 this
Hi,
Python 3 now stores the traceback object in Exception.__traceback__
and exceptions can be chained through Exception.__context__. It's
convinient but it introduced tricky reference cycles if the exception
object is used out of the except block.
Refrences: Exception.__traceback__ - traceback -
Le 05/03/2014 17:37, Victor Stinner a écrit :
Python 3.4 introduced frame.clear(), but frame.clear() raises an
RuntimeError if the frame is still running. And it doesn't break all
reference cycles.
An obvious workaround is to store the traceback as text, but this
operation is expensive
On 2014-03-05, 11:37 AM, Victor Stinner wrote:
[snip]
I tried to write views of the traceback (and frames), but
Exception.__traceback__ rejects types other than traceback and
traceback instances cannot be created. It's possible to store the
traceback somewhere else and set
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 6 Mar 2014 01:32, Antoine Pitrou solip...@pitrou.net wrote:
Le 05/03/2014 03:46, Larry Hastings a écrit :
On 03/04/2014 03:59 PM, Barry Warsaw wrote:
I too would like an rc3, especially to see if issue 19021 can be fixed,
which
I suspect will hit a lot of people.
I talked to the other
On 6 Mar 2014 02:43, Antoine Pitrou solip...@pitrou.net wrote:
Le 05/03/2014 17:37, Victor Stinner a écrit :
Python 3.4 introduced frame.clear(), but frame.clear() raises an
RuntimeError if the frame is still running. And it doesn't break all
reference cycles.
An obvious workaround is to
I think it was http://bugs.python.org/issue17911
On Wed, Mar 5, 2014 at 1:54 PM, Nick Coghlan ncogh...@gmail.com wrote:
On 6 Mar 2014 02:43, Antoine Pitrou solip...@pitrou.net wrote:
Le 05/03/2014 17:37, Victor Stinner a écrit :
Python 3.4 introduced frame.clear(), but frame.clear()
On Wed, Mar 5, 2014 at 2:54 PM, Nick Coghlan ncogh...@gmail.com wrote:
Guido had a fix in mind - splitting traceback formatting into two pieces.
The first would convert a traceback to a sequence of named tuples, the
second would do the actual string formatting.
+1
This is basically how I've
On 2014-03-05, 4:54 PM, Nick Coghlan wrote:
On 6 Mar 2014 02:43, Antoine Pitrou solip...@pitrou.net wrote:
Le 05/03/2014 17:37, Victor Stinner a écrit :
Python 3.4 introduced frame.clear(), but frame.clear() raises an
RuntimeError if the frame is still running. And it doesn't break all
On 6 Mar 2014 08:32, Yury Selivanov yselivanov...@gmail.com wrote:
On 2014-03-05, 4:54 PM, Nick Coghlan wrote:
On 6 Mar 2014 02:43, Antoine Pitrou solip...@pitrou.net wrote:
Le 05/03/2014 17:37, Victor Stinner a écrit :
Python 3.4 introduced frame.clear(), but frame.clear() raises an
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
19 matches
Mail list logo
