On 2/9/09, Gabriel Genellina <gagsl-...@yahoo.com.ar> wrote: > En Mon, 09 Feb 2009 23:34:05 -0200, Daniel Fetchinson > <fetchin...@googlemail.com> 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 loooooong 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
