headers
Barry Scott | 5 Oct 20:14

porting pycxx and pysvn to python 3.0 hit a problem

I have a version of PyCXX ported to python 3.0 rc1 and its passing  
its tests.
I'm porting pysvn to python 3.0 rc1 and hit an odd problem.

Given this dict:

	wc_status_kind_map = {
    	 	pysvn.wc_status_kind.added: 'A',
     		pysvn.wc_status_kind.replaced: 'R',
     		pysvn.wc_status_kind.unversioned: '?',
     	}

This fails:

	wc_status_kind_map[ pysvn.wc_status_kind.unversioned ]

With:

	KeyError: <wc_status_kind.unversioned>

Clearly I have a bug in the implementation of pysvn.wc_status_kind and
could do with some suggestions on what to check please.

I've assumed that if my objects support tp_hash and tp_compare
they can be used as keys to a dictionary. My test scripts shows
hash() and cmp() working.

Why does "key in wc_status_kind_wc" work when I use an object returned
by keys() by not when I use pysvn.wc_status_kind.unversioned?
(Continue reading)

Permalink | Reply |
headers
"Martin v. =?iso-8859-1?q?L=F6wis=22?= | 5 Oct 20:47

Re: porting pycxx and pysvn to python 3.0 hit a problem

> Why does "key in wc_status_kind_wc" work when I use an object returned
> by keys() by not when I use pysvn.wc_status_kind.unversioned?

This is too little detail to come up with an explanation. Do your
objects support __eq__.

Regards,
Martin
_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
Permalink | Reply |
headers
Barry Scott | 7 Oct 23:52

Re: porting pycxx and pysvn to python 3.0 hit a problem


On Oct 5, 2008, at 19:47, Martin v. Löwis wrote:

>> Why does "key in wc_status_kind_wc" work when I use an object  
>> returned
>> by keys() by not when I use pysvn.wc_status_kind.unversioned?
>
> This is too little detail to come up with an explanation. Do your
> objects support __eq__.
>
> Regards,
> Martin
>

I wrote a smaller version of the code that fails and had a session with
gdb.

My object implements tp_compare but lookdict() uses richcompare.
If richcompare is not implemented do_richcompare() falls back to
comparing PyObject * pointers - which is cause of the KeyError
as the objects cmp() eq but have different PyObect * values.

This is a change from V2 python where to be a key implementing
tp_hash and tp_compare is sufficient.

In V3 is it your intention that to be a key you must implement
tp_hash and tp_richcompare? If not I'll raise a bug against
3.0 on this issue.

Barry
(Continue reading)

Permalink | Reply |
headers
"Martin v. =?iso-8859-1?q?L=F6wis=22?= | 8 Oct 00:31

Re: porting pycxx and pysvn to python 3.0 hit a problem

> In V3 is it your intention that to be a key you must implement
> tp_hash and tp_richcompare? If not I'll raise a bug against
> 3.0 on this issue.

I believe that cmp/tp_compare are being phased out, although
I think there was a heavy debate about this.

In any case, I think you really need to implement tp_richcompare.

Regards,
Martin
_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
Permalink | Reply |
headers
Barry Scott | 8 Oct 01:20

Re: porting pycxx and pysvn to python 3.0 hit a problem


On Oct 7, 2008, at 23:31, Martin v. Löwis wrote:

>> In V3 is it your intention that to be a key you must implement
>> tp_hash and tp_richcompare? If not I'll raise a bug against
>> 3.0 on this issue.
>
> I believe that cmp/tp_compare are being phased out, although
> I think there was a heavy debate about this.

Given the problems I am seeing with tp_compare I'd advise
that you get rid of it for 3.0. The half hearted support is worst
then no support. At least if you remove tp_compare it forces
a porter to implement tp_richcompare.

>
> In any case, I think you really need to implement tp_richcompare.

