> [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. [Brett Cannon] > That sounds great. Anything to make coding C extensions easier. Brett, may I politely suggest that you try writing C extensions first before claiming it needs to be made easier? Christian's additions (as far as I understand them :-) are mostly intended for very esoteric situations. > > 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? Alas, it would cause a major slowdown if this was the only way to provide heavily-used operations like __add__ and __getitem__. Most of the machinery to allow this probably already exists, but I wouldn't recommend using it. Also, you'd have to provide two implementations for binary operators, e.g. __add__ and __radd__. > 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. =) You could've picked a simpler extension to try to modify. :-) --Guido van Rossum (home page: http://www.python.org/~guido/)
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