Defining Python class methods in C
Alex Martelli
aleax at aleax.it
Mon Mar 24 06:00:45 EST 2003
More information about the Python-list mailing list
Mon Mar 24 06:00:45 EST 2003
- Previous message (by thread): Defining Python class methods in C
- Next message (by thread): Defining Python class methods in C
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Bryan wrote: ... >> > i take it from >> >john's posting, that classes are uses to be compatible with older >> >versions of python. >> >> I don't know where you got that idea, or even what you mean by that. >> In fact there are two kinds of classes, classic and new. See this: >> >> http://www.python.org/doc/2.2.1/whatsnew/ >> >> Cheers, >> John > > hmmm... i don't know where i got that idea either... sorry about that. Perhaps something I said (maybe in email with Bryan rather than in a post) has something to do with this idea. What I wanted to say (but may have been too concise/hasty in expressing) is: if you need your extension to work with Python 2.1, and you also need certain features such as letting Python code inherit from the "kind" of objects that your extension supplies, then that is one motivation to go to the trouble of having your extension supply, as the "kind", a CLASS rather than a TYPE. That would be a "classic class", as there are no other categories of classes in Python 2.1 and earlier. Unless you specifically need 2.1 compatibility, having your extension supply a type is, I believe, generally simpler and more effective. In Python 2.2 and later, Python code can inherit from your type (if you design your type for that purpose), and other marginal issues such as introspection, that might require you to code a [classic] class instead of a type in your C-coded extensions for 2.1, are also ameliorated. > i know the difference between classic and new classes on the python > side. i'm just not clear from the c side. are c types equivalent to > python classic classes and c classes equivalent to python new classes? Of course not, and it's easy to check this -- just see what type(X) has to say when X is a classic class (whether implemented from C or from Python), a new-style class implemented in Python, a type object implemented in C. > anyways, the type was definitely the functionality that i wanted... c Good, I did suspect that was the case, and mentioned this repeatedly. > setting of the type object with encapsulated data, sending it to > python which callsback with methods executing in c that can retrieve > the data stored in self. it was interesting that with types, my self > variable has the correct value. but when i was using the class style, > self was always NULL and the first value of args was the type. seems The type rather than an instance thereof? That's weird -- I think you most likely may have mis-observed or misunderstood. > bizarre to me. i hope one day someone will write an entire book on > the python c api just like there are several books on java's JNI. I've toyed with that idea, though I think such a book should also cover SWIG, Boost and Pyrex at the very least -- each of them, under certain conditions, being a preferable way to extend Python rather than using the bare C API. But anyway, I think that, what with the diminishing-with-time importance of compatibility with Python versions earlier than 2.2, it would probably not make much sense for such a hypothetical book to delve into coverage of exoterica such as the implementation of classic classes (rather than types) in C code. Alex
- Previous message (by thread): Defining Python class methods in C
- Next message (by thread): Defining Python class methods in C
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-list mailing list