Mailman 3 August 2001 - Python-Dev

Re: [Python-Dev] Comments: PEP 252, PEP 253 and jython issues
by Samuele Pedroni 24 Aug '01

24 Aug '01

Thanks for the answers, I'm happy the questions were parseable, Here are some comments, I think they may be meanigful also for CPython > > The question is it possible for CSpecialList for the code that define > > for example sq_ass_slice to use sq_slice code in a safe manner? > > (AFAIK listobject does something similar) > > I'm not 100% sure I understand this question, but CSpecialList can > certainly override sq_ass_slice. Then, if it wants to call > self.__slice__ (in Python terms) it could call > obj->ob_type->tp_as_sequence->sq_slice -- this would call C's > obj->ob_type->tp_as_sequence->__slice__ if it had one. I overlooked this, I think we can implement that also in Jython. An important point: should that be the only way to use a Python level exposed and overridable method from C code, is that left to the programmer ? The problem is that with the new mro possibly independently C defined things get interleaved with Python level code, so I imagine that the effect should be a bit disciplined ... I saw that list_ass_slice calls list_slice directly, is that OK? > > And how can safely CSpecialList invoke a "super" behaviour, it is saf > > for it to refer to the behaviour offered by list. In principle > > given the mro e.g. a __getslice__ redefined in B should shadow > > such a behaviour? > > I don't know if cooperative super calls are possible at the C level. > I certainly didn't define an API for this. I didn't define a Python > level API either, but I know how to o it and it can even be coded in > Python. Hm, I guess that makes it a theoretical possibility at the C > level. > > I don't expect this to be a common use pattern though (famous last > words :-). But it is certainely a pattern that a writer of Jython types would expect to use. The problem is still that C/Java stuff with the new mro get interleaved with Python level behaviour. IMHO you would better discipline this and also the above point <wink>. I don't know if there is some GUI toolkit that implement inheritance using C and not some language enforcing OO like C++, etc. Other OO languages like Smalltalk, Self, or Java allow only to define primitives or single methods to add lowel-level functionality, they don't try to allow subtyping at that level, the previous scenario in Python where you could define just opaque types, and in particular your C code never/normally got interleaved with Python behaviour was on that line. At worst you could say that you allow subtyping but not code sharing, but then even a C method for an object should be very careful using another overridable method of the very same object. OK you could say: that's C level, everybody should care for herself, but with Java we cannot do the same. > > It would make sense to use Java subclassing to implement > > type subclassing, at least at layout level this does not clash with > > the multiple inheritance rule in best_base. > > So you would rule out multiple inheritance of types? Fine with me, > but you may regret this a few yearsfrom now (when we all code multiple > inheritance all the time :-). No it is ruled out at Java level, not Jython level. But it is not also ruled out in CPython at C level? > > But than there is the issue of method resolution order: from the viewpoint > > of Python code we can implement anything, not that easy ... > > > > But the at the Java level, where we construct types, the codebase uses the > > normal single inheritance of java and the codebase is full of super.foo > > invocations and of methods that cross-call each other (potentially overriden) > > versions, and this happen also for behaviour that correspond to the slots/ > > __foo__ special methods of CPython. > > > > That's why the two questions are important? > > I see. CPython doesn't have this problem (yet) because it doesn't use > inheritance at the C level. see above. > I propose that you just try to live with > this. Related e.g. to Zope porting projects there have been a lot of pressure on jython-dev regarding how to code new types and metaclasses, A Jython type writer expect to be able to use Java naturally (i.e. use inheritance), for that, so the situation isn't that easy, is not even easy with the current codebase, because given the new mro one can even put some Python behaviour between: PyList PythonLevelCode and PyObject :-( (*) > A safe rule would be to require that all Python classes in a > given inheritance graph should derive from the same C/Java class. I That would mean that all C/Java behaviour is always only at the top of the mro, right? I had the same idea because this would make my life easier. A problem: some of the Zope porters reported that there are classes that inherits from more than a single ExtensionClass in Zope :-( don't know if that is true. (**) > don't know if we should enforce this or just warn about it in the > documentation. It would make our (jython-dev) life easier and avoid some impredictable problem even with CPython and code sharing, but see previous note (**) > I don't want to force you to call a cooperative super > method at the Java level -- it would be very slow, I suspect... Yes ... very slow and we would have to use that also at the very core of the hierarchy, see (*) but the problem is more complicated, in Java given three classes C extends B extends A and a method m C.m overrides B.m overrides A.m there is not direct way (even using reflection) to apply B.m behaviour to a C object, unless the programmer has left some hook in C using super or in B ( a method B_m e.g.). ... complicated :( regards.

2 1

Re: [Python-Dev] PEP 252, PEP 253 and jython issues
by Samuele Pedroni 24 Aug '01

24 Aug '01

Hi. OK, here is my major concern Given the following three types subclassed in Pyhon: class A(CSpecialList): ... class B(list): ... class C(A,B): ... where CSpecialList is a subtype of list written in C. Now the old mro would be: C A CSpecialList list object B list object that translate to the new mro C A CSpecialList B list object The question is it possible for CSpecialList for the code that define for example sq_ass_slice to use sq_slice code in a safe manner? (AFAIK listobject does something similar) And how can safely CSpecialList invoke a "super" behaviour, it is safe for it to refer to the behaviour offered by list. In principle given the mro e.g. a __getslice__ redefined in B should shadow such a behaviour? A natural way to design PEP252, and PEP253 for Jython would be start to start from the equation: object = org.python.core.PyObject then it is necessary to build a class that truly correspond to the type metatype, actually jython fakes using the metatype used for Java Classes for that. It would make sense to use Java subclassing to implement type subclassing, at least at layout level this does not clash with the multiple inheritance rule in best_base. And actually is also how Jython now works: for example PyList extends PySequence that extends PyObject. But than there is the issue of method resolution order: from the viewpoint of Python code we can implement anything, not that easy ... But the at the Java level, where we construct types, the codebase uses the normal single inheritance of java and the codebase is full of super.foo invocations and of methods that cross-call each other (potentially overriden) versions, and this happen also for behaviour that correspond to the slots/ __foo__ special methods of CPython. That's why the two questions are important? regards.

2 1

Re: [Python-Dev] Inline and SWIG
by Jack Jansen 24 Aug '01

24 Aug '01

> The *real* problem IMHO is actually > trying to figure out how to properly handle all of the facets of the > C/C++ type system (pointers, references, qualifiers, classes, > templates, typedef, inheritance, multiple inheritance, member > pointers, pass by value, etc.) and how that's supposed to hook into > Python. And at this time I customarily put in my plug for bgen. Bgen is far ahead of SWIG in this respect, and completely customizable in Python. It will definitely not do all the things you specify, but it'll do a lot more than SWIG, -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

1 0

jython issues and PEP 252, PEP 253
by Samuele Pedroni 24 Aug '01

24 Aug '01

Hi. I'm feeling a bit annoying and I don't like that. I'm not in hurry for a answer for my questions on PEP253 and PEP252 but were them at least parseable, did they make sense? or are too vague, and underdetailed should I bring more elements in the picture? regards, Samuele Pedroni.

1 0

Near Final PEP 237 - Unifying Long Integers and Integers
by David Beazley 24 Aug '01

24 Aug '01

Guido van Rossum writes: > Please comment on a new version of PEP 237: > > Please mail comments on the PEP to python-dev(a)python.org or to me. > The PEP looks good to me. Can I make a very small C API feature request? (assuming this hasn't been implemented already). Since "integers" can now have arbitrary precision and can represent large unsigned values, can you add three new format characters to PyArg_ParseTuple() and Py_BuildValue() for the C datatypes "unsigned int", "unsigned long", and "unsigned long long"? The "u" and "l" namespace is a little crowded (and I don't think you would want to break that). However, here's one idea: 'I' - unsigned int (consistent with H and B) 'p' - unsigned long ('p' is for positive) 'P' - unsigned long long Cheers, Dave

2 1

Cuddly constants seek loving, stable home
by Tim Peters 24 Aug '01

24 Aug '01

__future__.py now contains this abomination: try: import new as _new # for CO_xxx symbols except ImportError: # May happen during build class _new: CO_NESTED = 0x0010 CO_GENERATOR_ALLOWED = 0x1000 CO_FUTURE_DIVISION = 0x2000 "new" turned out to be a bad module to hold these constants, despite that that's where they belong (i.e., along with the function that creates new code objects), first because "new" wasn't always built "in time" on Unixy boxes, and second because "new" isn't available at all in restricted mode. So they can't live in "new", but duplicating their values by hand is also unbearable. "sys" is the only other module I see where they *might* fit, but they don't really belong there (indeed, trying to make a case that they do is a lot like arguing "len" should be a method <wink>). So I propose a new builtin module, _sysconsts. The underscore is to announce its obscure internal nature. I propose only to expose the CO_xxx #defines at the start, but of course others could be added. Any objections? ain't-worth-a-pep-unless-there-are-ly y'rs - tim

8 12

Inline and SWIG
by David Beazley 24 Aug '01

24 Aug '01

> > It isn't as trivial as you think. It is essentially a superset of SWIG's > Python-related functionality. Don't forget that an important part of it > is trying to autodetect types. It quickly gets into figuring out structs > and then classes and then templates and then madness ensues. Obviously > you have to decide how much you are going to support and just require > "compliant" wrappers for the rest. Using SWIG might allow you to offload > a bunch of that effort for PyInline::C. I've looked briefly at Inline and agree that it's a pretty nifty approach. However, usability aside, it's got a number of pretty major limitations once you start getting into structure wrapping, C++ classes, and other advanced types of extension wrapping. I think a common misconception about wrapper generation tools in general is that it's just a matter of hacking up a quick parser and throwing something together in a couple of days. The *real* problem IMHO is actually trying to figure out how to properly handle all of the facets of the C/C++ type system (pointers, references, qualifiers, classes, templates, typedef, inheritance, multiple inheritance, member pointers, pass by value, etc.) and how that's supposed to hook into Python. What's worse, if you get *ANY* part of the type system wrong, everything becomes a hellish nightmare later (and I can speak from personal experience on this :-). We've been working on an upcoming major new SWIG release for quite some time now and about 80% of that work has been related to redesigning the internal type system. Maybe this sort of thing is obvious to everyone else and I'm missing some trivial point, but I sure haven't found the C++ type system to be this totally trivial thing I could just hack up in a few days and stick in a code generator! In any case, I think the coolest thing about Inline is the ability to add small little bits of C code on-the-fly without having to restart the interpreter. That's a pretty neat trick that would probably be useful in the context of working with larger C extensions. I'm not sure I'd want to build a huge 400 function C extension module with that kind of approach, but something like that would definitely be useful for prototyping and adding code on the fly. I almost wonder if something like SWIG could be used behind the scenes to do code generation for something like that. Cheers, Dave

8 9

Re: Inline::caveat
by Charles G Waldman 23 Aug '01

23 Aug '01

> It's also harder to maintain because it's harder to edit and debug. > > Maybe all them fancy IDEs you youngin's use can easily support editing > mutiple different languages in the same file, but if so, let me know! > The tools/editors/debuggers I'm familiar with don't deal with any of > that very well, if at all. I agree that debugging any Inline code is going to be difficult (it's already tricky enough debugging C modules generated by SWIG), but as far as editor support goes - the "fancy IDE" of choice (XEmacs, of course) actually can support such mixed-language editing, once you've loaded up the appropriate elisp and done some customization... Have you seen the "MMM" package? MMM stands for "Multiple Major Modes" which allows you to have, just like the name suggests, multiple major modes within one buffer. I have used this successfully for editing HTML with embedded JavaScript (although I hate to admit that I have written such junk!). You can get it at: http://members.tripod.com/gchen2/xemacs/ This package seems to be little-known. Maybe it should be added to the XEmacs package database? (I'll bring this up on xemacs-beta) FWIW, -C

3 2

Putting a builtin module into a package
by Jack Jansen 23 Aug '01

23 Aug '01

Is there a way to put a builtin module into a package, or should I really not want to do this? It seems that if in the module init() routine I call Py_InitModule("Carbon.Res") and if I put the module into _PyImport_Inittab as "Carbon.Res" things sort-of work, at first glance. Or should I rename the module to an underscore name and simply put a wrapper module in the package? -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++

3 2

More feedback from script scape
by Paul Prescod 23 Aug '01

23 Aug '01

Something else I heard at script scape is that for simple extensions (wrappers around C code) Perl has not only caught up to Python but surpassed it thanks to inline::C, inline::Python etc. As soon as you move to doing anything complicated with the interpreter internals, Python wins again, but it still annoys me that Perl has leapfrogged us in wrapping simplicity! -- Take a recipe. Leave a recipe. Python Cookbook! http://www.ActiveState.com/pythoncookbook

5 12