tag:blogger.com,1999:blog-3888382143307542639.post5810066586285153696..comments2023-02-02T03:36:20.483+00:00Comments on Lacking Rhoticity: CapPython, unbound methods and Python 3.0Mark Seabornhttp://www.blogger.com/profile/08046205947658697263noreply@blogger.comBlogger9125tag:blogger.com,1999:blog-3888382143307542639.post-57288767017744350262009-03-10T14:18:00.000+00:002009-03-10T14:18:00.000+00:00Mark, if you're listening, would you mind bringing...Mark, if you're listening, would you mind bringing this up on python-ideas@python.org? I'd like to have a discussion about this, but the comment section of a blog doesn't feel like a good place to have it. I am surprised by the fact that this matters to you so much -- I don't understand where the function object f gets its magic powers. So there is a lot to learn for me and the Python community about what it is that you do and need.Guido van Rossumhttps://www.blogger.com/profile/12821714508588242516noreply@blogger.comtag:blogger.com,1999:blog-3888382143307542639.post-2361600006531517242008-09-17T13:04:00.000+01:002008-09-17T13:04:00.000+01:00@David-Sarah: "Being able to call a superclass met...@David-Sarah: <I>"Being able to call a superclass method implementation on a subclass that has overridden that method, seems like an encapsulation violation."</I> - Yes, it is a limited encapsulation violation, at least for non-self references. (You would expect to be able to do this on "self".) Let's call this the "override override problem" (or maybe "underride"?).<BR/><BR/>Some background: Python has two mechanisms for calling a superclass's method implementation: super() (newer) and class attributes (older). If unbound methods did not accept subclasses they would not have been usable for this purpose in normal Python.<BR/><BR/>Ideally, class objects would not have attributes at all. It is a compromise for CapPython to rely on unbound methods' type check.<BR/><BR/>My answer to this particular "override override problem" for now is that it means you have to be careful about how you use inheritance. Suppose you have a class hierarchy defined in one module: classes C and D, where D overrides C's method. You don't want C's version of the method to be callable on instances of D by outside code. My answer is that you should "close off" C and D by not exporting the class objects themselves from the module and by only exporting the constructors.<BR/><BR/>There some other approaches but they are more complex and I'll leave them for another post.Mark Seabornhttps://www.blogger.com/profile/08046205947658697263noreply@blogger.comtag:blogger.com,1999:blog-3888382143307542639.post-37385642974250836822008-09-15T17:17:00.000+01:002008-09-15T17:17:00.000+01:00"Unbound method wrappers are just adding the check...<I>"Unbound method wrappers are just adding the check that builtin methods already do."</I><BR/><BR/>Ah, OK. So <A HREF="http://mail.python.org/pipermail/python-dev/2005-January/050685.html" REL="nofollow">the post I referenced</A> is completely wrong; <EM>all</EM> builtin methods are effectively unbound.<BR/><BR/>From the original post:<BR/><I>"Function f should only ever be used on instances of C and its subclasses."</I><BR/><BR/>Shouldn't that only be instances of exactly C? Being able to call a superclass method implementation on a subclass that has overridden that method, seems like an encapsulation violation. <BR/><BR/>(The Java VM design also has that problem, IIRC.)Daira Hopwoodhttps://www.blogger.com/profile/07786700719460528830noreply@blogger.comtag:blogger.com,1999:blog-3888382143307542639.post-67101961439714337492008-09-15T14:12:00.000+01:002008-09-15T14:12:00.000+01:00@David-Sarah: The same problem does not occur for ...@David-Sarah: The same problem does not occur for builtin methods such as list.append because these already apply a type check:<BR/><BR/>>>> class C(object): pass<BR/>>>> list.append(C(), 1)<BR/>TypeError: descriptor 'append' requires a 'list' object but received a 'C'<BR/><BR/>Builtin unbound methods have to check this otherwise the interpreter could crash. list.append is a primitive operation that depends on the list type's private representation.<BR/><BR/>Unbound method wrappers are just adding the check that builtin methods already do.Mark Seabornhttps://www.blogger.com/profile/08046205947658697263noreply@blogger.comtag:blogger.com,1999:blog-3888382143307542639.post-38271630810087190512008-09-15T04:43:00.000+01:002008-09-15T04:43:00.000+01:00If you were to post something about this to the py...If you were to post something about this to the python-3000 (at) python.org list, I'd back you up.Daira Hopwoodhttps://www.blogger.com/profile/07786700719460528830noreply@blogger.comtag:blogger.com,1999:blog-3888382143307542639.post-80923052515453091742008-09-15T04:40:00.000+01:002008-09-15T04:40:00.000+01:00Just like in JavaScript (modulo some differences t...Just like in JavaScript (modulo some differences that I don't think are important here), the syntax "C.method" is used both for access to methods of a class, and for any other field/property access. I suspect that it is difficult to distinguish between these statically, since references to classes are first-class values.<BR/><BR/>OTOH, I haven't looked at this for Python in nearly as much detail as for JavaScript, so don't take my word for it.Daira Hopwoodhttps://www.blogger.com/profile/07786700719460528830noreply@blogger.comtag:blogger.com,1999:blog-3888382143307542639.post-50329215519445427312008-09-15T02:07:00.000+01:002008-09-15T02:07:00.000+01:00I'll echo David-Sarah's comments.Can you write you...I'll echo David-Sarah's comments.<BR/><BR/>Can you write your static verifier to simply forbid the code from accessing unbound methods? e.g., forbid the syntax "C.method"? Seems like this would preserve the interoperability properties you're trying to achieve. Would this represent an unacceptable loss of functionality? Is there some reason why it's important to be able to use unbound methods?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3888382143307542639.post-31393900516814105432008-09-14T23:57:00.000+01:002008-09-14T23:57:00.000+01:00Hmm. Having looked at this in more detail, why doe...Hmm. Having looked at this in more detail, why does the same problem not occur even pre-Python-3.0 for builtin methods (which are <A HREF="http://mail.python.org/pipermail/python-dev/2005-January/050685.html" REL="nofollow">never unbound</A>).Daira Hopwoodhttps://www.blogger.com/profile/07786700719460528830noreply@blogger.comtag:blogger.com,1999:blog-3888382143307542639.post-72120054676817764482008-09-14T23:43:00.000+01:002008-09-14T23:43:00.000+01:00That's shocking. They are deliberately introducing...That's shocking. They are <EM>deliberately introducing</EM> exactly the problem that JavaScript has that makes it so difficult to create secure subsets of JavaScript.Daira Hopwoodhttps://www.blogger.com/profile/07786700719460528830noreply@blogger.com