Antoine Pitrou writes:
> Le Wed, 14 Aug 2013 14:17:59 +0900, Arnaud Fontaine
> a écrit :
>> From my understanding of import.c source code, until something is
>> added to sys.modules or the code loaded, there should be no
>> side-effect to releasing the lock, right? (eg there is no global
>> vari
On Sun, 18 Aug 2013 17:31:24 +0100
Mark Shannon wrote:
>
> By giving the dummy object a custom type, the dummy object can be
> recognised by testing that its type equals PySetDummy_Type (or
> whatever it is called)
>
> See dictobject.c for an implementation of a suitable dummy object.
The most
On 17/08/13 19:42, Antoine Pitrou wrote:
On Sat, 17 Aug 2013 11:32:00 +0200 (CEST)
raymond.hettinger wrote:
http://hg.python.org/cpython/rev/2c9a2b588a89
changeset: 85218:2c9a2b588a89
user:Raymond Hettinger
date:Sat Aug 17 02:31:53 2013 -0700
summary:
Use a known unique o
On Sun, 18 Aug 2013 09:03:56 +0200
Armin Rigo wrote:
> Hi,
>
> On Sat, Aug 17, 2013 at 8:42 PM, Antoine Pitrou wrote:
> >> summary:
> >> Use a known unique object for the dummy entry.
>
> Another issue with this change: the dummy object should be of a dummy
> subclass of 'object', rather than
Hi,
On Sat, Aug 17, 2013 at 8:42 PM, Antoine Pitrou wrote:
>> summary:
>> Use a known unique object for the dummy entry.
Another issue with this change: the dummy object should be of a dummy
subclass of 'object', rather than of 'object' itself. When it is
'object' itself, a custom __eq__() me
