[Christian Tismer] <snip> > For your own, non-magic methods, there was not support, yet. > Sure, you could override your methods, but you needed > extra machinery to keep track of the methods, to find out > which to call when, and so on. > The proper way to store extra info about methods is to > put this info into the type object itself. This was not > possible before my patch. You could help yourself my > extending some of the existing method tables, but this > is hackish. > That sounds great. Anything to make coding C extensions easier. > I didn't care of the magic slots at all. I think they don't need > to be changed, but I will have a look at it. <snip> Part of the reason I asked about the magic slots is that I personally think it would be great if you didn't have to use the specific struct slots for magic slots but instead were called based on their name in Python. That way you would not have to view Include/object.h every time you wanted to use one of the magic methods; you could just add it just like any other method and just give it a Python name that matched its magic method name. The obvious drawback is you would lose compiler checking that the arguments were correct for the method. But wouldn't this simplify keeping binary-compatibility if it was used since the struct would be pruned down significantly? I don't know how much of a stumbling block this all is for newbies, but I know when I looked at extending sre's pattern objects to add a __contains__ method it took me a little while to find where the slot was and what all the macros were for. But that might also be because I didn't read the C extension docs and just dove in. =) -Brett
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4