Mailman 3 August 2001 - Python-Dev

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

Aug. 24, 2001

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.… [View More]__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. [View Less]

2 1

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

Aug. 24, 2001

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 … [View More]

2 1

Re: [Python-Dev] Inline and SWIG
by Jack Jansen Aug. 24, 2001

Aug. 24, 2001

> 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 … [View More]

1 0

jython issues and PEP 252, PEP 253
by Samuele Pedroni Aug. 24, 2001

Aug. 24, 2001

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 Aug. 24, 2001

Aug. 24, 2001

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", … [View More]

2 1

Cuddly constants seek loving, stable home
by Tim Peters Aug. 23, 2001

Aug. 23, 2001

__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 … [View More]

8 12

Inline and SWIG
by David Beazley Aug. 23, 2001

Aug. 23, 2001

> > 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 … [View More]

8 9

Re: Inline::caveat
by Charles G Waldman Aug. 23, 2001

Aug. 23, 2001

> 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 … [View More]

3 2

Putting a builtin module into a package
by Jack Jansen Aug. 23, 2001

Aug. 23, 2001

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 … [View More]

3 2

More feedback from script scape
by Paul Prescod Aug. 23, 2001

Aug. 23, 2001

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