Re: [Python-Dev] Let's get rid of unbound methods
On 04/06/13 12:43, 探晴 wrote: Your email appears to be blank, except for a large chunk of HTML code. Did you have something specific to say other than the subject line? As for unbound methods, Guido's time machine strikes again. They're already gone in Python 3. py> class X: ... def spam(self): ... pass ... py> X.spam py> X().spam > -- Steven ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Let's get rid of unbound methods
___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's get rid of unbound methods
Tim Peters wrote: I expect that's because he stopped working on Zope code, so actually thinks it's odd again to see a gazillion methods like: class Registerer(my_base): def register(*args, **kws): my_base.register(*args, **kws) I second that! My PyGUI code is *full* of __init__ methods like that, because of my convention for supplying initial values of properties as keyword arguments. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's get rid of unbound methods
Josiah Carlson wrote: While it seems that super() is the 'modern paradigm' for this, I have been using base.method(self, ...) for years now, and have been quite happy with it. I too would be very disappointed if base.method(self, ...) became somehow deprecated. Cooperative super calls are a different beast altogether and have different use cases. In fact I'm having difficulty finding *any* use cases at all for super() in my code. I thought I had found one once, but on further reflection I changed my mind. And I have found that the type checking of self provided by unbound methods has caught a few bugs that would probably have produced more mysterious symptoms otherwise. But I can't say for sure whether they would have been greatly more mysterious -- perhaps not. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's get rid of unbound methods
Hi Phillip, On Wed, Jan 05, 2005 at 01:03:42PM -0500, Phillip J. Eby wrote: > >Is there any other use case for 'C.x' not returning the same as > >'appropriate_super_class_of_C.__dict__["x"]' ? > > Er, classmethod would be one; a rather important one at that. Oups. Right, sorry. Armin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's get rid of unbound methods
> Um, isn't all this stuff going to be more complicated and spread out over > more of the code than just leaving unbound methods in place? Well, in an early version of Python it was as simple as I'd like ot to be again: the instancemethod type was only used for bound methods (hence the name) and C.f would return same the function object as C.__dict__["f"]. Apart from backwards compatibility with all the code that has grown cruft to deal with the fact that C.f is not a function object, I still see no reason why the current state of affairs is better. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's get rid of unbound methods
At 12:29 PM 1/5/05 -0500, Barry Warsaw wrote: On Wed, 2005-01-05 at 10:41, Glyph Lefkowitz wrote: > I think it would be reasonable to assign im_class only to functions > defined in class scope. The only serialization that would break in that > case is if your example had a 'del f' at the end. +1. If you're doing something funkier, then you can set that attribute yourself. -Barry Um, isn't all this stuff going to be more complicated and spread out over more of the code than just leaving unbound methods in place? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's get rid of unbound methods
At 04:30 PM 1/5/05 +, Armin Rigo wrote: Hi Guido, On Tue, Jan 04, 2005 at 10:28:03AM -0800, Guido van Rossum wrote: > Let's get rid of unbound methods. Is there any other use case for 'C.x' not returning the same as 'appropriate_super_class_of_C.__dict__["x"]' ? Er, classmethod would be one; a rather important one at that. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's get rid of unbound methods
Armin Rigo wrote: Hi Jim, On Tue, Jan 04, 2005 at 02:44:43PM -0500, Jim Fulton wrote: Actually, unbound builtin methods are a different type than bound builtin methods: Of course, but conceptually they are similar. You would still encounter the concept if you got an unbound builtin method. There are no such things as unbound builtin methods: list.append is list.__dict__['append'] True In other words 'list.append' just returns exactly the same object as stored in the list type's dict. Guido's proposal is to make Python methods behave in the same way. OK, interesting. I'm sold then. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
RE: [Python-Dev] Let's get rid of unbound methods
> duck typing? That's the Australian pronunciation of "duct taping". ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's get rid of unbound methods
On Wed, 2005-01-05 at 10:41, Glyph Lefkowitz wrote: > I think it would be reasonable to assign im_class only to functions > defined in class scope. The only serialization that would break in that > case is if your example had a 'del f' at the end. +1. If you're doing something funkier, then you can set that attribute yourself. -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's get rid of unbound methods
On Wed, 2005-01-05 at 10:37, Glyph Lefkowitz wrote: > One approach I have taken in order to avoid copiously over-documenting > every super() using class is to decouple different phases of > initialization by making __init__ as simple as possible (setting a few > attributes, resisting the temptation to calculate things), and then > providing class methods like '.fromString' or '.forUnserialize' that > create instances that have been completely constructed for a particular > purpose. That way the signatures are much more likely to line up across > inheritance hierarchies. Perhaps this should be a suggested "best > practice" when using super() as well? Yep, I've done the same thing. It's definitely a good practice. -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's get rid of unbound methods
Alex Martelli wrote: def f(*a): pass class C(object): pass class D(object): pass C.f = D.f = f If now we want C.f.im_class to differ from D.f.im_class then we need f to get copied implicitly when it's assigned to C.f (or, of course, when C.f is accessed... but THAT might be substantial overhead). OK, I guess, as long as we don't expect any further attribute setting on f to affect C.f or D.f (and I don't know of any real use case where that would be needed). You'd have to do a copy anyway, because f() is still a module-level callable entity. I also agree with Glyph that im_class should only really be set in the case of methods defined within the class block. Also, interestingly, removing unbound methods makes another thing possible. class A(object): def foo(self): pass class B(object): foo = A.foo class C(object): pass C.foo = A.foo I'd really like to avoid making copies of functions for the sake of reload() and edit-and-continue functionality. Currently we can track down everything that has a reference to foo, and replace it with newfoo. With copies, this would more difficult. Thanks, -Shane ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's get rid of unbound methods
Hi Guido, On Tue, Jan 04, 2005 at 10:28:03AM -0800, Guido van Rossum wrote: > Let's get rid of unbound methods. Is there any other use case for 'C.x' not returning the same as 'appropriate_super_class_of_C.__dict__["x"]' ? I guess it's too late now but it would have been nice if user-defined __get__() methods had the more obvious signature (self, instance) instead of (self, instance_or_None, cls=None). Given the amount of potential breakage people already pointed out I guess it is not reasonable to change that. Armin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's get rid of unbound methods
Hi Jim, On Tue, Jan 04, 2005 at 02:44:43PM -0500, Jim Fulton wrote: > >Actually, unbound builtin methods are a different type than bound > >builtin methods: > > Of course, but conceptually they are similar. You would still > encounter the concept if you got an unbound builtin method. There are no such things as unbound builtin methods: >>> list.append is list.__dict__['append'] True In other words 'list.append' just returns exactly the same object as stored in the list type's dict. Guido's proposal is to make Python methods behave in the same way. Armin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's get rid of unbound methods
On Wed, 2005-01-05 at 12:11 +0100, Alex Martelli wrote: > Hmmm, seems to me we'd need copies of the function object for this > purpose: For the stated use-case of serialization, only one copy would be necessary, and besides - even *I* don't use idioms as weird as the one you are suggesting very often ;). I think it would be reasonable to assign im_class only to functions defined in class scope. The only serialization that would break in that case is if your example had a 'del f' at the end. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's get rid of unbound methods
On Tue, 2005-01-04 at 22:12 -0500, Bob Ippolito wrote: > If you have a class hierarchy where this is a problem, it's probably > pretty fragile to begin with, and you should think about making it > simpler. I agree with James's rant almost entirely, but I like super() anyway. I think it is an indication not of a new weakness of super(), but of a long-standing weakness of __init__. One approach I have taken in order to avoid copiously over-documenting every super() using class is to decouple different phases of initialization by making __init__ as simple as possible (setting a few attributes, resisting the temptation to calculate things), and then providing class methods like '.fromString' or '.forUnserialize' that create instances that have been completely constructed for a particular purpose. That way the signatures are much more likely to line up across inheritance hierarchies. Perhaps this should be a suggested "best practice" when using super() as well? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's get rid of unbound methods
On 2005 Jan 05, at 04:42, Barry Warsaw wrote: On Tue, 2005-01-04 at 18:01, Jack Jansen wrote: But I'm more worried about losing the other information in an unbound method, specifically im_class. I would guess that info is useful to class browsers and such, or are there other ways to get at that? That would be my worry too. OTOH, we have function attributes now, so why couldn't we just stuff the class on the function's im_class attribute? Who'd be the wiser? (Could the same be done for im_self and im_func for backwards compatibility?) Hmmm, seems to me we'd need copies of the function object for this purpose: def f(*a): pass class C(object): pass class D(object): pass C.f = D.f = f If now we want C.f.im_class to differ from D.f.im_class then we need f to get copied implicitly when it's assigned to C.f (or, of course, when C.f is accessed... but THAT might be substantial overhead). OK, I guess, as long as we don't expect any further attribute setting on f to affect C.f or D.f (and I don't know of any real use case where that would be needed). Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's get rid of unbound methods
Tim Peters <[EMAIL PROTECTED]> wrote: > > [Tim Peters] > >> ... Unbound methods are used most often (IME) to call a > >> base-class method from a subclass, like > >> my_base.the_method(self, ...). > >> It's especially easy to forget to write `self, ` there, and the > >> exception msg then is quite focused because of that extra bit of > >> type checking. Otherwise I expect we'd see a more-mysterious > >> AttributeError or TypeError when the base method got around to > >> trying to do something with the bogus `self` passed to it. > > [Josiah Carlson] > > Agreed. > > Well, it's not that easy to agree with. Guido replied that most such > cases would raise an argument-count-mismatch exception instead. I > expect that's because he stopped working on Zope code, so actually > thinks it's odd again to see a gazillion methods like: > > class Registerer(my_base): > def register(*args, **kws): > my_base.register(*args, **kws) > > I bet he even presumes that if you chase such chains long enough, > you'll eventually find a register() method *somewhere* that actually > uses its arguments . If type checking is important, one can always add it using decorators. Then again, I would be willing to wager that most people wouldn't add it due to laziness, until it bites them for more than a few hours worth of debugging time. > > While it seems that super() is the 'modern pradigm' for this, > > I have been using base.method(self, ...) for years now, and have > > been quite happy with it. After attempting to convert my code to > > use the super() paradigm, and having difficulty, I discovered James > > Knight's "Python's Super Considered Harmful" (available at > > http://www.ai.mit.edu/people/jknight/super-harmful/ ), wherein I > > discovered how super really worked (I should have read the > > documention in the first place), and reverted my changes to the > > base.method version. > > How did super() get into this discussion? I don't think I've ever > used it myself, but I avoid fancy inheritance graphs in "my own" code, > so can live with anything. It was my misunderstanding of your statement in regards to base.method. I had thought that base.method(self, ...) would stop working, and attempted to discover how one would be able to get the equivalent back, regardless of the inheritance graph. > > I could live with it too, but I would probably use an equivalent of the > > following (with actual type checking): > > > > def mysuper(typ, obj): > >lm = list(o.__class__.__mro__) > >indx = lm.index(typ) > >if indx == 0: > >return obj > >return super(lm[indx-1], obj) > > > > All in all, I'm -0. I don't desire to replace all of my base.method > > with mysuper(base, obj).method, but if I must sacrifice > > convenience for the sake of making Python 2.5's implementation > > simpler, I guess I'll deal with it. My familiarity with grep's regular > > expressions leaves something to be desired, so I don't know how > > often base.method(self,...) is or is not used in the standard library. > > I think there may be a misunderstanding here. Guido isn't proposing > that base.method(self, ...) would stop working -- it would still work > fine. The result of base.method would still be a callable object: it > would no longer be of an "unbound method" type (it would just be a > function), and wouldn't do special checking on the first argument > passed to it anymore, but base.method(self, ...) would still invoke > the base class method. You wouldn't need to rewrite anything (unless > you're doing heavy-magic introspection, picking callables apart). Indeed, there was a misunderstanding on my part. I misunderstood your discussion of base.method(self, ...) to mean that such things would stop working. My apologies. - Josiah ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's get rid of unbound methods
On Tue, 2005-01-04 at 18:01, Jack Jansen wrote: > But I'm more worried about losing the other information in an unbound > method, specifically im_class. I would guess that info is useful to > class browsers and such, or are there other ways to get at that? That would be my worry too. OTOH, we have function attributes now, so why couldn't we just stuff the class on the function's im_class attribute? Who'd be the wiser? (Could the same be done for im_self and im_func for backwards compatibility?) quack-quack-ly y'rs, -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's get rid of unbound methods
On Jan 4, 2005, at 8:18 PM, Josiah Carlson wrote: Tim Peters <[EMAIL PROTECTED]> wrote: Guido wrote: Let's get rid of unbound methods. When class C defines a method [snip] Really? Unbound methods are used most often (IME) to call a base-class method from a subclass, like my_base.the_method(self, ...). It's especially easy to forget to write `self, ` there, and the exception msg then is quite focused because of that extra bit of type checking. Otherwise I expect we'd see a more-mysterious AttributeError or TypeError when the base method got around to trying to do something with the bogus `self` passed to it. Agreed. While it seems that super() is the 'modern paradigm' for this, I have been using base.method(self, ...) for years now, and have been quite happy with it. After attempting to convert my code to use the super() paradigm, and having difficulty, I discovered James Knight's "Python's Super Considered Harmful" (available at http://www.ai.mit.edu/people/jknight/super-harmful/ ), wherein I discovered how super really worked (I should have read the documention in the first place), and reverted my changes to the base.method version. How does removing the difference between unmount methods and base.method(self, ...) break anything at all if it was correct code in the first place? As far as I can tell, all it does is remove any restriction on what "self" is allowed to be. On another note - I don't agree with the "super considered harmful" rant at all. Yes, when you're using __init__ and __new__ of varying signatures in a complex class hierarchy, initialization is going to be one hell of a problem -- no matter which syntax you use. All super is doing is taking the responsibility of calculating the MRO away from you, and it works awfully well for the general case where a method of a given name has the same signature and the class hierarchies are not insane. If you have a class hierarchy where this is a problem, it's probably pretty fragile to begin with, and you should think about making it simpler. -bob ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's get rid of unbound methods
[Tim Peters] >> ... Unbound methods are used most often (IME) to call a >> base-class method from a subclass, like >> my_base.the_method(self, ...). >> It's especially easy to forget to write `self, ` there, and the >> exception msg then is quite focused because of that extra bit of >> type checking. Otherwise I expect we'd see a more-mysterious >> AttributeError or TypeError when the base method got around to >> trying to do something with the bogus `self` passed to it. [Josiah Carlson] > Agreed. Well, it's not that easy to agree with. Guido replied that most such cases would raise an argument-count-mismatch exception instead. I expect that's because he stopped working on Zope code, so actually thinks it's odd again to see a gazillion methods like: class Registerer(my_base): def register(*args, **kws): my_base.register(*args, **kws) I bet he even presumes that if you chase such chains long enough, you'll eventually find a register() method *somewhere* that actually uses its arguments . > While it seems that super() is the 'modern pradigm' for this, > I have been using base.method(self, ...) for years now, and have > been quite happy with it. After attempting to convert my code to > use the super() paradigm, and having difficulty, I discovered James > Knight's "Python's Super Considered Harmful" (available at > http://www.ai.mit.edu/people/jknight/super-harmful/ ), wherein I > discovered how super really worked (I should have read the > documention in the first place), and reverted my changes to the > base.method version. How did super() get into this discussion? I don't think I've ever used it myself, but I avoid fancy inheritance graphs in "my own" code, so can live with anything. > I could live with it too, but I would probably use an equivalent of the > following (with actual type checking): > > def mysuper(typ, obj): >lm = list(o.__class__.__mro__) >indx = lm.index(typ) >if indx == 0: >return obj >return super(lm[indx-1], obj) > > All in all, I'm -0. I don't desire to replace all of my base.method > with mysuper(base, obj).method, but if I must sacrifice > convenience for the sake of making Python 2.5's implementation > simpler, I guess I'll deal with it. My familiarity with grep's regular > expressions leaves something to be desired, so I don't know how > often base.method(self,...) is or is not used in the standard library. I think there may be a misunderstanding here. Guido isn't proposing that base.method(self, ...) would stop working -- it would still work fine. The result of base.method would still be a callable object: it would no longer be of an "unbound method" type (it would just be a function), and wouldn't do special checking on the first argument passed to it anymore, but base.method(self, ...) would still invoke the base class method. You wouldn't need to rewrite anything (unless you're doing heavy-magic introspection, picking callables apart). ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's get rid of unbound methods
Tim Peters <[EMAIL PROTECTED]> wrote: > Guido wrote: > > Let's get rid of unbound methods. When class C defines a method [snip] > Really? Unbound methods are used most often (IME) to call a > base-class method from a subclass, like my_base.the_method(self, ...). > It's especially easy to forget to write `self, ` there, and the > exception msg then is quite focused because of that extra bit of type > checking. Otherwise I expect we'd see a more-mysterious > AttributeError or TypeError when the base method got around to trying > to do something with the bogus `self` passed to it. Agreed. While it seems that super() is the 'modern paradigm' for this, I have been using base.method(self, ...) for years now, and have been quite happy with it. After attempting to convert my code to use the super() paradigm, and having difficulty, I discovered James Knight's "Python's Super Considered Harmful" (available at http://www.ai.mit.edu/people/jknight/super-harmful/ ), wherein I discovered how super really worked (I should have read the documention in the first place), and reverted my changes to the base.method version. > I could live with that, though. I could live with it too, but I would probably use an equivalent of the following (with actual type checking): def mysuper(typ, obj): lm = list(o.__class__.__mro__) indx = lm.index(typ) if indx == 0: return obj return super(lm[indx-1], obj) All in all, I'm -0. I don't desire to replace all of my base.method with mysuper(base, obj).method, but if I must sacrifice convenience for the sake of making Python 2.5's implementation simpler, I guess I'll deal with it. My familiarity with grep's regular expressions leaves something to be desired, so I don't know how often base.method(self,...) is or is not used in the standard library. - Josiah ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's get rid of unbound methods
On Jan 4, 2005, at 6:01 PM, Jack Jansen wrote: On 4-jan-05, at 19:28, Guido van Rossum wrote: The extra type checking on the first argument that unbound methods are supposed to provide is not useful in practice (I can't remember that it ever caught a bug in my code) It caught bugs for me a couple of times. If I remember correctly I was calling methods of something that was supposed to be a mixin class but I forgot to actually list the mixin as a base. But I don't think that's a serious enough issue alone to keep the unbound method type. But I'm more worried about losing the other information in an unbound method, specifically im_class. I would guess that info is useful to class browsers and such, or are there other ways to get at that? For a class browser, presumably, you would start at the class and then find the methods. Starting from some class and walking the mro, you can inspect the dicts along the way and you'll find everything and know where it came from. -bob ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's get rid of unbound methods
On 4-jan-05, at 19:28, Guido van Rossum wrote: The extra type checking on the first argument that unbound methods are supposed to provide is not useful in practice (I can't remember that it ever caught a bug in my code) It caught bugs for me a couple of times. If I remember correctly I was calling methods of something that was supposed to be a mixin class but I forgot to actually list the mixin as a base. But I don't think that's a serious enough issue alone to keep the unbound method type. But I'm more worried about losing the other information in an unbound method, specifically im_class. I would guess that info is useful to class browsers and such, or are there other ways to get at that? -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's get rid of unbound methods
At 11:40 AM 1/4/05 -0800, Guido van Rossum wrote: [Jim] > We'll still need unbound builtin methods, so the concept won't > go away. In fact, the change would mean that the behavior between > builtin methods and python methods would become more inconsistent. Actually, unbound builtin methods are a different type than bound builtin methods: >>> type(list.append) >>> type([].append) >>> Compare this to the same thing for a method on a user-defined class: >>> type(C.foo) >>> type(C().foo) (The 'instancemethod' type knows whether it is a bound or unbound method by checking whether im_self is set.) [Phillip] > Code that currently does 'aClass.aMethod.im_func' in order to access the > function object would break, as would code that inspects 'im_self' to > determine whether a method is a class or instance method. (Although code > of the latter sort would already break with static methods, I suppose.) Right. (But I think you're using the terminology in a cunfused way -- im_self distinguishes between bould and unbound methods. Class methods are a different beast.) IIUC, when you do 'SomeClass.aMethod', if 'aMethod' is a classmethod, then you will receive a bound method with an im_self of 'SomeClass'. So, if you are introspecting items listed in 'dir(SomeClass)', this will be your only clue that 'aMethod' is a class method. Similarly, the fact that you get an unbound method object if 'aMethod' is an instance method, allows you to distinguish it from a static method (if the object is a function). That is, I'm saying that code that looks at the type and attributes of 'aMethod' as retrieved from 'SomeClass' will now not be able to distinguish between a static method and an instance method, because both will return a function instance. However, the 'inspect' module uses __dict__ rather than getattr to get at least some attributes, so it doesn't rely on this property. I guess for backwards compatibility, function objects could implement dummy im_func and im_self attributes (im_func returning itself and im_self returning None), while issuing a warning that this is a deprecated feature. +1 on this part if the proposal goes through. On the proposal as a whole, I'm -0, as I'm not quite clear on what this is going to simplify enough to justify the various semantic impacts such as upcalls, pickling, etc. Method objects will still have to exist, so ISTM that this is only going to streamline the "__get__(None,type)" branch of functions' descriptor code, and the check for "im_self is None" in the __call__ of method objects. (And maybe some eval loop shortcuts for calling methods?) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's get rid of unbound methods
On Tue, 4 Jan 2005 12:18:15 -0800, Guido van Rossum <[EMAIL PROTECTED]> wrote: >[me] > > > Actually, unbound builtin methods are a different type than bound > > > builtin methods: > > [Jim] > > Of course, but conceptually they are similar. You would still > > encounter the concept if you got an unbound builtin method. > > Well, these are all just implementation details. They really are all > just callables. > > [Jp] > > This would make pickling (or any serialization mechanism) of > > `Class.method' based on name next to impossible. Right now, with > > the appropriate support, this works: > > > > >>> import pickle > > >>> class Foo: > > ... def bar(self): pass > > ... > > >>> pickle.loads(pickle.dumps(Foo.bar)) > > > > >>> > > > > I don't see how it could if Foo.bar were just a function object. > > Is this a purely theoretical objection or are you actually aware of > anyone doing this? Anyway, that approach is pretty limited -- how > would you do it for static and class methods, or methods wrapped by > other decorators? It's not a feature I often depend on, however I have made use of it on occassion. Twisted's supports serializing unbound methods this way, primarily to enhance the useability of tap files (a feature whereby an application is configured by constructing a Python object graph and then pickled to a file to later be loaded and run). "Objection" may be too strong a word for my stance here, I just wanted to point out another potentially incompatible behavior change. I can't think of any software which I cam currently developing or maintaining which benefits from this feature, it just seems unfortunate to further complicate the already unpleasant business of serialization. Jp ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's get rid of unbound methods
[me] > > Actually, unbound builtin methods are a different type than bound > > builtin methods: [Jim] > Of course, but conceptually they are similar. You would still > encounter the concept if you got an unbound builtin method. Well, these are all just implementation details. They really are all just callables. [Jp] > This would make pickling (or any serialization mechanism) of > `Class.method' based on name next to impossible. Right now, with > the appropriate support, this works: > > >>> import pickle > >>> class Foo: > ... def bar(self): pass > ... > >>> pickle.loads(pickle.dumps(Foo.bar)) > > >>> > > I don't see how it could if Foo.bar were just a function object. Is this a purely theoretical objection or are you actually aware of anyone doing this? Anyway, that approach is pretty limited -- how would you do it for static and class methods, or methods wrapped by other decorators? -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's get rid of unbound methods
On Tue, 04 Jan 2005 20:02:06 GMT, Jp Calderone <[EMAIL PROTECTED]> wrote: >On Tue, 4 Jan 2005 10:28:03 -0800, Guido van Rossum <[EMAIL PROTECTED]> wrote: > >In my blog I wrote: > > > > Let's get rid of unbound methods. When class C defines a method f, C.f > > should just return the function object, not an unbound method that > > behaves almost, but not quite, the same as that function object. The > > extra type checking on the first argument that unbound methods are > > supposed to provide is not useful in practice (I can't remember that > > it ever caught a bug in my code) and sometimes you have to work around > > it; it complicates function attribute access; and the overloading of > > unbound and bound methods on the same object type is confusing. Also, > > the type checking offered is wrong, because it checks for subclassing > > rather than for duck typing. > > > > This would make pickling (or any serialization mechanism) of > `Class.method' based on name next to impossible. Right now, with > the appropriate support, this works: It occurs to me that perhaps I was not clear enough here. What I mean is that it is possible to serialize unbound methods currently, because they refer to both their own name, the name of their class object, and thus indirectly to the module in which they are defined. If looking up a method on a class object instead returns a function, then the class is no longer knowable, and most likely the function will not have a unique name which can be used to allow a reference to it to be serialized. In particular, I don't see how one will be able to write something equivalent to this: import new, copy_reg, types def pickleMethod(method): return unpickleMethod, (method.im_func.__name__, method.im_self, method.im_class) def unpickleMethod(im_name, im_self, im_class): unbound = getattr(im_class, im_name) if im_self is None: return unbound return new.instancemethod(unbound.im_func, im_self, im_class) copy_reg.pickle(types.MethodType, pickleMethod, unpickleMethod) But perhaps I am just overlooking the obvious. Jp ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's get rid of unbound methods
On Tue, 4 Jan 2005 10:28:03 -0800, Guido van Rossum <[EMAIL PROTECTED]> wrote: >In my blog I wrote: > > Let's get rid of unbound methods. When class C defines a method f, C.f > should just return the function object, not an unbound method that > behaves almost, but not quite, the same as that function object. The > extra type checking on the first argument that unbound methods are > supposed to provide is not useful in practice (I can't remember that > it ever caught a bug in my code) and sometimes you have to work around > it; it complicates function attribute access; and the overloading of > unbound and bound methods on the same object type is confusing. Also, > the type checking offered is wrong, because it checks for subclassing > rather than for duck typing. > This would make pickling (or any serialization mechanism) of `Class.method' based on name next to impossible. Right now, with the appropriate support, this works: >>> import pickle >>> class Foo: ... def bar(self): pass ... >>> pickle.loads(pickle.dumps(Foo.bar)) >>> I don't see how it could if Foo.bar were just a function object. Jp ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's get rid of unbound methods
Guido van Rossum wrote: [Jim] We'll still need unbound builtin methods, so the concept won't go away. In fact, the change would mean that the behavior between builtin methods and python methods would become more inconsistent. Actually, unbound builtin methods are a different type than bound builtin methods: Of course, but conceptually they are similar. You would still encounter the concept if you got an unbound builtin method. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
RE: [Python-Dev] Let's get rid of unbound methods
[Guido van Rossum] > > Let's get rid of unbound methods. +1 [Jim Fulton] > duck typing? Requiring a specific interface instead of a specific type. [Guido] > > Does anyone think this is a bad idea? [Jim] > It *feels* very disruptive to me, but I'm probably wrong. > We'll still need unbound builtin methods, so the concept won't > go away. In fact, the change would mean that the behavior between > builtin methods and python methods would become more inconsistent. The type change would be disruptive and guaranteed to break some code. Also, it would partially breakdown the distinction between functions and methods. The behavior, on the other hand, would remain essentially the same (sans type checking). Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's get rid of unbound methods
[Jim] > We'll still need unbound builtin methods, so the concept won't > go away. In fact, the change would mean that the behavior between > builtin methods and python methods would become more inconsistent. Actually, unbound builtin methods are a different type than bound builtin methods: >>> type(list.append) >>> type([].append) >>> Compare this to the same thing for a method on a user-defined class: >>> type(C.foo) >>> type(C().foo) (The 'instancemethod' type knows whether it is a bound or unbound method by checking whether im_self is set.) [Phillip] > Code that currently does 'aClass.aMethod.im_func' in order to access the > function object would break, as would code that inspects 'im_self' to > determine whether a method is a class or instance method. (Although code > of the latter sort would already break with static methods, I suppose.) Right. (But I think you're using the terminology in a cunfused way -- im_self distinguishes between bould and unbound methods. Class methods are a different beast.) I guess for backwards compatibility, function objects could implement dummy im_func and im_self attributes (im_func returning itself and im_self returning None), while issuing a warning that this is a deprecated feature. [Tim] > Really? Unbound methods are used most often (IME) to call a > base-class method from a subclass, like my_base.the_method(self, ...). > It's especially easy to forget to write `self, ` there, and the > exception msg then is quite focused because of that extra bit of type > checking. Otherwise I expect we'd see a more-mysterious > AttributeError or TypeError when the base method got around to trying > to do something with the bogus `self` passed to it. Hm, I hadn't thought ot this. > I could live with that, though. Most cases would be complaints about argument counts (it gets harier when there are default args so the arg count is variable). Ironically, I get those all the time these days due to the reverse error: using super() but forgetting *not* to pass self! > Across the Python, Zope2 and Zope3 code bases, types.UnboundMethodType > is defined once and used once (believe it or not, in unittest.py). But that might be because BoundMethodType is the same type object... -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's get rid of unbound methods
Phillip J. Eby wrote: At 10:28 AM 1/4/05 -0800, Guido van Rossum wrote: Of course, more changes would be needed: docs, the test suite, and some simplifications to the instance method object implementation in classobject.c. Does anyone think this is a bad idea? Code that currently does 'aClass.aMethod.im_func' in order to access the function object would break, as would code that inspects 'im_self' to determine whether a method is a class or instance method. (Although code of the latter sort would already break with static methods, I suppose.) Code of the latter sort wouldn't break with the change. We'd still have bound methods. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's get rid of unbound methods
[Guido] > In my blog I wrote: > > Let's get rid of unbound methods. When class C defines a method > f, C.f should just return the function object, not an unbound > method that behaves almost, but not quite, the same as that > function object. The extra type checking on the first argument that > unbound methods are supposed to provide is not useful in practice > (I can't remember that it ever caught a bug in my code) Really? Unbound methods are used most often (IME) to call a base-class method from a subclass, like my_base.the_method(self, ...). It's especially easy to forget to write `self, ` there, and the exception msg then is quite focused because of that extra bit of type checking. Otherwise I expect we'd see a more-mysterious AttributeError or TypeError when the base method got around to trying to do something with the bogus `self` passed to it. I could live with that, though. > and sometimes you have to work around it; For me, 0 times in ... what? ... about 14 years . > it complicates function attribute access; and the overloading of > unbound and bound methods on the same object type is > confusing. Yup, it is a complication, without a compelling use case I know of. Across the Python, Zope2 and Zope3 code bases, types.UnboundMethodType is defined once and used once (believe it or not, in unittest.py). ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's get rid of unbound methods
At 01:36 PM 1/4/05 -0500, Jim Fulton wrote: duck typing? AKA latent typing or, "if it walks like a duck and quacks like a duck, it must be a duck." Or, more pythonically: if hasattr(ob,"quack") and hasattr(ob,"duckwalk"): # it's a duck This is as distinct from both 'if isinstance(ob,Duck)' and 'if implements(ob,IDuck)'. That is, "duck typing" is determining an object's type by inspection of its method/attribute signature rather than by explicit relationship to some type object. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's get rid of unbound methods
At 10:28 AM 1/4/05 -0800, Guido van Rossum wrote: Of course, more changes would be needed: docs, the test suite, and some simplifications to the instance method object implementation in classobject.c. Does anyone think this is a bad idea? Code that currently does 'aClass.aMethod.im_func' in order to access the function object would break, as would code that inspects 'im_self' to determine whether a method is a class or instance method. (Although code of the latter sort would already break with static methods, I suppose.) Cursory skimming of the first 100 Google hits for 'im_func' seems to show at least half a dozen instances of the first type of code, though. Such code would also be in the difficult position of having to do things two ways in order to be both forward and backward compatible. Also, I seem to recall once having relied on the behavior of a dynamically-created unbound method (via new.instancemethod) in order to create a descriptor of some sort. But I don't remember where or when I did it or whether I still care. :) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's get rid of unbound methods
On Tue, Jan 04, 2005, Jim Fulton wrote: > Guido van Rossum wrote: >> >> and the overloading of >>unbound and bound methods on the same object type is confusing. Also, >>the type checking offered is wrong, because it checks for subclassing >>rather than for duck typing. > > duck typing? "If it looks like a duck and quacks like a duck, it must be a duck." Python is often referred to as having duck typing because even without formal interface declarations, good practice mostly depends on conformant interfaces rather than subclassing to determine an object's type. -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "19. A language that doesn't affect the way you think about programming, is not worth knowing." --Alan Perlis ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's get rid of unbound methods
On Tue, Jan 04, 2005 at 10:28:03AM -0800, Guido van Rossum wrote: > In my blog I wrote: > > Let's get rid of unbound methods. When class C defines a method f, C.f > should just return the function object, not an unbound method that > behaves almost, but not quite, the same as that function object. The > extra type checking on the first argument that unbound methods are > supposed to provide is not useful in practice (I can't remember that > it ever caught a bug in my code) and sometimes you have to work around > it; it complicates function attribute access; and the overloading of > unbound and bound methods on the same object type is confusing. Also, > the type checking offered is wrong, because it checks for subclassing > rather than for duck typing. > > Does anyone think this is a bad idea? Anyone want to run with it? > I like the idea, it means I can get rid of this[1] func = getattr(cls, 'do_command', None) setattr(cls, 'do_command', staticmethod(func.im_func)) # don't let anyone on c.l.py see this .. or at least change the comment *grin*, -Jack [1] http://cvs.sourceforge.net/viewcvs.py/lyntin/lyntin40/sandbox/leantin/mudcommands.py?view=auto ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's get rid of unbound methods
On Jan 4, 2005, at 1:28 PM, Guido van Rossum wrote: Let's get rid of unbound methods. When class C defines a method f, C.f should just return the function object, not an unbound method that behaves almost, but not quite, the same as that function object. The extra type checking on the first argument that unbound methods are supposed to provide is not useful in practice (I can't remember that it ever caught a bug in my code) and sometimes you have to work around it; it complicates function attribute access; and the overloading of unbound and bound methods on the same object type is confusing. Also, the type checking offered is wrong, because it checks for subclassing rather than for duck typing. +1 I like this idea. It may have some effect on current versions of PyObjC though, because we really do care about what self is in order to prevent crashes. This is not a discouragement; we are already using custom descriptors and a metaclass, so it won't be a problem to do this ourselves if we are not doing it already. I'll try and find some time later in the week to play with this patch to see if it does break PyObjC or not. If it breaks PyObjC, I can sure that PyObjC 1.3 will be compatible with such a runtime change, as we're due for a refactoring in that area anyway. -bob ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's get rid of unbound methods
Guido van Rossum wrote:
In my blog I wrote:
Let's get rid of unbound methods. When class C defines a method f, C.f
should just return the function object, not an unbound method that
behaves almost, but not quite, the same as that function object. The
extra type checking on the first argument that unbound methods are
supposed to provide is not useful in practice (I can't remember that
it ever caught a bug in my code) and sometimes you have to work around
it; it complicates function attribute access;
I think this is probably a good thing as it potentially avoids
some unintential aliasing.
> and the overloading of
unbound and bound methods on the same object type is confusing. Also,
the type checking offered is wrong, because it checks for subclassing
rather than for duck typing.
duck typing?
This is a really simple change to begin with:
*** funcobject.c 28 Oct 2004 16:32:00 - 2.67
--- funcobject.c 4 Jan 2005 18:23:42 -
***
*** 564,571
static PyObject *
func_descr_get(PyObject *func, PyObject *obj, PyObject *type)
{
! if (obj == Py_None)
! obj = NULL;
return PyMethod_New(func, obj, type);
}
--- 564,573
static PyObject *
func_descr_get(PyObject *func, PyObject *obj, PyObject *type)
{
! if (obj == NULL || obj == Py_None) {
! Py_INCREF(func);
! return func;
! }
return PyMethod_New(func, obj, type);
}
There are some test suite failures but I suspect they all have to do
with checking this behavior.
Of course, more changes would be needed: docs, the test suite, and
some simplifications to the instance method object implementation in
classobject.c.
Does anyone think this is a bad idea?
It *feels* very disruptive to me, but I'm probably wrong.
We'll still need unbound builtin methods, so the concept won't
go away. In fact, the change would mean that the behavior between
builtin methods and python methods would become more inconsistent.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Let's get rid of unbound methods
In my blog I wrote:
Let's get rid of unbound methods. When class C defines a method f, C.f
should just return the function object, not an unbound method that
behaves almost, but not quite, the same as that function object. The
extra type checking on the first argument that unbound methods are
supposed to provide is not useful in practice (I can't remember that
it ever caught a bug in my code) and sometimes you have to work around
it; it complicates function attribute access; and the overloading of
unbound and bound methods on the same object type is confusing. Also,
the type checking offered is wrong, because it checks for subclassing
rather than for duck typing.
This is a really simple change to begin with:
*** funcobject.c28 Oct 2004 16:32:00 - 2.67
--- funcobject.c4 Jan 2005 18:23:42 -
***
*** 564,571
static PyObject *
func_descr_get(PyObject *func, PyObject *obj, PyObject *type)
{
! if (obj == Py_None)
! obj = NULL;
return PyMethod_New(func, obj, type);
}
--- 564,573
static PyObject *
func_descr_get(PyObject *func, PyObject *obj, PyObject *type)
{
! if (obj == NULL || obj == Py_None) {
! Py_INCREF(func);
! return func;
! }
return PyMethod_New(func, obj, type);
}
There are some test suite failures but I suspect they all have to do
with checking this behavior.
Of course, more changes would be needed: docs, the test suite, and
some simplifications to the instance method object implementation in
classobject.c.
Does anyone think this is a bad idea? Anyone want to run with it?
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
