Mailman 3 August 2001 - Python-Dev

%b formatting
by Greg Wilson 25 Aug '01

25 Aug '01

Patch 455076 adds "%b" (binary) formatting for integers and long integers to both strings and unicodes. As this is my first time hacking on the Python source, I'd be grateful for comments. Thanks, Greg p.s. apologies for the length of the signature --- it's another joy of corporate life :-( ----------------------------------------------------------------------------------------------------------------- The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error or there are any problems please notify the originator immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Baltimore Technologies plc will not be liable for direct, special, indirect or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on. In addition, certain Marketing collateral may be added from time to time to promote Baltimore Technologies products, services, Global e-Security or appearance at trade shows and conferences. This footnote confirms that this email message has been swept by Baltimore MIMEsweeper for Content Security threats, including computer viruses.

1 0

shutting up tmpnam, tempnam, link warnings
by Neil Schemenauer 24 Aug '01

24 Aug '01

If you're using a recent version of GNU libc you know what I mean. They are annoying as hell and there seems to be no way to disable them cleanly. Here's a hack: cd /lib perl -pe 's/gnu\.warning\.(tempnam|tmpnam|tmpnam_r)/gnu.wanting.\1/g' \ < libc-2.2.3.so > /tmp/libc-2.2.3.so cp -b /tmp/libc-2.2.3.so libc-2.2.3.so No warranty implied. :-) Neil

1 0

Re: [Python-Dev] PEP 264
by Michael Hudson 24 Aug '01

24 Aug '01

"Tim Peters" <tim.one(a)home.com> writes: > [Michael Hudson] > > I *think* I'm done coding for implementing PEP 264; patch at: > > > > http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449043 > > &group_id=5470 > > > > I've also done a first draft of docs. > > > > The reason for mentioning this is I'm off on holiday tomorrow, so if > > you want changes before the proposed date for 2.2a2, you've got aobut > > 12 hours to tell me about it. > > Thanks, Michael! I was out sick yesterday, but intend to get on this > tonight. You should enjoy your vacation! If it's a disaster, I'll probably > villify you on python-dev, but will fix it anyway <wink>. Thank you in turn for fixing all my cock-ups! I'd just like to note in passing that I considered most of the places the CO_* constants ended up in the last week, and rejected them as too gross. My idea was that __future__.generators.compiler_flag was to be the *only* (Python) name for CO_GENERATORS_ALLOWED (for example). Are there problems with this (other than the fact that you have to make sure two sets of magic numbers match up - but you have to edit __future__.py when you add a new future feature anyway...). I should probably add some words to the PEP on this topic, anyway. Cheers, M. -- ... when all the programmes on all the channels actually were made by actors with cleft pallettes speaking lines by dyslexic writers filmed by blind cameramen instead of merely seeming like that, it somehow made the whole thing more worthwhile. -- HHGTG, Episode 11

2 1

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

24 Aug '01

[GvR] > > [SP] > > *bad-guy-java* > > > > > > 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.). > > > [snip] > > I overlooked a central point, namely *bad-guy-java* > > > > I fear, because of it, we have to code all the built-in types this way, > > > > > > class SpamType { > > > > ... SpamTypes__foo__ { ... > > } > > > > ... __foo__ { } > > > > } > > > > Or find other slower ways, otherwise no descrs for them > > As long as the slowness only applies when someone invokes > SpamType.__foo__(x), that's acceptable. Not that simple, *bad-guy-java* is really nasty given your design for PEP 252 and PEP 253, you should put some hook to overridable behaviour or completely give up with Java OOP ... but it's our problem, your design up to my mro concerns is clearly is sound. But Jython 2.2 will be a major challenge. Samuele.

1 0

Customizing the binding of attributes
by Thomas Heller 24 Aug '01

24 Aug '01

In Python 2.2, is it possible to customize the binding of class attributes, to emulate the normal behaviour of methods (function -> unbound method -> bound method)? I think I have read something about this, but I can't find it anymore. Thomas

3 7

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

24 Aug '01

