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 the
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 wrote:
+Had this facility existed early in Python's history, there would have been
+no need to create dict.get() and related methods;
On Wed, Mar 05, 2014 at 12:57:03PM -0800, Thomas Wouters wrote:
> On Thu, Feb 27, 2014 at 1:29 PM, Chris Angelico 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 s
On Thu, Mar 6, 2014 at 12:03 PM, Thomas Wouters 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
Unsubscribe:
https://m
On Wed, Mar 5, 2014 at 4:28 PM, Chris Angelico wrote:
> On Thu, Mar 6, 2014 at 7:57 AM, Thomas Wouters 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 pa
On Thu, Mar 6, 2014 at 7:57 AM, Thomas Wouters 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 any of
> the othe
On Thu, Mar 6, 2014 at 7:57 AM, Thomas Wouters wrote:
> On Thu, Feb 27, 2014 at 1:29 PM, Chris Angelico 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 consid
On 6 Mar 2014 08:32, "Yury Selivanov" wrote:
>
>
> On 2014-03-05, 4:54 PM, Nick Coghlan wrote:
>>
>> On 6 Mar 2014 02:43, "Antoine Pitrou" wrote:
>>>
>>> Le 05/03/2014 17:37, Victor Stinner a écrit :
>>>
Python 3.4 introduced frame.clear(), but frame.clear() raises an
RuntimeError if th
On 2014-03-05, 4:54 PM, Nick Coghlan wrote:
On 6 Mar 2014 02:43, "Antoine Pitrou" 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 o
On Wed, Mar 5, 2014 at 2:54 PM, Nick Coghlan 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 handled pickling
I think it was http://bugs.python.org/issue17911
On Wed, Mar 5, 2014 at 1:54 PM, Nick Coghlan wrote:
>
> On 6 Mar 2014 02:43, "Antoine Pitrou" wrote:
> >
> > Le 05/03/2014 17:37, Victor Stinner a écrit :
> >
> >>
> >> Python 3.4 introduced frame.clear(), but frame.clear() raises an
> >> Runtim
On 6 Mar 2014 02:43, "Antoine Pitrou" 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 sto
On 6 Mar 2014 01:32, "Antoine Pitrou" 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 oth
On Thu, Feb 27, 2014 at 1:29 PM, Chris Angelico 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 incorrect. 'd[k] ex
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 Exception.__traceba
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" especi
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 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 weeken
On 5 Mar 2014 12:48, "Larry Hastings" 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 do
an r
19 matches
Mail list logo
