> The most reasonable thing to do would probably be to share the same
> dummy object between setobject.c and dictobject.c, then.
> Raymond, it would be nice if you could take a look!
Thanks, I will look at it shortly.
Raymond
On Sun, Aug 18, 2013 at 11:46 AM, Antoine Pitrou wrote:
> On Sun,
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
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 object for the dummy entry.
>
> T