[GvR] > > > now A is in between list and object: what is the right thing here? > > Just say that this is what happens. The MRO is inconsistent in this > case. > > > I don't expect or invite users to do that, but your rules allow A to > > end up in that position in the mro, your philosophy seems to be > > this is thin ice and so let it be ... > > Exactly. I wish I would not feel uneasy with that <wink> > > On the third hand, if a C programmer *wants* to write a class with the > proper cooperative super calling, they can do so, it's just a bit > clumsy. Should I provide a C API to make this easier? I doubt that > it will be used much. If there's demand, it can be added later. I hope there will not be. GvR> I don't think such subclasses GvR> should be used in complex multiple inheritance lattices. > > > Better to enforce that? > > Why? I can think of situations where you have a MRO like this: > > C list B object > > but where B doesn't override anything that list might use. In fact, > this is the typical mix-in situation. I don't want to forbid this. OK, I see. (*) GVR> So enforce it and see how it turns out in practice. > > > It's probably the best solution, at least for Jython, > > and could even make sense for CPython (see above points) > > Good. We seem to agree. Yup but I see your point (*) so probably I can't. [me] *bad-guy-java* > > > > 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.). > > I hope this discussion so far has been helpful -- I have to pack for > my trip and will soon be off to San Francisco until next Wednesday. > Yes it was, thanks but I overlooked a central point, namely *bad-guy-java* I fear, because of it, we have to code all the built-in types this way, class SpamType { ... SpamTypes__foo__ { ... } ... __foo__ { } } Or find other slower ways, otherwise no descrs for them A nightmare :-( regards.

2 1

Re: [Python-Dev] Re: copy, len and the like as 'object' methods?
by Michael Hudson 24 Aug '01

24 Aug '01

Paul Prescod <paulp(a)ActiveState.com> writes: > > Would you also argue for [1, 2, 3].repr() and "abc".hash()? > > Yes. But hashing and repring are done much less often than taking the > length. Note that this is an argument for keeping len(o) over o.len() - at least you bump into it early. Reminds me of what Laura Creighton said about the results of her case-sensitivity survey. Cheers, M. -- First of all, email me your AOL password as a security measure. You may find that won't be able to connect to the 'net for a while. This is normal. The next thing to do is turn your computer upside down and shake it to reboot it. -- Darren Tucker, asr

1 0

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

24 Aug '01

[GvR] > > > 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 don't expect this to happen regularly. if you count on this I think > you're on really thin ice. No I'm not counting on that, I'm worried about this scenario A subclasses object and redefines __getattr__ B subclasses list then class C(B,A): ... will have the following mro: C B list A object In Jython codebase hypothetically but possibly list could contains calls like: __getattr__(...) and super.__getattr__ now A is in between list and object: what is the right thing here? I don't expect or invite users to do that, but your rules allow A to end up in that position in the mro, your philosophy seems to be this is thin ice and so let it be ... > > I saw that list_ass_slice calls list_slice directly, is that OK? > > It's certainly safe -- any subclass of list will share the same > structure lay-out (this is enforced by the subclassing machinery) so > the list_slice call will find the object properly inititialized. > > There are lots of places where the C code doesn't bother to look for > overridden methods -- the PyDict_* API is a common example. I have no > intention of fixing this. Fine with that, but ... > > > 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. > > Well, if you like that better, maybe I should remove the instructions > for subclassing at the C level? :-) No, I'm just saying that you are moving from a world were you had docume ntable C black-boxes and clear Python semantics, to a world where (but you say that would be rare) you can have Python code whose behaviour depends on very fine-grained decision inside C code. On one side your rules make it very easy to interleave Python and C code in the mro, on the other hand I agree that will be rarely done by the wary user because it's just surprise-land, don't know about the unwary ... > > My intention is to make the maximum number of different paradigms > usable in Python. You can do cooperative multiple inheritance, but > only of all your classes are designed with cooperation in mind. If > some class uses C-level (or Java-level) inheritance and is not written > cooperatively, you have to be a little careful using it as a base > class in a cooperatively written class. I don't want to enforce > cooperative coding at the Python level either: the > "BaseClass.method(self, args)" approach is still valid, but you have > to beware of the consequences. Do you feel is that a good thing, especially if new-style classes become the default? It is not a rethoric question, Python is becoming a little single dispatch CLOS with a MOP, descriptors etc but CLOS has only next-method and strange beasts like method combinators and don't allow to interleave low-level coded behaviour in the class mro. > > > 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. > > I definitely have to support code sharing. I think subclassing at the > C level is useful to create variations of built-in objects with > additional properties, e.g. numbers with additional operations or > formatting parameters, dictionaries with certain restrictions on the > keys, etc. I don't think such subclasses should be used in complex > multiple inheritance lattices. Better to enforce that? > > > OK you could say: that's C level, everybody should care for herself, > > but with Java we cannot do the same. > > Why not? Because users would like writing Jython types to become easier, and be possible using Java OOP model, without surprises, or undocumented subtlities, any deviation is an hard sell because Java has already an OOP model. >> > > > 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? > > Mostly because I don't provide a way to create multiple base classes. > That would not be hard to add though -- if there's demand. But this is a path that Jython could not follow. > > 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 :-( (*) > > Just sa no. :-) See above. > > > > 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? > > If you mean at the end, yes. Of course. > > > I had the same idea because this would make my life easier. > > Sounds good to me. > > > 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. (**) > > Me neither. But the problem is probably shallow -- Zope mostly uses > mixins of various sorts, so these classes probably don't override > stuff -- they just define new methods. (I haven't looked at what it > would take to replace ExtensionClass with the new metaclasses, but > that's definitely on the agenda.) > > > > 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 (**) > > So enforce it and see how it turns out in practice. It's probably the best solution, at least for Jython, and could even make sense for CPython (see above points) > > > 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.). > > I guess C.m has to call super.m to invoke B.m, right? Yup. > > Does this mean that the following can't be made to work? > > class C(list): > def add_spam(self): > return list.append(self, "spam") > > It's legal Python (although in general questionable style of course). Yes, it can be made to work (it already works for Java subclassing and type subclassing would be some flavor of that), but the point is that your Java stuff should be at the top of the mro. Because then you can insert some hooks using super. regards.