I've added support already in PyCXX. I'll now implement
tp_richcompare for pysvn and document this in my PyCXX
porting guide.

Barry

_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
(Continue reading)

Permalink | Reply |
headers
Terry Reedy | 5 Oct 23:49

Re: porting pycxx and pysvn to python 3.0 hit a problem

Barry Scott wrote:

> for key in [pysvn.wc_status_kind.added,
>             pysvn.wc_status_kind.replaced,
>             pysvn.wc_status_kind.unversioned]:
>     print( '2 key', key, key in wc_status_kind_map, cmp( key, 
> pysvn.wc_status_kind.unversioned ), hash( key ) )
>     try:
>         print( '2 lookup', wc_status_kind_map[ key ] )
>     except:
>         print( '2 failed' )

> 2 key added False 1 -586300914
> 2 failed
> 2 key replaced False 1 -586300911
> 2 failed
> 2 key unversioned False 0 -586300916
> 2 failed

Given that p.we.x seems to always return the same object (since the 
hashes, which which appear to be ids, are the same), an __eq__ method 
(which gets called in preference to __cmp__), possibly inherited, that 
always return False is the only thing I can think of.  (Hence Martin's 
question, I presume).  I have no idea, however, how porting could make 
that happen.

tjr

_______________________________________________
Python-Dev mailing list
(Continue reading)

Permalink | Reply |
headers
Barry Scott | 7 Oct 21:53

Re: porting pycxx and pysvn to python 3.0 hit a problem


On Oct 5, 2008, at 22:49, Terry Reedy wrote:

> Barry Scott wrote:
>
>> for key in [pysvn.wc_status_kind.added,
>>             pysvn.wc_status_kind.replaced,
>>             pysvn.wc_status_kind.unversioned]:
>>     print( '2 key', key, key in wc_status_kind_map, cmp( key,  
>> pysvn.wc_status_kind.unversioned ), hash( key ) )
>>     try:
>>         print( '2 lookup', wc_status_kind_map[ key ] )
>>     except:
>>         print( '2 failed' )
>
>> 2 key added False 1 -586300914
>> 2 failed
>> 2 key replaced False 1 -586300911
>> 2 failed
>> 2 key unversioned False 0 -586300916
>> 2 failed
>
> Given that p.we.x seems to always return the same object (since the  
> hashes, which which appear to be ids, are the same), an __eq__  
> method (which gets called in preference to __cmp__), possibly  
> inherited, that always return False is the only thing I can think  
> of.  (Hence Martin's question, I presume).  I have no idea,  
> however, how porting could make that happen.

The type is not derived so the __eq__ cannot be happening.
(Continue reading)

Permalink | Reply |
headers
Barry Scott | 7 Oct 21:58

Re: porting pycxx and pysvn to python 3.0 hit a problem


On Oct 5, 2008, at 22:49, Terry Reedy wrote:

Given that p.we.x seems to always return the same object (since the hashes, which which appear to be ids, are the same), an __eq__ method (which gets called in preference to __cmp__), possibly inherited, that always return False is the only thing I can think of.  (Hence Martin's question, I presume).  I have no idea, however, how porting could make that happen.


I see no reply from Martin. What was his question?

Barry

_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
Permalink | Reply |
headers
"Martin v. =?iso-8859-1?q?L=F6wis=22?= | 7 Oct 22:11

Re: porting pycxx and pysvn to python 3.0 hit a problem

>> Given that p.we.x seems to always return the same object (since the
>> hashes, which which appear to be ids, are the same), an __eq__ method
>> (which gets called in preference to __cmp__), possibly inherited, that
>> always return False is the only thing I can think of.  (Hence Martin's
>> question, I presume).  I have no idea, however, how porting could make
>> that happen.
>>
> 
> I see no reply from Martin. What was his question?

Whether __eq__ was implemented for the specific type (and whether
that implementation was consistent with __hash__).

Regards,
Martin
_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
Permalink | Reply |

Gmane