Re: "Super()" confusion
On Feb 10, 9:19 am, "Gabriel Genellina"
wrote:
> You really should push them to be included in python.org, even in their
> unfinished form. (At least a link in the wiki pages). Their visibility is
> almost null now.
It looks like I made an unfortunate choice with the
title ("Things to Know about Super"). I have just changed
it to "Things to Know about *Python* Super" so that now
googling for "python super" should hopefully find them.
I agree that the real solution would be to publish on python.org, but
for that I have to write yet another paper about Python 3.0 super, cut
things about old version/bugs of Python, re-read the whole beast, and
convince the core developers to publish it (which is not automatic).
That is some work, and I have many other projects going on right now.
Truth is, discussions about super do not come out so often, and most
people don't care.
> They're very clearly written - I wish you had published them years ago!
Me too, but you know what happens when working for free and without
deadlines ;)
> again, you really should publish the
> series in a more prominent place.
Soon or later I will go back to super in Python 3.0, but now I am
working on my Scheme series, I have yet to translate two articles of
my "Mixins considered harmful" series, and I have at least two other
articles which has been waiting publication for more than one year.
Plus, I have a full time job ;)
But if you and others keep bugging me something may happen ...
Michele Simionato
--
http://mail.python.org/mailman/listinfo/python-list
Re: "Super()" confusion
En Wed, 11 Feb 2009 00:31:06 -0200, Benjamin Kaplan escribió: On Tue, Feb 10, 2009 at 9:25 PM, Daniel Fetchinson < fetchin...@googlemail.com> wrote: Okay, I think we converged to a common denominator. I agree with you that the documentation needs additions about super and I also agree with you that referring to both MS and JK articles is appropriate when a question about super comes up. It's good to have a discussion when views actually converge and not diverge at the end :) Wait, that's not supposed to happen. This is Usenet after all. Quick, someone comment on the GIL! Our resident trolls are sleeping, it seems... -- Gabriel Genellina -- http://mail.python.org/mailman/listinfo/python-list
Re: "Super()" confusion
On Tue, Feb 10, 2009 at 9:25 PM, Daniel Fetchinson < fetchin...@googlemail.com> wrote: > >>> Consider whether you really need to use super(). > >>> http://fuhm.net/super-harmful/ > > Because throwing around that link carries about the same amount of > information as "perl is better than python", "my IDE is better than > yours", "vim rulez!", "emacs is cooler than vim", etc, etc. > >>> > >>> Not at all. It contains accurate and valuable information that isn't > >>> available elsewhere. > >> > >> But does not contain other valuable information which would demystify > >> super. If only this source is shown to a person who wants to learn the > >> proper usage of super, the impression he/she gets will be distorted. > > > > Why so? At the end there is a "best practices" recipe that pretty much > > summarizes the proper usage of super, and AFAIK it's the right way to use > > it. Don't you agree with any of the conclusions? > > > >> Example: 1. somebody asks about threading 2. reply comes: there is a > >> GIL! you can't do real threading. Now this reply might be technically > >> more-or-less correct, it is misleading and does not help the poster. > >> An informed discussion of the various solutions that does not involve > >> a rant about the GIL would be very useful though. > > > > As I said, the article presents a "recipe" for super() usage, and I'd > > consider it very helpful. It's far from just saying "super s*cks!", or > > "the GIL s*cks!" or something like that. > > > >> You might want to start with > >> > >> http://www.artima.com/weblogs/viewpost.jsp?thread=236275 > > > > ...which, although the author says it was written a long time ago, was > not > > published until less than six months ago, and has very low visibility. > > > >> You are right, it's not in the documentation. But if somebody asks on > >> c.l.p the appropriate answer, I think, is to point to information such > >> as the one above, and not the misleading "harmful" essay. > > > > According to Google, nobody has menctioned the "harmful" essay in this > > group since April 2008 [1], months before Simionato's article were > > available... So this is the *first* time the reference to the former > essay > > could have been replaced by M.S.' one... don't be so strict! > > > > Anyway, the right thing to do, IMHO, is to publish correct and accurate > > documentation in the main Python site. Not everybody knows about this > > group existence, nor has the time/experience/interest on subscribe here, > > post a question and wait for an answer. I've seen some posts in > python-dev > > saying something like "this is confusing, we should evangelize people on > > c.l.p. on the right way to do it" and I completely disagree; the right > > place for such things is the product documentation, or -to a much lesser > > degree because it's online only- some article collection linked from the > > main site (like the "Other resources" left bar, already present). > > > Honestly, I don't understand how this thing got so much out of > control. If anyone starts an intelligent question or remark about > super, this essay is thrown in no matter what. Anyone can explain why? > >>> > >>> Because for a very loong time (seven years, 2001-2008) super was > >>> almost undocumented. The Library Reference -before release 2.6- only > >>> had a short paragraph, the [...] > >> > >> You are right, the documentation needs some work in this regard. But > >> again, just because some sources are not in the documentation doesn't > >> mean that the most opinionated essay is the best source. A little > >> search turns up much more useful ones. > > > > (not according to Google [2]: I get the "harmful" article in the top, the > > thread in python-dev, a couple threads in c.l.p including posts by M.S., > > his article in artima, and nothing more relevant than "Monty Python Super > > Star" up to the 3rd page) > > > > *Now* that *I* am aware of the recent article series by M.S., the next > > time someone asks *me* about super(), probably I'll refer her to both > M.S. > > and J.K.'s articles. Last time I checked (perhaps one or two years ago), > > the "harmful" article was almost the only relevant source of info about > > super(). > > > > [1] > > > http://groups.google.com/group/comp.lang.python/search?q=super+harmful&start=0&scoring=d&; > > [2] http://www.google.com/search?q=python+super > > Okay, I think we converged to a common denominator. I agree with you > that the documentation needs additions about super and I also agree > with you that referring to both MS and JK articles is appropriate when > a question about super comes up. > > It's good to have a discussion when views actually converge and not > diverge at the end :) Wait, that's not supposed to happen. This is Usenet after all. Quick, someone comment on the GIL! -- > Psss, psss, put it down! - http://www.cafepress.com/putitdown > -- > http://mail.python.org/mailman/listinfo/python-list >
Re: "Super()" confusion
>>> Consider whether you really need to use super(). >>> http://fuhm.net/super-harmful/ Because throwing around that link carries about the same amount of information as "perl is better than python", "my IDE is better than yours", "vim rulez!", "emacs is cooler than vim", etc, etc. >>> >>> Not at all. It contains accurate and valuable information that isn't >>> available elsewhere. >> >> But does not contain other valuable information which would demystify >> super. If only this source is shown to a person who wants to learn the >> proper usage of super, the impression he/she gets will be distorted. > > Why so? At the end there is a "best practices" recipe that pretty much > summarizes the proper usage of super, and AFAIK it's the right way to use > it. Don't you agree with any of the conclusions? > >> Example: 1. somebody asks about threading 2. reply comes: there is a >> GIL! you can't do real threading. Now this reply might be technically >> more-or-less correct, it is misleading and does not help the poster. >> An informed discussion of the various solutions that does not involve >> a rant about the GIL would be very useful though. > > As I said, the article presents a "recipe" for super() usage, and I'd > consider it very helpful. It's far from just saying "super s*cks!", or > "the GIL s*cks!" or something like that. > >> You might want to start with >> >> http://www.artima.com/weblogs/viewpost.jsp?thread=236275 > > ...which, although the author says it was written a long time ago, was not > published until less than six months ago, and has very low visibility. > >> You are right, it's not in the documentation. But if somebody asks on >> c.l.p the appropriate answer, I think, is to point to information such >> as the one above, and not the misleading "harmful" essay. > > According to Google, nobody has menctioned the "harmful" essay in this > group since April 2008 [1], months before Simionato's article were > available... So this is the *first* time the reference to the former essay > could have been replaced by M.S.' one... don't be so strict! > > Anyway, the right thing to do, IMHO, is to publish correct and accurate > documentation in the main Python site. Not everybody knows about this > group existence, nor has the time/experience/interest on subscribe here, > post a question and wait for an answer. I've seen some posts in python-dev > saying something like "this is confusing, we should evangelize people on > c.l.p. on the right way to do it" and I completely disagree; the right > place for such things is the product documentation, or -to a much lesser > degree because it's online only- some article collection linked from the > main site (like the "Other resources" left bar, already present). > Honestly, I don't understand how this thing got so much out of control. If anyone starts an intelligent question or remark about super, this essay is thrown in no matter what. Anyone can explain why? >>> >>> Because for a very loong time (seven years, 2001-2008) super was >>> almost undocumented. The Library Reference -before release 2.6- only >>> had a short paragraph, the [...] >> >> You are right, the documentation needs some work in this regard. But >> again, just because some sources are not in the documentation doesn't >> mean that the most opinionated essay is the best source. A little >> search turns up much more useful ones. > > (not according to Google [2]: I get the "harmful" article in the top, the > thread in python-dev, a couple threads in c.l.p including posts by M.S., > his article in artima, and nothing more relevant than "Monty Python Super > Star" up to the 3rd page) > > *Now* that *I* am aware of the recent article series by M.S., the next > time someone asks *me* about super(), probably I'll refer her to both M.S. > and J.K.'s articles. Last time I checked (perhaps one or two years ago), > the "harmful" article was almost the only relevant source of info about > super(). > > [1] > http://groups.google.com/group/comp.lang.python/search?q=super+harmful&start=0&scoring=d&; > [2] http://www.google.com/search?q=python+super Okay, I think we converged to a common denominator. I agree with you that the documentation needs additions about super and I also agree with you that referring to both MS and JK articles is appropriate when a question about super comes up. It's good to have a discussion when views actually converge and not diverge at the end :) Cheers, Daniel -- Psss, psss, put it down! - http://www.cafepress.com/putitdown -- http://mail.python.org/mailman/listinfo/python-list
Re: "Super()" confusion
En Tue, 10 Feb 2009 18:01:53 -0200, Daniel Fetchinson escribió: On 2/9/09, Gabriel Genellina wrote: En Mon, 09 Feb 2009 23:34:05 -0200, Daniel Fetchinson escribió: Consider whether you really need to use super(). http://fuhm.net/super-harmful/ Because throwing around that link carries about the same amount of information as "perl is better than python", "my IDE is better than yours", "vim rulez!", "emacs is cooler than vim", etc, etc. Not at all. It contains accurate and valuable information that isn't available elsewhere. But does not contain other valuable information which would demystify super. If only this source is shown to a person who wants to learn the proper usage of super, the impression he/she gets will be distorted. Why so? At the end there is a "best practices" recipe that pretty much summarizes the proper usage of super, and AFAIK it's the right way to use it. Don't you agree with any of the conclusions? Example: 1. somebody asks about threading 2. reply comes: there is a GIL! you can't do real threading. Now this reply might be technically more-or-less correct, it is misleading and does not help the poster. An informed discussion of the various solutions that does not involve a rant about the GIL would be very useful though. As I said, the article presents a "recipe" for super() usage, and I'd consider it very helpful. It's far from just saying "super s*cks!", or "the GIL s*cks!" or something like that. You might want to start with http://www.artima.com/weblogs/viewpost.jsp?thread=236275 ...which, although the author says it was written a long time ago, was not published until less than six months ago, and has very low visibility. You are right, it's not in the documentation. But if somebody asks on c.l.p the appropriate answer, I think, is to point to information such as the one above, and not the misleading "harmful" essay. According to Google, nobody has menctioned the "harmful" essay in this group since April 2008 [1], months before Simionato's article were available... So this is the *first* time the reference to the former essay could have been replaced by M.S.' one... don't be so strict! Anyway, the right thing to do, IMHO, is to publish correct and accurate documentation in the main Python site. Not everybody knows about this group existence, nor has the time/experience/interest on subscribe here, post a question and wait for an answer. I've seen some posts in python-dev saying something like "this is confusing, we should evangelize people on c.l.p. on the right way to do it" and I completely disagree; the right place for such things is the product documentation, or -to a much lesser degree because it's online only- some article collection linked from the main site (like the "Other resources" left bar, already present). Honestly, I don't understand how this thing got so much out of control. If anyone starts an intelligent question or remark about super, this essay is thrown in no matter what. Anyone can explain why? Because for a very loong time (seven years, 2001-2008) super was almost undocumented. The Library Reference -before release 2.6- only had a short paragraph, the [...] You are right, the documentation needs some work in this regard. But again, just because some sources are not in the documentation doesn't mean that the most opinionated essay is the best source. A little search turns up much more useful ones. (not according to Google [2]: I get the "harmful" article in the top, the thread in python-dev, a couple threads in c.l.p including posts by M.S., his article in artima, and nothing more relevant than "Monty Python Super Star" up to the 3rd page) *Now* that *I* am aware of the recent article series by M.S., the next time someone asks *me* about super(), probably I'll refer her to both M.S. and J.K.'s articles. Last time I checked (perhaps one or two years ago), the "harmful" article was almost the only relevant source of info about super(). [1] http://groups.google.com/group/comp.lang.python/search?q=super+harmful&start=0&scoring=d&; [2] http://www.google.com/search?q=python+super -- Gabriel Genellina -- http://mail.python.org/mailman/listinfo/python-list
Re: "Super()" confusion
On 10 Feb, 20:45, Jean-Paul Calderone wrote: > > It replaces one kind of repetition with another. I think each kind is > about as unpleasant. Has anyone gathered any data on the frequency of > changes of base classes as compared to the frequency of classes being > renamed? I don't think either happens very often, but it might be > interesting to see some numbers. Base class changes are less important than common derived class functionality. For example, I have employed the following style of class hierarchy in at least one system: class ResourceUsingClass: """ Stuff using some resource, like a file. Should we close the file when we're finished with it? Is that rude? Best not do it! """ def close(self): pass # Don't close anything! class SelfContainedResourceUsingClass(ResourceUsingClass): """ We don't care about keeping the resource open in this class. The user of the class should just need to call the close method. """ def close(self): ResourceUsingClass.close(self) # Now close the resource! I know that there would be other ways of solving this problem, but in this case, for every class we want to subclass and provide such functionality, we need to write a specific close method. With super, we can avoid being specific about the superclass, but we still need to write the method unless we define it in a mix-in which appears before the superclass in the method resolution order. I think this is the only real use I've found for super, mostly because, as you say, in most other situations it doesn't actually save anyone very much effort. Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: "Super()" confusion
> Consider whether you really need to use super(). > > http://fuhm.net/super-harmful/ Did you actually read that article, understood it, went through the tons of responses from python-dev team members, including Guido > > "Tons" of responses? This was mentioned already, but just to repeat: one good source, for example, apart from the python-dev list: http://www.artima.com/weblogs/viewpost.jsp?thread=236275 > I count 16, about a third of which are written by James Knight himself > (the author of the page you are ranting against), and of the remaining, > about half are low-to-zero information content, e.g. Tim Peter's joke > about renaming the page for better marketing value. > > It's especially telling that even Guido, the most vocal critic of the > article, is critical of the *title* but not the content. In his first > post, he says: "I agree with the best practices in James's > Conclusion...", and suggested that if the article was called "Multiple > Inheritance Pitfalls in Python" he'd be much happier. > > >>> Yes. Why the knee-jerk reaction? >> >> Because throwing around that link carries about the same amount of >> information as "perl is better than python", "my IDE is better than >> yours", "vim rulez!", "emacs is cooler than vim", etc, etc. > > This is clearly not the case when even the most vocal critic agrees with > the article's recommendations. > > >>> I simply pointed out a resource which might be helpful to someone >>> trying to learn to use super. >> >> It will certainly not be helpful to anyone trying to learn the usage of >> super. > > I've read it, and found it very useful. > > >> The person who wrote that essay is simply misunderstanding the >> concept, as has been explained countless times by the python dev team. > > "Countless". Is that more or less than the "tons of responses" above? > > >> Hence, it only increases confusion, adds to the noise and spreads false >> alarm. > > So you say. > > >> Honestly, I don't understand how this thing got so much out of control. >> If anyone starts an intelligent question or remark about super, this >> essay is thrown in no matter what. Anyone can explain why? > > Because inheritance is potentially confusing. Multiple inheritance is > even more confusing. Multiple inheritance with diamond diagrams even more > so, and multiple inheritance with diamond diagrams and non-cooperative > classes are simply impossible to get right. > > Because there are many pitfalls to inheritance in Python, and they aren't > obvious: who on earth would imagine that calling __init__ or __new__ with > positional arguments could be dangerous? James Knight's article is a well- > written, understandable description of some of them, in one place and > with a catchy title. Of course people are going to link to it. > > And finally, because people do wrongly get the impression that using > super will magically make those problems go away. I know this, because I > was one of them. > > (I went through the anger period, sure that Knight must be full of it. > How could anyone suggest that Guido made a super that isn't perfect? I > got past that once I realised just how complex inheritance actually is. > Currently I'm in denial, writing code with super and hoping that it will > Just Work but not pushing it too hard in case it doesn't.) > > > > -- > Steven > -- > http://mail.python.org/mailman/listinfo/python-list > -- Psss, psss, put it down! - http://www.cafepress.com/putitdown -- http://mail.python.org/mailman/listinfo/python-list
Re: "Super()" confusion
On 2/9/09, Gabriel Genellina wrote: > En Mon, 09 Feb 2009 23:34:05 -0200, Daniel Fetchinson > escribió: > >> Hello. I've been scouring the web looking for something to clear up a >> little confusion about the use of "super()" but haven't found >> anything >> that really helps. Here's my simple example: >> >> [snip] >> >> "super(Child,self).__init__(filePath) >> TypeError: super() argument 1 must be type, not classobj" >> >> What have I done wrong? Thanks in advance for any help. > > Consider whether you really need to use super(). > > http://fuhm.net/super-harmful/ Did you actually read that article, understood it, went through the tons of responses from python-dev team members, including Guido >>> >>> Yes. Why the knee-jerk reaction? >> >> Because throwing around that link carries about the same amount of >> information as "perl is better than python", "my IDE is better than >> yours", "vim rulez!", "emacs is cooler than vim", etc, etc. > > Not at all. It contains accurate and valuable information that isn't > available elsewhere. But does not contain other valuable information which would demystify super. If only this source is shown to a person who wants to learn the proper usage of super, the impression he/she gets will be distorted. Example: 1. somebody asks about threading 2. reply comes: there is a GIL! you can't do real threading. Now this reply might be technically more-or-less correct, it is misleading and does not help the poster. An informed discussion of the various solutions that does not involve a rant about the GIL would be very useful though. >>> I simply pointed out a resource which >>> might be helpful to someone trying to learn to use super. >> >> It will certainly not be helpful to anyone trying to learn the usage >> of super. The person who wrote that essay is simply misunderstanding >> the concept, as has been explained countless times by the python dev >> team. Hence, it only increases confusion, adds to the noise and >> spreads false alarm. > > AFAIK, all facts appearing in said article are still true (except for 3.x > which uses a shorter form). If super usage had been clearly documented in > the first place, this had not happened. > Perhaps you could point us to some resource explaining how is super > supposed to be used correctly? > And of those giving explanations in python-dev, nobody cared to add a > single word to the Python documentation for years. You might want to start with http://www.artima.com/weblogs/viewpost.jsp?thread=236275 You are right, it's not in the documentation. But if somebody asks on c.l.p the appropriate answer, I think, is to point to information such as the one above, and not the misleading "harmful" essay. >> Honestly, I don't understand how this thing got so much out of >> control. If anyone starts an intelligent question or remark about >> super, this essay is thrown in no matter what. Anyone can explain why? > > Because for a very loong time (seven years, 2001-2008) super was > almost undocumented. The Library Reference -before release 2.6- only had a > short paragraph, the online documentation referred (and still does) to the > original essay by Guido introducing descriptors, which is inaccurate and > outdated, and then the "... harmful" article was the only source of > information available. > Worse was the fate of packages and how they're imported: nobody "could be > bothered to spell that out" (sic); or how import works in general, still > barely documented (one has to dig into the PEP collection, trying to guess > what parts are truly implemented and what parts are only a wish...) You are right, the documentation needs some work in this regard. But again, just because some sources are not in the documentation doesn't mean that the most opinionated essay is the best source. A little search turns up much more useful ones. Cheers, Daniel -- Psss, psss, put it down! - http://www.cafepress.com/putitdown -- http://mail.python.org/mailman/listinfo/python-list
Re: "Super()" confusion
On Tue, 10 Feb 2009 19:40:56 + (UTC), Benjamin Peterson wrote: Marc 'BlackJack' Rintsch gmx.net> writes: On Tue, 10 Feb 2009 02:02:43 +, Benjamin Peterson wrote: > Jean-Paul Calderone divmod.com> writes: >> Consider whether you really need to use super(). >> >> http://fuhm.net/super-harmful/ > > This article chiefly deals with super()'s harm in multiple inteheritance > situations. For the simple case, though, like that presented by the OP, > I believe super() is perfect. But for the simple cases it is unnecessary because it was invented to deal with multiple inheritance problems. super() is great for single inheritance because it furthers the DRY principle (base classes are not scattered through the code), and rather ugly use of unbound methods. It replaces one kind of repetition with another. I think each kind is about as unpleasant. Has anyone gathered any data on the frequency of changes of base classes as compared to the frequency of classes being renamed? I don't think either happens very often, but it might be interesting to see some numbers. Jean-Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: "Super()" confusion
Marc 'BlackJack' Rintsch gmx.net> writes: > > On Tue, 10 Feb 2009 02:02:43 +, Benjamin Peterson wrote: > > > Jean-Paul Calderone divmod.com> writes: > >> Consider whether you really need to use super(). > >> > >> http://fuhm.net/super-harmful/ > > > > This article chiefly deals with super()'s harm in multiple inteheritance > > situations. For the simple case, though, like that presented by the OP, > > I believe super() is perfect. > > But for the simple cases it is unnecessary because it was invented to > deal with multiple inheritance problems. super() is great for single inheritance because it furthers the DRY principle (base classes are not scattered through the code), and rather ugly use of unbound methods. -- http://mail.python.org/mailman/listinfo/python-list
Re: "Super()" confusion
On Tue, 10 Feb 2009 02:11:10 -0800, Michele Simionato wrote: > Unfortunately there is no good solution. If you have a single > inheritance hierarchy and you do not use super, you make it impossible > for users of your hierarchy to subclass it by using multiple > inheritance in a cooperative way (this is not polite). So I'm impolite. :-) I'm using multiple inheritance only for mixin classes and even that quite seldom. No `super()` in my code. Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: "Super()" confusion
On Feb 10, 10:42 am, Marc 'BlackJack' Rintsch wrote: > On Tue, 10 Feb 2009 02:02:43 +, Benjamin Peterson wrote: > > Jean-Paul Calderone divmod.com> writes: > >> Consider whether you really need to use super(). > > >>http://fuhm.net/super-harmful/ > > > This article chiefly deals with super()'s harm in multiple inteheritance > > situations. For the simple case, though, like that presented by the OP, > > I believe super() is perfect. > > But for the simple cases it is unnecessary because it was invented to > deal with multiple inheritance problems. > > Ciao, > Marc 'BlackJack' Rintsch Unfortunately there is no good solution. If you have a single inheritance hierarchy and you do not use super, you make it impossible for users of your hierarchy to subclass it by using multiple inheritance in a cooperative way (this is not polite). OTOH, if you user super, your users must know about it, to avoid unexpected cooperation. It is all explained in the "super harmful" paper, which is a must read even if you only use single inheritance. -- http://mail.python.org/mailman/listinfo/python-list
Re: "Super()" confusion
On Tue, 10 Feb 2009 02:02:43 +, Benjamin Peterson wrote: > Jean-Paul Calderone divmod.com> writes: >> Consider whether you really need to use super(). >> >> http://fuhm.net/super-harmful/ > > This article chiefly deals with super()'s harm in multiple inteheritance > situations. For the simple case, though, like that presented by the OP, > I believe super() is perfect. But for the simple cases it is unnecessary because it was invented to deal with multiple inheritance problems. Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: "Super()" confusion
En Tue, 10 Feb 2009 03:26:20 -0200, Michele Simionato escribió: On Feb 10, 4:29 am, "Gabriel Genellina" > Honestly, I don't understand how this thing got so much out of > control. If anyone starts an intelligent question or remark about > super, this essay is thrown in no matter what. Anyone can explain why? Because for a very loong time (seven years, 2001-2008) super was almost undocumented. The Library Reference -before release 2.6- only had a short paragraph, the online documentation referred (and still does) to the original essay by Guido introducing descriptors, which is inaccurate and outdated, and then the "... harmful" article was the only source of information available. All right. This is way I made the effort of writing a comprehensive collection of all the tricky points about super I knew: http://www.artima.com/weblogs/viewpost.jsp?thread=236275 http://www.artima.com/weblogs/viewpost.jsp?thread=236278 http://www.artima.com/weblogs/viewpost.jsp?thread=237121 You really should push them to be included in python.org, even in their unfinished form. (At least a link in the wiki pages). Their visibility is almost null now. They're very clearly written - I wish you had published them years ago! Also see this thread on python-dev about the issue of super documentation: http://www.gossamer-threads.com/lists/python/dev/673833 Apart from a few remarks in the first posts, there is little criticism of your articles themselves. Looks like adding a section about Python 3 is the only important pending issue - again, you really should publish the series in a more prominent place. -- Gabriel Genellina -- http://mail.python.org/mailman/listinfo/python-list
Re: "Super()" confusion
On Feb 10, 4:29 am, "Gabriel Genellina" > AFAIK, all facts appearing in said article are still true (except for 3.x > which uses a shorter form). If super usage had been clearly documented in > the first place, this had not happened. > Perhaps you could point us to some resource explaining how is super > supposed to be used correctly? > And of those giving explanations in python-dev, nobody cared to add a > single word to the Python documentation for years. > > > Honestly, I don't understand how this thing got so much out of > > control. If anyone starts an intelligent question or remark about > > super, this essay is thrown in no matter what. Anyone can explain why? > > Because for a very loong time (seven years, 2001-2008) super was > almost undocumented. The Library Reference -before release 2.6- only had a > short paragraph, the online documentation referred (and still does) to the > original essay by Guido introducing descriptors, which is inaccurate and > outdated, and then the "... harmful" article was the only source of > information available. All right. This is way I made the effort of writing a comprehensive collection of all the tricky points about super I knew: http://www.artima.com/weblogs/viewpost.jsp?thread=236275 http://www.artima.com/weblogs/viewpost.jsp?thread=236278 http://www.artima.com/weblogs/viewpost.jsp?thread=237121 Also see this thread on python-dev about the issue of super documentation: http://www.gossamer-threads.com/lists/python/dev/673833 Michele Simionato -- http://mail.python.org/mailman/listinfo/python-list
Re: "Super()" confusion
On Mon, 09 Feb 2009 17:34:05 -0800, Daniel Fetchinson wrote: ... Consider whether you really need to use super(). http://fuhm.net/super-harmful/ >>> >>>Did you actually read that article, understood it, went through the >>>tons of responses from python-dev team members, including Guido "Tons" of responses? I count 16, about a third of which are written by James Knight himself (the author of the page you are ranting against), and of the remaining, about half are low-to-zero information content, e.g. Tim Peter's joke about renaming the page for better marketing value. It's especially telling that even Guido, the most vocal critic of the article, is critical of the *title* but not the content. In his first post, he says: "I agree with the best practices in James's Conclusion...", and suggested that if the article was called "Multiple Inheritance Pitfalls in Python" he'd be much happier. >> Yes. Why the knee-jerk reaction? > > Because throwing around that link carries about the same amount of > information as "perl is better than python", "my IDE is better than > yours", "vim rulez!", "emacs is cooler than vim", etc, etc. This is clearly not the case when even the most vocal critic agrees with the article's recommendations. >> I simply pointed out a resource which might be helpful to someone >> trying to learn to use super. > > It will certainly not be helpful to anyone trying to learn the usage of > super. I've read it, and found it very useful. > The person who wrote that essay is simply misunderstanding the > concept, as has been explained countless times by the python dev team. "Countless". Is that more or less than the "tons of responses" above? > Hence, it only increases confusion, adds to the noise and spreads false > alarm. So you say. > Honestly, I don't understand how this thing got so much out of control. > If anyone starts an intelligent question or remark about super, this > essay is thrown in no matter what. Anyone can explain why? Because inheritance is potentially confusing. Multiple inheritance is even more confusing. Multiple inheritance with diamond diagrams even more so, and multiple inheritance with diamond diagrams and non-cooperative classes are simply impossible to get right. Because there are many pitfalls to inheritance in Python, and they aren't obvious: who on earth would imagine that calling __init__ or __new__ with positional arguments could be dangerous? James Knight's article is a well- written, understandable description of some of them, in one place and with a catchy title. Of course people are going to link to it. And finally, because people do wrongly get the impression that using super will magically make those problems go away. I know this, because I was one of them. (I went through the anger period, sure that Knight must be full of it. How could anyone suggest that Guido made a super that isn't perfect? I got past that once I realised just how complex inheritance actually is. Currently I'm in denial, writing code with super and hoping that it will Just Work but not pushing it too hard in case it doesn't.) -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: "Super()" confusion
En Mon, 09 Feb 2009 23:34:05 -0200, Daniel Fetchinson escribió: Hello. I've been scouring the web looking for something to clear up a little confusion about the use of "super()" but haven't found anything that really helps. Here's my simple example: [snip] "super(Child,self).__init__(filePath) TypeError: super() argument 1 must be type, not classobj" What have I done wrong? Thanks in advance for any help. Consider whether you really need to use super(). http://fuhm.net/super-harmful/ Did you actually read that article, understood it, went through the tons of responses from python-dev team members, including Guido Yes. Why the knee-jerk reaction? Because throwing around that link carries about the same amount of information as "perl is better than python", "my IDE is better than yours", "vim rulez!", "emacs is cooler than vim", etc, etc. Not at all. It contains accurate and valuable information that isn't available elsewhere. I simply pointed out a resource which might be helpful to someone trying to learn to use super. It will certainly not be helpful to anyone trying to learn the usage of super. The person who wrote that essay is simply misunderstanding the concept, as has been explained countless times by the python dev team. Hence, it only increases confusion, adds to the noise and spreads false alarm. AFAIK, all facts appearing in said article are still true (except for 3.x which uses a shorter form). If super usage had been clearly documented in the first place, this had not happened. Perhaps you could point us to some resource explaining how is super supposed to be used correctly? And of those giving explanations in python-dev, nobody cared to add a single word to the Python documentation for years. Honestly, I don't understand how this thing got so much out of control. If anyone starts an intelligent question or remark about super, this essay is thrown in no matter what. Anyone can explain why? Because for a very loong time (seven years, 2001-2008) super was almost undocumented. The Library Reference -before release 2.6- only had a short paragraph, the online documentation referred (and still does) to the original essay by Guido introducing descriptors, which is inaccurate and outdated, and then the "... harmful" article was the only source of information available. Worse was the fate of packages and how they're imported: nobody "could be bothered to spell that out" (sic); or how import works in general, still barely documented (one has to dig into the PEP collection, trying to guess what parts are truly implemented and what parts are only a wish...) -- Gabriel Genellina -- http://mail.python.org/mailman/listinfo/python-list
Re: "Super()" confusion
Jean-Paul Calderone divmod.com> writes: > Consider whether you really need to use super(). > > http://fuhm.net/super-harmful/ This article chiefly deals with super()'s harm in multiple inteheritance situations. For the simple case, though, like that presented by the OP, I believe super() is perfect. -- http://mail.python.org/mailman/listinfo/python-list
Re: "Super()" confusion
On Mon, 9 Feb 2009 17:34:05 -0800, Daniel Fetchinson wrote: Hello. I've been scouring the web looking for something to clear up a little confusion about the use of "super()" but haven't found anything that really helps. Here's my simple example: [snip] "super(Child,self).__init__(filePath) TypeError: super() argument 1 must be type, not classobj" What have I done wrong? Thanks in advance for any help. Consider whether you really need to use super(). http://fuhm.net/super-harmful/ Did you actually read that article, understood it, went through the tons of responses from python-dev team members, including Guido Yes. Why the knee-jerk reaction? Because throwing around that link carries about the same amount of information as "perl is better than python", "my IDE is better than yours", "vim rulez!", "emacs is cooler than vim", etc, etc. That's not true. The page contains lots of information. I simply pointed out a resource which might be helpful to someone trying to learn to use super. It will certainly not be helpful to anyone trying to learn the usage of super. The person who wrote that essay is simply misunderstanding the concept, as has been explained countless times by the python dev team. Hence, it only increases confusion, adds to the noise and spreads false alarm. Quoting Guido, in whom you seem to place a lot of faith: Super is intended for use that are designed with method cooperation in mind, so I agree with the best practices in James's Conclusion: """ * Use it consistently, and document that you use it, as it is part of the external interface for your class, like it or not. * Never call super with anything but the exact arguments you received, unless you really know what you're doing. * When you use it on methods whose acceptable arguments can be altered on a subclass via addition of more optional arguments, always accept *args, **kw, and call super like "super(MyClass, self).currentmethod(alltheargsideclared, *args, **kwargs)". If you don't do this, forbid addition of optional arguments in subclasses. * Never use positional arguments in __init__ or __new__. Always use keyword args, and always call them as keywords, and always pass all keywords on to super. """ The original poster's code did not use it consistently, did not document its use, and used positional arguments in __init__. So according to Guido, the OP was misusing super. Why are you complaining that I pointed this out? Honestly, I don't understand how this thing got so much out of control. If anyone starts an intelligent question or remark about super, this essay is thrown in no matter what. Anyone can explain why? You're seriously overreacting. Jean-Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: "Super()" confusion
Hello. I've been scouring the web looking for something to clear up a little confusion about the use of "super()" but haven't found anything that really helps. Here's my simple example: [snip] "super(Child,self).__init__(filePath) TypeError: super() argument 1 must be type, not classobj" What have I done wrong? Thanks in advance for any help. >>> >>> Consider whether you really need to use super(). >>> >>> http://fuhm.net/super-harmful/ >> >>Did you actually read that article, understood it, went through the >>tons of responses from python-dev team members, including Guido > > Yes. Why the knee-jerk reaction? Because throwing around that link carries about the same amount of information as "perl is better than python", "my IDE is better than yours", "vim rulez!", "emacs is cooler than vim", etc, etc. > I simply pointed out a resource which > might be helpful to someone trying to learn to use super. It will certainly not be helpful to anyone trying to learn the usage of super. The person who wrote that essay is simply misunderstanding the concept, as has been explained countless times by the python dev team. Hence, it only increases confusion, adds to the noise and spreads false alarm. Honestly, I don't understand how this thing got so much out of control. If anyone starts an intelligent question or remark about super, this essay is thrown in no matter what. Anyone can explain why? Cheers, Daniel -- Psss, psss, put it down! - http://www.cafepress.com/putitdown -- http://mail.python.org/mailman/listinfo/python-list
Re: "Super()" confusion
On Mon, 9 Feb 2009 17:19:41 -0800, Daniel Fetchinson wrote: Hello. I've been scouring the web looking for something to clear up a little confusion about the use of "super()" but haven't found anything that really helps. Here's my simple example: [snip] "super(Child,self).__init__(filePath) TypeError: super() argument 1 must be type, not classobj" What have I done wrong? Thanks in advance for any help. Consider whether you really need to use super(). http://fuhm.net/super-harmful/ Did you actually read that article, understood it, went through the tons of responses from python-dev team members, including Guido Yes. Why the knee-jerk reaction? I simply pointed out a resource which might be helpful to someone trying to learn to use super. Jean-Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: "Super()" confusion
>>Hello. I've been scouring the web looking for something to clear up a >>little confusion about the use of "super()" but haven't found anything >>that really helps. Here's my simple example: >> >> [snip] >> >>"super(Child,self).__init__(filePath) >>TypeError: super() argument 1 must be type, not classobj" >> >>What have I done wrong? Thanks in advance for any help. > > Consider whether you really need to use super(). > > http://fuhm.net/super-harmful/ Did you actually read that article, understood it, went through the tons of responses from python-dev team members, including Guido, or simply read its title, did absolutely no serious thinking about it and go on throwing it around as if it would prove anything? I can't believe this "super( ) is harmful" BS is still alive, it grew to be a mature internet meme like the dancing hamster or star wars kid :) See (among tons of other writings): http://mail.python.org/pipermail/python-dev/2005-January/thread.html Cheers, Daniel -- Psss, psss, put it down! - http://www.cafepress.com/putitdown -- http://mail.python.org/mailman/listinfo/python-list
Re: "Super()" confusion
On Mon, 9 Feb 2009 16:18:34 -0800 (PST), Lionel wrote: On Feb 9, 4:04 pm, Jean-Paul Calderone wrote: On Mon, 9 Feb 2009 15:20:05 -0800 (PST), Lionel wrote: >Hello. I've been scouring the web looking for something to clear up a >little confusion about the use of "super()" but haven't found anything >that really helps. Here's my simple example: > [snip] >"super(Child,self).__init__(filePath) >TypeError: super() argument 1 must be type, not classobj" >What have I done wrong? Thanks in advance for any help. Consider whether you really need to use super(). http://fuhm.net/super-harmful/ Jean-Paul Yes, I came across that essay...and it scared me. Will my base class initializer always get called regardless of whether or not I use super ()? If so, does this occur prior to any code in my derived class initializer being executed (in other words, if I don't explicitly call "super()" in my derived class, am I guaranteed that the base class "__init__" has executed completely)? If so, then I guess I can forego the use of "super()" Neither the use nor disuse of super can guarantee any of these things. Old-style base method calling (ie, "Foo.bar(self, ...)" - as opposed to using super) is just as capable of causing these things to happen as is super *except* in the case of diamond inheritance. If you use either correctly, it will do what you want. It's just that using super correctly is a lot harder most of the time. Jean-Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: "Super()" confusion
On Mon, Feb 9, 2009 at 4:18 PM, Lionel wrote: > On Feb 9, 4:04 pm, Jean-Paul Calderone wrote: >> On Mon, 9 Feb 2009 15:20:05 -0800 (PST), Lionel >> wrote: >> >Hello. I've been scouring the web looking for something to clear up a >> >little confusion about the use of "super()" but haven't found anything >> >that really helps. Here's my simple example: >> >> > [snip] >> >> >"super(Child,self).__init__(filePath) >> >TypeError: super() argument 1 must be type, not classobj" >> >> >What have I done wrong? Thanks in advance for any help. >> >> Consider whether you really need to use super(). >> >> http://fuhm.net/super-harmful/ >> >> Jean-Paul > > Yes, I came across that essay...and it scared me. Will my base class > initializer always get called regardless of whether or not I use super > ()? No, it is not called unless you /explicitly/ call it (either using super() or manually via BaseClassName.__init__(self, other, args, here)) in your subclass' __init__ or you don't define an __init__ for your subclass (and it inherits __init__ from its first superclass). Cheers, Chris -- Follow the path of the Iguana... http://rebertia.com -- http://mail.python.org/mailman/listinfo/python-list
Re: "Super()" confusion
On Feb 9, 4:04 pm, Jean-Paul Calderone wrote: > On Mon, 9 Feb 2009 15:20:05 -0800 (PST), Lionel > wrote: > >Hello. I've been scouring the web looking for something to clear up a > >little confusion about the use of "super()" but haven't found anything > >that really helps. Here's my simple example: > > > [snip] > > >"super(Child,self).__init__(filePath) > >TypeError: super() argument 1 must be type, not classobj" > > >What have I done wrong? Thanks in advance for any help. > > Consider whether you really need to use super(). > > http://fuhm.net/super-harmful/ > > Jean-Paul Yes, I came across that essay...and it scared me. Will my base class initializer always get called regardless of whether or not I use super ()? If so, does this occur prior to any code in my derived class initializer being executed (in other words, if I don't explicitly call "super()" in my derived class, am I guaranteed that the base class "__init__" has executed completely)? If so, then I guess I can forego the use of "super()" -- http://mail.python.org/mailman/listinfo/python-list
Re: "Super()" confusion
On Mon, 9 Feb 2009 15:20:05 -0800 (PST), Lionel wrote: Hello. I've been scouring the web looking for something to clear up a little confusion about the use of "super()" but haven't found anything that really helps. Here's my simple example: [snip] "super(Child,self).__init__(filePath) TypeError: super() argument 1 must be type, not classobj" What have I done wrong? Thanks in advance for any help. Consider whether you really need to use super(). http://fuhm.net/super-harmful/ Jean-Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: "Super()" confusion
Lionel wrote: Hello. I've been scouring the web looking for something to clear up a little confusion about the use of "super()" but haven't found anything that really helps. Here's my simple example: class Parent: def __init__(self, filePath):... class Child(Parent): def __init__(self, filePath): super(Child,self).__init__(filePath) As I understand it, "super()" will invoke the initializer of the base class. There must be something wrong with the above syntax since I'm getting: "super(Child,self).__init__(filePath) TypeError: super() argument 1 must be type, not classobj" What have I done wrong? Thanks in advance for any help. To use super, you must work with descendants of "object". So, just change your first line to: class Parent(object): and you should find your world back in place. --Scott David Daniels scott.dani...@acm.org -- http://mail.python.org/mailman/listinfo/python-list
Re: "Super()" confusion
On 2009-02-09 17:20, Lionel wrote: Hello. I've been scouring the web looking for something to clear up a little confusion about the use of "super()" but haven't found anything that really helps. Here's my simple example: class Parent: def __init__(self, filePath): . . Do some processing with "filePath" . . class Child(Parent): def __init__(self, filePath): super(Child,self).__init__(filePath) . . Do some additional Child-specific processing on filePath . . As I understand it, "super()" will invoke the initializer of the base class. There must be something wrong with the above syntax since I'm getting: "super(Child,self).__init__(filePath) TypeError: super() argument 1 must be type, not classobj" What have I done wrong? Thanks in advance for any help. super() only works on the "new-style" classes introduced in Python 2.2. You need to make Parent subclass from object: class Parent(object): ... -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco -- http://mail.python.org/mailman/listinfo/python-list
