[Python-3000] Get rid of Py_FindMethod

[Collin Winter]

On Tue, Jul 1, 2008 at 10:06 AM, Guido van Rossum <guido at python.org> wrote:
> On Tue, Jul 1, 2008 at 5:37 AM, Amaury Forgeot d'Arc <amauryfa at gmail.com> wrote:
>> http://bugs.python.org/issue3247 complains that with python 3.0, dir()
>> of a SRE_Match object returns an empty list.
>>
>> This type has the particularity to not define a tp_methods; instead,
>> its tp_getattr slot calls Py_FindMethod(match_methods, self, name)
>> where "match_methods" is a PyMethodDef[] array that looks very very
>> similar to a typical tp_methods slot.
>>
>> Py_FindMethod has a trick: when the requested name is "__methods__",
>> it returns the names of the PyMethodDef items.
>>
>> __methods__ has disappeared with python 3.0, and indeed if I enable
>> the "-3" warning flag on python2.6,
>> dir() on a SRE_Match object raises two (!) warnings:
>> __main__:1: DeprecationWarning: __methods__ not supported in 3.x
>> __main__:1: DeprecationWarning: __members__ and __methods__ not supported in 3.x
>>
>> According to previous discussions:
>> http://mail.python.org/pipermail/python-3000/2007-July/008787.html
>> Py_FindMethod is not needed any more in modern modules, and should go away.
>> Note that PyMember_Get has already disappeared, because the few
>> modules using them were deleted...
>>
>> Is it still time for such a change after beta1?
>
> I'd say definitely. This just fell through the cracks.
>
>> There are ~30 occurrences of Py_FindMethod in the code base.
>> Most of the time, it is enough to remove the call, and set the
>> tp_methods members.
>
> Good!
>
>> Another thing: why was traceback.__dir__ added?
>> the current 3.0 produces:
>>>>> dir(b.__traceback__)
>> ['tb_frame', 'tb_lasti', 'tb_lineno', 'tb_next']
>>
>> When I remove the __dir__ method, I get the special methods as well:
>>>>> dir(b.__traceback__)
>> ['__class__', '__delattr__', '__doc__', '__eq__', '__format__',
>> '__ge__', '__getattribute__', '__gt__', '__hash__', '__init__',
>> '__le__', '__lt__', '__ne__', '__new__', '__reduce__',
>> '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__str__',
>> '__subclasshook__', 'tb_frame', 'tb_lasti', 'tb_lineno', 'tb_next']
>>
>> It's more verbose, but most types have the same list of special
>> members. I suggest to remove it, to enhance consistency (loosing some
>> 2.6 compatibility, but it's python3.0 after all)
>
> Can't tell you why -- looks odd to me too. Hopefully Collin Winter remembers.

My recollection is that this was done to preserve compatibility with
2.x, which has this behaviour; there were some tests that iterated the
list of members or something like that.

Collin