2 1

super()
by Guido van Rossum 24 Aug '01

24 Aug '01

Thomas Heller wrote (in private email, responding to a checkin message): > From: "Guido van Rossum" <gvanrossum(a)users.sourceforge.net> > > Add 'super', another new object type with magical properties. > > > > super(type) -> unbound super object > > super(type, obj) -> bound super object; requires isinstance(obj, type) > > > > Typical use to call a cooperative superclass method: > > > > class C(B): > > def meth(self, arg): > > super(C, self).meth(arg); > > Shouldn't that be > class C(B): > def meth(self, arg): > super(B, self).meth(arg) > ^ > to call B.meth(self, arg)? > > Thomas No. Good question, though! You have to pass your *own* class so that this finds the right super-method when multiple inheritance involving a "diamond" diagram. You may want to read the section on Method resolution order in PEP 253 first. Look at this example: class A(object): def meth(self, a): return "A.meth(%r)" % a print A().meth(1) class B(A): def __init__(self): self.__super = super(B, self) def meth(self, a): return "B.meth(%r) -> " % a + self.__super.meth(a) print B().meth(2) class C(A): __dynamic__ = 1 def meth(self, a): return "C.meth(%r) -> " % a + self.__super.meth(a) C._C__super = super(C) print C().meth(3) class D(C, B): def meth(self, a): return "D.meth(%r) -> " % a + super(D, self).meth(a) print D().meth(4) # D.meth(4) -> C.meth(4) -> B.meth(4) -> A.meth(4) D has the following inheritance graph: A ^ ^ / \ / \ / \ / \ C B ^ ^ \ / \ / \ / \ / D When you have a C or B instance, C.meth's super references A. But when you have a D instance, C.meth's super references B! In other words, D.meth calls C.meth calls B.meth calls A.meth. This is why you need to pass self to super() -- it needs the __mro__ sequence of the instance. Remember that D.__mro__ == (D,C,B,A,object). C.meth calls super(C, D()).meth. This looks for C in D.__mro__, and then starts searching for meth at the next class -- finding B.meth. If you wonder *why* the MRO is designed this way, imagine that meth() does some sort of saving to disk. Each subclass saves its own stuff and then calls the save method of its base class. Without the behavior described above, D.save() would have to call C.save() and B.save(), but this would call A.save() twice! This is part of a pattern called cooperative class design, described in the book Putting Metaclasses to Work (for a reference, see PEP 253). --Guido van Rossum (home page: http://www.python.org/~guido/)

1 0

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

24 Aug '01

Yes, I'm thinking furiously. GvR > A safe rule would be to require that all Python classes in a GvR > 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. (**) Oops, this is already a problem with the actual best_base rule, I don't know if my reinterpretation is OK, but doesn't it basically states that all C types subclassed by a new C level class should be in a subtyping relationship that means: with A isa list isa object B isa special_list isa list isa object C isa object class D(A,B,C): ... is OK but with Z isa Cbadboy isa object then class D(Z,A) isn't allowed. but if that is already *not* *a* *problem* then I think the rule could be not that bad ... regards.

2 1