Re: [Python-Dev] cpython: Use a known unique object for the dummy entry.
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__() method will be called, sending what
should be the dummy object to the pure Python code explicitly, as in
the example below. This is bad because ---in addition to calling
__eq__() with unexpected arguments, which might break some code--- we
could then take the dummy object, and try to insert it into another
set...
class A(object):
def __init__(self, hash):
self.hash = hash
def __eq__(self, other):
print("seen!", self, other)
return False
def __hash__(self):
return self.hash
a1 = A(1)
a2 = A(2)
s = {a1, a2}
s.remove(a2)
A(2) in s
A bientôt,
Armin.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Use a known unique object for the dummy entry.
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 of 'object' itself. When it is > 'object' itself, a custom __eq__() method will be called, sending what > should be the dummy object to the pure Python code explicitly, as in > the example below. This is bad because ---in addition to calling > __eq__() with unexpected arguments, which might break some code--- we > could then take the dummy object, and try to insert it into another > set... Indeed. Also, any non-trivial __eq__ will start receiving unexpected objects and may break in mysterious ways... Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Use a known unique object for the dummy entry.
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 object for the dummy entry.
This lets us run PyObject_RichCompareBool() without
first needing to check whether the entry is a dummy.
files:
Objects/setobject.c | 45 ++--
1 files changed, 20 insertions(+), 25 deletions(-)
This broke test_gdb on several machines:
==
FAIL: test_sets (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of sets
--
Traceback (most recent call last):
File "/home/antoine/cpython/default/Lib/test/test_gdb.py", line 319,
in test_sets self.assertEqual(gdb_repr, "{'b'}")
AssertionError: "{, 'b'}" != "{'b'}"
- {, 'b'}
+ {'b'}
Obviously the pretty-printing of sets isn't able to recognize the dummy
from regular set contents, anymore :-) It should be fixable, but I
don't know how.
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.
Cheers,
Mark.
Regards
Antoine.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/mark%40hotpy.org
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Use a known unique object for the dummy entry.
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 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! Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Dealing with import lock deadlock in Import Hooks
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 >> variables/data being shared for importing modules, meaning that >> releasing the lock should be safe as long as the modules loaded >> through import hooks are protected by a lock) > > Er, probably, but import.c is a nasty pile of code. > It's true the import lock is there mainly to: > - avoid incomplete modules from being seen by other threads > - avoid a module from being executed twice Yes. Hopefully, the implementation in Python 3.3 should be much better! ;-) > But that doesn't mean it can't have had any other - unintended - > benefits ;-) Indeed, that's why I checked the source code, but I will check again anyway to make sure. > (also, some import hooks might not be thread-safe, something which they > haven't had to bother about until now) Good point, I didn't think about that. Thanks! Regards, -- Arnaud Fontaine ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
