Re: noob question: "TypeError" wrong number of args
And thank you gentlemen for turning my somewhat banale question into a worthwhile discussion. :-) I shall not forget self ever again! -- http://mail.python.org/mailman/listinfo/python-list
Re: noob question: "TypeError" wrong number of args
Edward Elliott wrote: > bruno at modulix wrote: > >>Edward Elliott wrote: >> >>>Ah, well then, there's no need for a full-blown parser. It should >>>suffice to recognize a class definition and modify the parameter list of >>>every def indented one level further than that. >> >>won't do : >> >>class CounterExample(object): >> if compute_some_const_according_to_phase_of_moon(): >>def meth(...): >> do_something(self, 42) > > > Uuunn, you got me pardner. (cough, cough) my hands, they're so cold. > bruno? where'd you go, bruno? i can't see you anymore. are we back on > the farm? tell ma i love her. (clunk) > "We'll remember you foreever Eddy..." -- bruno desthuilliers python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in '[EMAIL PROTECTED]'.split('@')])" -- http://mail.python.org/mailman/listinfo/python-list
Re: noob question: "TypeError" wrong number of args
bruno at modulix wrote: > Edward Elliott wrote: >> Ah, well then, there's no need for a full-blown parser. It should >> suffice to recognize a class definition and modify the parameter list of >> every def indented one level further than that. > > won't do : > > class CounterExample(object): > if compute_some_const_according_to_phase_of_moon(): > def meth(...): > do_something(self, 42) Uuunn, you got me pardner. (cough, cough) my hands, they're so cold. bruno? where'd you go, bruno? i can't see you anymore. are we back on the farm? tell ma i love her. (clunk) -- http://mail.python.org/mailman/listinfo/python-list
Re: noob question: "TypeError" wrong number of args
Edward Elliott wrote: > Ben Finney wrote: > >>As I understand it, the point was not what the code does, but to give >>a sample input (a Python program) for the "simple text processor" you >>described to wade through. > > > Ah, well then, there's no need for a full-blown parser. It should suffice > to recognize a class definition and modify the parameter list of every def > indented one level further than that. won't do : class CounterExample(object): if compute_some_const_according_to_phase_of_moon(): def meth(...): do_something(self, 42) else: do_something_else(self) > Then pick out the static methods and > 'undo' those. don't forget classmethods... -- bruno desthuilliers python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in '[EMAIL PROTECTED]'.split('@')])" -- http://mail.python.org/mailman/listinfo/python-list
Re: noob question: "TypeError" wrong number of args
Ben Finney wrote: > Bruno Desthuilliers <[EMAIL PROTECTED]> writes: > > >>Ben Finney a écrit : >> >>>So now you're proposing that this be a special case when a >>>function is declared by that particular syntax, and it should be >>>different to when a function is created outside the class >>>definition and added as a method to the object at run-time. >>> >>>Thus breaking not only "explicit is better than implicit", >> >>This one can be subject to discussion. > > > All the assertions in 'import this' are subject to discussion. Of course - but that was not the point. I meant that having implicit self in methods would not break this assertion much more than the current strange mix of explicit declaration of self + implicit passing of self. > They're > even contradictory. That's the nature of Zen, isn't it ?-) (snip) >>I'm not yet ready to vote for Edward's proposition - as you say, it >>makes 'def statements into a class statement' a special case, and I >>don't like special cases too much (OTOH, there actually *are* >>special cases - __new__() being an example) - *but* it's not that >>silly either IMHO, and I think this should not be dismissed on a >>purely reactional basis. > > > My basis for rejecting the proposal is that it claims to offer net > simplicity, yet it breaks at least two of the admonishments that > simplify Python. One could also claim that the current scheme *actually* breaks explicit-implicit and special-case rules in that the instance is implicitely passed at call time for the bound methods special case - which is ok IMHO since practicallity-beats-purity. Also, FWIW, Edward's proposition can be justified (at least that's Edward's POV) by the first rule : beautiful is better than ugly !-) disclaimer : None of this is to be taken as the expression of my own position on this proposition... -- bruno desthuilliers python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in '[EMAIL PROTECTED]'.split('@')])" -- http://mail.python.org/mailman/listinfo/python-list
Re: noob question: "TypeError" wrong number of args
Ben Finney wrote: > As I understand it, the point was not what the code does, but to give > a sample input (a Python program) for the "simple text processor" you > described to wade through. Ah, well then, there's no need for a full-blown parser. It should suffice to recognize a class definition and modify the parameter list of every def indented one level further than that. Then pick out the static methods and 'undo' those. Can be done in one pass by keeping the class definition in memory until you've scanned the whole thing, then adding self where needed as you spit it back out. Implementation is left as an exercise for the reader. :) -- http://mail.python.org/mailman/listinfo/python-list
Re: noob question: "TypeError" wrong number of args
Edward Elliott <[EMAIL PROTECTED]> writes: > Marc 'BlackJack' Rintsch wrote: > > Edward Elliott wrote: > >> I can prove that assertion too: make a simple text processor that > >> reads Python source code and outputs the same source code with > >> only one change: insert the string 'self" as the first parameter > >> of every "def somemethod". Next run the output source code with > >> the normal Python > > > > Okay, let's start with writing a simple text processor for this > > little mess:: > > I didn't even try to wade through that morass of monocharacter > variables. Anyone wanna summarize the point of that code? As I understand it, the point was not what the code does, but to give a sample input (a Python program) for the "simple text processor" you described to wade through. -- \"I always had a repulsive need to be something more than | `\ human." -- David Bowie | _o__) | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: noob question: "TypeError" wrong number of args
Marc 'BlackJack' Rintsch wrote: > Edward Elliott wrote: >> I can prove that assertion too: make a simple text processor that reads >> Python source code and outputs the same source code with only one change: >> insert the string 'self" as the first parameter of every "def >> somemethod". Next run the output source code with the normal Python > > Okay, let's start with writing a simple text processor for this little > mess:: I didn't even try to wade through that morass of monocharacter variables. Anyone wanna summarize the point of that code? -- http://mail.python.org/mailman/listinfo/python-list
Re: noob question: "TypeError" wrong number of args
Ben Finney wrote: > My basis for rejecting the proposal is that it claims to offer net > simplicity, yet it breaks at least two of the admonishments that > simplify Python. As do other features of Python. Or did you forget the follow-up to the special cases "rule"? Special cases aren't special enough to break the rules. Although practicality beats purity. -- http://mail.python.org/mailman/listinfo/python-list
Re: noob question: "TypeError" wrong number of args
Ben Finney wrote: > Edward Elliott <[EMAIL PROTECTED]> writes: >> As long as we're trotting out aphorisms > > The ones I quoted were from Python. > >>> import this Yes I know where it's from. > You've misunderstood "don't repeat yourself". It advocates *one* > definition of any given thing in the code. You are advocating *zero* > definitions of 'self' in the code. It's implicitly defined by the language/runtime, so I shouldn't need to define it in my code. Doing so is duplication of effort, aka DRY. An implicit definition is not an empty definition. Where do the semantics of 'while' and 'for' come from? Same thing, it's implicit in the language. -- http://mail.python.org/mailman/listinfo/python-list
Re: noob question: "TypeError" wrong number of args
Bruno Desthuilliers <[EMAIL PROTECTED]> writes: > Ben Finney a écrit : > > So now you're proposing that this be a special case when a > > function is declared by that particular syntax, and it should be > > different to when a function is created outside the class > > definition and added as a method to the object at run-time. > > > > Thus breaking not only "explicit is better than implicit", > > This one can be subject to discussion. All the assertions in 'import this' are subject to discussion. They're even contradictory. > > but also "special cases aren't special enough to break the rules". > > Yeps, I think this is what I don't like here. > > > Still -1. > > I'm not yet ready to vote for Edward's proposition - as you say, it > makes 'def statements into a class statement' a special case, and I > don't like special cases too much (OTOH, there actually *are* > special cases - __new__() being an example) - *but* it's not that > silly either IMHO, and I think this should not be dismissed on a > purely reactional basis. My basis for rejecting the proposal is that it claims to offer net simplicity, yet it breaks at least two of the admonishments that simplify Python. -- \"My house is made out of balsa wood, so when I want to scare | `\ the neighborhood kids I lift it over my head and tell them to | _o__) get out of my yard or I'll throw it at them." -- Steven Wright | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: noob question: "TypeError" wrong number of args
Edward Elliott <[EMAIL PROTECTED]> writes: > As long as we're trotting out aphorisms The ones I quoted were from Python. >>> import this > how about DRY: Don't Repeat Yourself. The rule couldn't be clearer: > don't repeat your SELF. ;) Yet that's exactly what explicitly > declaring self does, forces me to needlessly repeat what everyone > already knows: methods take the object instance as their first > parameter. You've misunderstood "don't repeat yourself". It advocates *one* definition of any given thing in the code. You are advocating *zero* definitions of 'self' in the code. -- \ "No wonder I'm all confused; one of my parents was a woman, the | `\ other was a man." -- Ashleigh Brilliant | _o__) | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: noob question: "TypeError" wrong number of args
Marc 'BlackJack' Rintsch a écrit : (snip) > > Okay, let's start with writing a simple text processor for this little > mess:: > > def b(c): > def d(r, *s, **t): > print '***' > c(r, *s, **t) > return d > > What a nice, readable, highly pythonic code... (snip) -- http://mail.python.org/mailman/listinfo/python-list
Re: noob question: "TypeError" wrong number of args
In <[EMAIL PROTECTED]>, Edward Elliott wrote: > I can prove that assertion too: make a simple text processor that reads > Python source code and outputs the same source code with only one change: > insert the string 'self" as the first parameter of every "def somemethod". > Next run the output source code with the normal Python interpreter. > Everything functions *exactly* as before because the code is *exactly* the > same as what you would have written if you'd put the 'self's in there > manually. Now make the Python interpreter invoke this text processor as > the first step in processing source code. Voila, python + implicit self. Okay, let's start with writing a simple text processor for this little mess:: def b(c): def d(r, *s, **t): print '***' c(r, *s, **t) return d class A: @b def a(x, y, z): print y, z x.e(23) def e(u, v): print u, v class B: def e(v, w): print 'spam', v, w A.e = e x = A() x.a('answer', 42) e('eric', 'viking') A.a(x, 'ham', 'eggs') Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: noob question: "TypeError" wrong number of args
Edward Elliott a écrit : > bruno at modulix wrote: > >>Technically, they are still function objects. They are later wrapped >>into method descriptor objects (at lookup time IIRC, but ask a guru or >>read the doc to know for sure). And don't forget the case of nested >>functions... > > > I don't see how nested functions change anything. If they're nested in a > method, they can access self, but the name mapping is done at runtime. > Unless you mean a nested fucntion which is dynamically added as a method, > but that's the same case as the next one. > Nope. I just wanted to point out that just checking for def statements in the scope of a class statement is not enough to decide if it has to be treated as a method. (snip) > >>>Well I'm assuming the rules for when to put 'self' in the parameter list >>>are simple enough to be automated. >> >>They are still complex enough to require a real parser. And anyway, >>since this is a syntax change, this should be handled by the parser IMHO. > > I agree, but it's good to keep options in mind. regexp are not an option !-) > >>Honestly, I don't think it has much chance. I barely even notice typing >>'self' or 'cls', and I guess it's the same for most Python programmers >>- those who can't stand it probably use another language... And FWIW, I >>still prefer to keep consistency in functions definitions. > > I have no doubt that's true for a lot of people. Hell I probably prefer the > current approach because 1) it's not a big deal in practice, and 2) I can > use the shorter 'me' or 's' in place of self in my own code, which I > couldn't do under the change Now *this* would be a +1 !-) > (well, I could add 'me = self' as the first > statement of any method, but that's clumsy). My objections stem more from > an elegance standpoint. Of course elegance is in the eye of the beholder. Indeed... -- http://mail.python.org/mailman/listinfo/python-list
Re: noob question: "TypeError" wrong number of args
bruno at modulix wrote: > Technically, they are still function objects. They are later wrapped > into method descriptor objects (at lookup time IIRC, but ask a guru or > read the doc to know for sure). And don't forget the case of nested > functions... I don't see how nested functions change anything. If they're nested in a method, they can access self, but the name mapping is done at runtime. Unless you mean a nested fucntion which is dynamically added as a method, but that's the same case as the next one. >> If you're declaring >> methods outside the class and adding them dynamically, I think you would >> need to declare 'self' explicitly. > > Of course. Virtually *any* function can be set as a method[1] outside > the class statement scope, either directly on the class object or - with > manual wrapping - on an individual instance. And it's important to keep > this feature. I wouldn't dream otherwise. >> Well I'm assuming the rules for when to put 'self' in the parameter list >> are simple enough to be automated. > > They are still complex enough to require a real parser. And anyway, > since this is a syntax change, this should be handled by the parser IMHO. I agree, but it's good to keep options in mind. > Honestly, I don't think it has much chance. I barely even notice typing > 'self' or 'cls', and I guess it's the same for most Python programmers > - those who can't stand it probably use another language... And FWIW, I > still prefer to keep consistency in functions definitions. I have no doubt that's true for a lot of people. Hell I probably prefer the current approach because 1) it's not a big deal in practice, and 2) I can use the shorter 'me' or 's' in place of self in my own code, which I couldn't do under the change (well, I could add 'me = self' as the first statement of any method, but that's clumsy). My objections stem more from an elegance standpoint. Of course elegance is in the eye of the beholder. -- http://mail.python.org/mailman/listinfo/python-list
Re: noob question: "TypeError" wrong number of args
Edward Elliott wrote: > Bruno Desthuilliers wrote: > >>But then, constructs like: >> >>class Obj(object): >> def method(...): ... >> method = staticmethod(method) >> >>or it's newer syntactic-sugar-version would become somewhat more >>difficult to parse properly - but I admit that this is beyond my >>knowledge. > > > Hmm, that'll take some thought. I assume if you're making method static, > you don't declare a self parameter for it? Nope. But classmethods takes the class object as the first param (usually named 'cls'). > >>>e.g. when it sees "def method (a,b)" >> >>This has to be in a class statement - else it's shouldn't be touched. > > Exactly, that's why I called it method and not func. Technically, they are still function objects. They are later wrapped into method descriptor objects (at lookup time IIRC, but ask a guru or read the doc to know for sure). And don't forget the case of nested functions... > If you're declaring > methods outside the class and adding them dynamically, I think you would > need to declare 'self' explicitly. Of course. Virtually *any* function can be set as a method[1] outside the class statement scope, either directly on the class object or - with manual wrapping - on an individual instance. And it's important to keep this feature. (snip) >>>I can prove that assertion too: make a simple text processor that reads >>>Python source code and outputs the same source code with only one change: >>>insert the string 'self" as the first parameter of every "def >>>somemethod". >> >>Not so simple: you have plain functions (outside class statements), and >>inner functions (inside def statements), and classmethods, and statict >>methods, and some other corner cases (like __new__()) to take into >>acccount... > > > Well I'm assuming the rules for when to put 'self' in the parameter list are > simple enough to be automated. They are still complex enough to require a real parser. And anyway, since this is a syntax change, this should be handled by the parser IMHO. (snip) > >>You'll have to really prove it doesn't break anything else in the >>object model, have strong and articulate arguments to support your point >>(like proving this is really a common source of confusion for newbies), >>and I really doubt it'll be accepted anyway. But what... > > > It's definitely an uphill battle and I wonder if it's really worth the > effort. Honestly, I don't think it has much chance. I barely even notice typing 'self' or 'cls', and I guess it's the same for most Python programmers - those who can't stand it probably use another language... And FWIW, I still prefer to keep consistency in functions definitions. -- bruno desthuilliers python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in '[EMAIL PROTECTED]'.split('@')])" -- http://mail.python.org/mailman/listinfo/python-list
Re: noob question: "TypeError" wrong number of args
bruno at modulix wrote: > And of course propose an implementation - perhaps the compiler.ast could > be useful ? Ugh. Just when I thought I'd seen my last abstract syntax tree, one rears its ugly head. -- http://mail.python.org/mailman/listinfo/python-list
Re: noob question: "TypeError" wrong number of args
Bruno Desthuilliers wrote: > But then, constructs like: > > class Obj(object): >def method(...): ... >method = staticmethod(method) > > or it's newer syntactic-sugar-version would become somewhat more > difficult to parse properly - but I admit that this is beyond my > knowledge. Hmm, that'll take some thought. I assume if you're making method static, you don't declare a self parameter for it? If so, it shouldn't be hard, just have the parser mark the method as static or no as it parses, and when it reaches the end of the class insert 'self' for non-static methods. If a normal method can be converted to a static method outside the class definition, that case should work just as it does now. >> e.g. when it sees "def method (a,b)" > > This has to be in a class statement - else it's shouldn't be touched. Exactly, that's why I called it method and not func. If you're declaring methods outside the class and adding them dynamically, I think you would need to declare 'self' explicitly. I'm ok with this because 1) when you're going that route, an explicit signal that something "different" is happening is a good thing, and 2) I have no problem with optimizing for the common case. Not everyone will agree on these points, obviously. >> I can prove that assertion too: make a simple text processor that reads >> Python source code and outputs the same source code with only one change: >> insert the string 'self" as the first parameter of every "def >> somemethod". > > Not so simple: you have plain functions (outside class statements), and > inner functions (inside def statements), and classmethods, and statict > methods, and some other corner cases (like __new__()) to take into > acccount... Well I'm assuming the rules for when to put 'self' in the parameter list are simple enough to be automated. In cases where they're not (e.g. dynamic methods outside a class), I have no problem with an explicit self to signal what's going on. That's the price you pay for dynamism. > As I said, this requires more than a simple pre-processor > and so would have to be done at parsing time since it requires parsing > anyway. I think you could make a go of it with regular expressions, but yes parsing is the better approach. > - but note that there may as well be something obviously wrong that I > fail to spot ditto > (it's very late here and I had a hard day !-). I of course > don't take into account the fact that this would break all existing > Python code, which is unavoidable for such a syntactic change. of course, which I'm sure means it will never happen, Python 3 notwithstanding. > Well, I must admit that done this way (which is quite different from > what I understood from your previous posts), That's my fault, I did a lot of hand-waving at first and probably contradicted myself a couple times as I was describing the idea. > Now is this something good is another point. I was about to argue that I > don't like the implicitness of it, but 1/ this is how most OOPLs do (at > least from a syntactic POV) and 2/ the fact is that the instance is > implicitely passed at call time, so I guess I'm just way too intoxicated > by so many years of Python programming to feel at ease with this !-) I'm sure much ink will be (and has been) spilled on the subject. > Since Python 3K is supposed to be the 'clean the warts and don't bother > breaking compat' rewrite of Python, you may as well propose a PEP on > this. Maybe that will be my summer project. We'll see, I was really hoping to write fewer briefs and more code. > You'll have to really prove it doesn't break anything else in the > object model, have strong and articulate arguments to support your point > (like proving this is really a common source of confusion for newbies), > and I really doubt it'll be accepted anyway. But what... It's definitely an uphill battle and I wonder if it's really worth the effort. We'll see. -- http://mail.python.org/mailman/listinfo/python-list
Re: noob question: "TypeError" wrong number of args
Bruno Desthuilliers wrote: > IOW, let's give Edward some time to come up with enough rope so we can > hang him to the nearest (AS) Tree !-) That's all I ask. ;) -- http://mail.python.org/mailman/listinfo/python-list
Re: noob question: "TypeError" wrong number of args
Bruno Desthuilliers wrote: (snip) > Since Python 3K is supposed to be the 'clean the warts and don't bother > breaking compat' rewrite of Python, you may as well propose a PEP on > this. You'll have to really prove it doesn't break anything else in the > object model, have strong and articulate arguments to support your point > (like proving this is really a common source of confusion for newbies), And of course propose an implementation - perhaps the compiler.ast could be useful ? -- bruno desthuilliers python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in '[EMAIL PROTECTED]'.split('@')])" -- http://mail.python.org/mailman/listinfo/python-list
Re: noob question: "TypeError" wrong number of args
Ben Finney a écrit : > Edward Elliott <[EMAIL PROTECTED]> writes: > > >>Compiler, interpreter, magic-codey-runny-thingy, whatever, at some point >>something has to translate this source code >> def method (self, a, b): something >>into a function object (or whatever you're calling the runnable code this >>week). Call this translator Foo. Whatever Foo is, it can insert 'self' >>into the parameter list for method, e.g. when it sees "def method (a,b)" it >>pretend like it saw "def method (self,a,b)" and proceed as usual. Once it >>does that, everything is exactly the same as before. > > > So now you're proposing that this be a special case when a function is > declared by that particular syntax, and it should be different to when > a function is created outside the class definition and added as a > method to the object at run-time. > > Thus breaking not only "explicit is better than implicit", This one can be subject to discussion. Actually, we must explicitely declare the instance in the params list, but it's implicitely passed at calltime by the method descriptor. > but also > "special cases aren't special enough to break the rules". Yeps, I think this is what I don't like here. > Still -1. I'm not yet ready to vote for Edward's proposition - as you say, it makes 'def statements into a class statement' a special case, and I don't like special cases too much (OTOH, there actually *are* special cases - __new__() being an example) - *but* it's not that silly either IMHO, and I think this should not be dismissed on a purely reactional basis. IOW, let's give Edward some time to come up with enough rope so we can hang him to the nearest (AS) Tree !-) -- http://mail.python.org/mailman/listinfo/python-list
Re: noob question: "TypeError" wrong number of args
Ben Finney wrote: > So the tradeoff you propose is: > > - Honour "explicit is better than implicit", but users are confused > over "why do I need to declare the instance in the method > signature?" > > against > > - Break "explicit is better than implicit", take away some of the > flexibility in Python, and users are confused over "where the heck > did this 'self' thing come from?" or "how the heck do I refer to > the instance object?" Essentially, but 1. it removes zero flexibility (everything works as before) 2. it's no more confusing than "where did this len/count/dir/type/str/any other builtin thing come from?" 3. learning "how do i access this instance object" is certainly no harder or less intuitive than learning "how do i initialize this instance object?" > I don't see a net gain by going with the latter. Ok. Would you care to explain in more detail? -- http://mail.python.org/mailman/listinfo/python-list
Re: noob question: "TypeError" wrong number of args
Ben Finney wrote: > So now you're proposing that this be a special case when a function is > declared by that particular syntax, and it should be different to when > a function is created outside the class definition and added as a > method to the object at run-time. > > Thus breaking not only "explicit is better than implicit", but also > "special cases aren't special enough to break the rules". Exactly. Hey, 'for' and 'while' are only special cases of if/goto. Why not ditch them and get back to basics? Rules are made to be broken, the key is when. Method calls are special cases no matter how you slice it. Overall I think implicit self beats explicit self for the typical case: def method (a): self.a = a # self magically appears obj.method (x) vs def method (self, a): # self explicit self.a = a obj.method (x) # arg count mismatch (except in message passing model) Not so much for the argument mismatch problem (see start of thread), which is easily rectified. The former is simply more elegant in my view. Less clutter, less confusion. Sure, if we get into calling "class.method (obj, a)" the argument mismatch problem resurfaces with implicit self. But 1) this is a rarer case, and 2) that's not my primary objection anyway. As long as we're trotting out aphorisms, how about DRY: Don't Repeat Yourself. The rule couldn't be clearer: don't repeat your SELF. ;) Yet that's exactly what explicitly declaring self does, forces me to needlessly repeat what everyone already knows: methods take the object instance as their first parameter. Whether this is a good idea is subject to debate, and I'd like to hear discussion on the merits. What I don't want is a silly battle of maxims. -- http://mail.python.org/mailman/listinfo/python-list
Re: noob question: "TypeError" wrong number of args
Edward Elliott a écrit : > Bruno Desthuilliers wrote: > >>Edward, I know I told you so at least three times, but really, >>seriously, do *yourself* a favor : take time to read about descriptors >>and metaclasses - and if possible to experiment a bit - so you can get a >>better understanding of Python's object model. Then I'll be happy to >>continue this discussion (. > > Will do, if nothing else it will eliminate language barriers, which we may > be running into at this point (though you've indicated otherwise). You won't regret it anyway - my own experience is that you must go thru this to really take full advantage of Python's power, expressivity and flexibility. Oh, and, yes : it's definitively fun too !-) > I appreciate your > patience and willingness to engage in this discussion. Votre serviteur, Messire. > As a last ditch effort to get my point across: > > Compiler, interpreter, magic-codey-runny-thingy, whatever, at some point > something has to translate this source code > def method (self, a, b): something > into a function object (or whatever you're calling the runnable code this > week). AFAIK, this is done by partly by the compiler and partly by the interpreter. > Call this translator Foo. Whatever Foo is, it can insert 'self' > into the parameter list for method, This would have to happen before compilation - I'd say at parsing time. But then, constructs like: class Obj(object): def method(...): ... method = staticmethod(method) or it's newer syntactic-sugar-version would become somewhat more difficult to parse properly - but I admit that this is beyond my knowledge. > e.g. when it sees "def method (a,b)" This has to be in a class statement - else it's shouldn't be touched. > it > pretend like it saw "def method (self,a,b)" and proceed as usual. Once it > does that, everything is exactly the same as before. > > I can prove that assertion too: make a simple text processor that reads > Python source code and outputs the same source code with only one change: > insert the string 'self" as the first parameter of every "def somemethod". Not so simple: you have plain functions (outside class statements), and inner functions (inside def statements), and classmethods, and statict methods, and some other corner cases (like __new__()) to take into acccount... As I said, this requires more than a simple pre-processor and so would have to be done at parsing time since it requires parsing anyway. I don't know enough about Python's parser to tell if it could work and how hard this would be. > Next run the output source code with the normal Python interpreter. > Everything functions *exactly* as before because the code is *exactly* the > same as what you would have written if you'd put the 'self's in there > manually. Now make the Python interpreter invoke this text processor as > the first step in processing source code. Voila, python + implicit self. cf above. > No changes to the object model. seems not. > No changes to dynamic binding. idem > Same "runnable" code as before. seems so. > Where is the problem in this scheme? > Or (since I haven't read up on the object model yet) simply: Is there a > problem? Apart from the added complexity to the parser, I don't find one righ now - but note that there may as well be something obviously wrong that I fail to spot (it's very late here and I had a hard day !-). I of course don't take into account the fact that this would break all existing Python code, which is unavoidable for such a syntactic change. Well, I must admit that done this way (which is quite different from what I understood from your previous posts), this could *perhaps* (unless I missed something - any guru around here ?) work. At least it does not sound so crazy. Now is this something good is another point. I was about to argue that I don't like the implicitness of it, but 1/ this is how most OOPLs do (at least from a syntactic POV) and 2/ the fact is that the instance is implicitely passed at call time, so I guess I'm just way too intoxicated by so many years of Python programming to feel at ease with this !-) Since Python 3K is supposed to be the 'clean the warts and don't bother breaking compat' rewrite of Python, you may as well propose a PEP on this. You'll have to really prove it doesn't break anything else in the object model, have strong and articulate arguments to support your point (like proving this is really a common source of confusion for newbies), and I really doubt it'll be accepted anyway. But what... Ok, time to bed now - I'll re-read this when my one and only neuron left will be willing and able to do its job !-) -- http://mail.python.org/mailman/listinfo/python-list
Re: noob question: "TypeError" wrong number of args
Edward Elliott <[EMAIL PROTECTED]> writes: > Compiler, interpreter, magic-codey-runny-thingy, whatever, at some point > something has to translate this source code > def method (self, a, b): something > into a function object (or whatever you're calling the runnable code this > week). Call this translator Foo. Whatever Foo is, it can insert 'self' > into the parameter list for method, e.g. when it sees "def method (a,b)" it > pretend like it saw "def method (self,a,b)" and proceed as usual. Once it > does that, everything is exactly the same as before. So now you're proposing that this be a special case when a function is declared by that particular syntax, and it should be different to when a function is created outside the class definition and added as a method to the object at run-time. Thus breaking not only "explicit is better than implicit", but also "special cases aren't special enough to break the rules". Still -1. -- \ "The cost of a thing is the amount of what I call life which is | `\ required to be exchanged for it, immediately or in the long | _o__)run." -- Henry David Thoreau | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: noob question: "TypeError" wrong number of args
Edward Elliott <[EMAIL PROTECTED]> writes: > bruno at modulix wrote: > > class MyObj(object): > > def __init__(self, name): > > self.name = name > > class MyObj(object): > def __init__(name): > self.name = name So the tradeoff you propose is: - Honour "explicit is better than implicit", but users are confused over "why do I need to declare the instance in the method signature?" against - Break "explicit is better than implicit", take away some of the flexibility in Python, and users are confused over "where the heck did this 'self' thing come from?" or "how the heck do I refer to the instance object?" I don't see a net gain by going with the latter. -1. -- \ "Those who will not reason, are bigots, those who cannot, are | `\ fools, and those who dare not, are slaves." -- "Lord" George | _o__)Gordon Noel Byron | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: noob question: "TypeError" wrong number of args
Bruno Desthuilliers wrote: > Edward, I know I told you so at least three times, but really, > seriously, do *yourself* a favor : take time to read about descriptors > and metaclasses - and if possible to experiment a bit - so you can get a > better understanding of Python's object model. Then I'll be happy to > continue this discussion (. Will do, if nothing else it will eliminate language barriers, which we may be running into at this point (though you've indicated otherwise). It probably won't happen for another week or two at though. I appreciate your patience and willingness to engage in this discussion. As a last ditch effort to get my point across: Compiler, interpreter, magic-codey-runny-thingy, whatever, at some point something has to translate this source code def method (self, a, b): something into a function object (or whatever you're calling the runnable code this week). Call this translator Foo. Whatever Foo is, it can insert 'self' into the parameter list for method, e.g. when it sees "def method (a,b)" it pretend like it saw "def method (self,a,b)" and proceed as usual. Once it does that, everything is exactly the same as before. I can prove that assertion too: make a simple text processor that reads Python source code and outputs the same source code with only one change: insert the string 'self" as the first parameter of every "def somemethod". Next run the output source code with the normal Python interpreter. Everything functions *exactly* as before because the code is *exactly* the same as what you would have written if you'd put the 'self's in there manually. Now make the Python interpreter invoke this text processor as the first step in processing source code. Voila, python + implicit self. No changes to the object model. No changes to dynamic binding. Same "runnable" code as before. Where is the problem in this scheme? Or (since I haven't read up on the object model yet) simply: Is there a problem? -- http://mail.python.org/mailman/listinfo/python-list
Re: noob question: "TypeError" wrong number of args
Edward Elliott a écrit : > bruno at modulix wrote: > (snip) > >>You skipped the interesting part, so I repost it and ask again: how >>could the following code work without the instance being an explicit >>parameter of the function to be used as a method ? >> >>def someFunc(obj): >> try: >>print obj.name >> except AttributeError: >>print "obj %s has no name" % obj >> >>import types >>m = MyObj('parrot') >>m.someMeth = types.MethodType(someFunc, obj, obj.__class__) >>m.someMeth() > > > I posted the only part that needs modification. Nope. > Here it is again with the > entire segment: > > class MyObj(object): > def __init__(name): > self.name = name <== interpreter binds name 'self' to object instance. > compiler adds 'self' to method sig as 1st param. > > def someFunc(obj): > try: > print obj.name <== 'obj' gets bound to first arg passed. when bound > as a method, first arg will be object instance. > when called as func, it will be first actual arg. > except AttributeError: > print "obj %s has no name" % obj > > import types > m = MyObj('parrot') > m.someMeth = types.MethodType(someFunc, obj, obj.__class__) <== binds obj >to first parameter of someFunc as usual > m.someMeth() > > > >>You see, wrapping a function into a method is not done at compile-time, >>but at runtime. And it can be done manually outside a class statement. >>In the above example, someFunc() can be used as a plain function. > > > All the parameter information has been preserved. > Method signatures are > unchanged from their current form, > so the interpreter has no trouble > deducing arguments. You just don't actually declare self yourself. In this exemple, it was named 'obj', to make clear that there was nothing special about 'self'. As you can see from the call, I didn't actually passed the fist param, since the method wrapper takes care of it... So if we were to implement your proposition (which seems very unlikely...), the above code *would not work* - we'd get a TypeError because of the missing argument. > When > binding a function to an object as above, the interpreter sees and does > exactly the same thing as now. I'm sorry, but you're just plain wrong. *Please* take time to read about the descriptor protocol and understand Python's object model. > >>This >>wouldn't work with some automagical injection of the instance in the >>function's local namespace, because you would then have to write >>"method"'s code diffently from function's code. > > > Maybe this will make it clearer: > > Programmer's view Compiler Interpreter's view > def func (a, b) func (a, b) -> func (a, b) func (a, b) > def method (a)method (a) -> method (self, a) method (self, a) > > IOW the compiler adds 'self' to the front of the parameter list when > processing a method declaration. 1/ there is *no* 'method declaration' in Python 2/ wrapping functions into methods happens at runtime, *not* at compile time. (snip) >>>And the rest should work fine. When the interpreter sees a method >>>declaration, >> >>The interpreter never sees a 'method declaration', since there is no >>such thing as a 'method declaration' in Python. The def statement >>creates a *function* object: > > > Fine, whatever, compiler sees method declaration, There ain't *nothing* like a 'method declaration' in Python. Zilch, nada, none, rien... All there is is the def statement that creates a *function* (and the class statement that creates a class object). > >>>Complete non-sequitor, what does this have to do with self? >> >>It has to do that the obj.name() syntax doesn't imply a *method* call - >>it can as well be a plain function call. > > Ok I see your point, Not quite, I'm afraid. > >>Also, and FWIW: >> >def moduleFunc(): >> >>... print self.name >>... >> >moduleFunc() >> >>Traceback (most recent call last): >>NameError: global name 'self' is not defined > > > Exactly, that was my point in the first place. I'm afraid we don't understand each other here. This was supposed to come as an illustration that, if some black magic was to 'inject' the instance (here named 'self') in the local namespace of a 'method' (the way you see it), we would loose the possibility to turn a function into a method. Try to re-read both examples with s/obj/self/ in the first one and s/self/obj/ in this last one. Edward, I know I told you so at least three times, but really, seriously, do *yourself* a favor : take time to read about descriptors and metaclasses - and if possible to experiment a bit - so you can get a better understanding of Python's object model. Then I'll be happy to continue this discussion (. FWIW, I too found at first that having to explicitely declare the instance as first param of a 'function-to-be-used-as-a-method' was an
Re: noob question: "TypeError" wrong number of args
bruno at modulix wrote: > It is to be taken literally. Either you talk about how Python > effectively works or the whole discussion is useless. I started talking about the code-level view (programmer's perspective) so shorthand was fine. Now that we've moved on to interpreter/compiler-level stuff, I agree that more precision is warranted. > You skipped the interesting part, so I repost it and ask again: how > could the following code work without the instance being an explicit > parameter of the function to be used as a method ? > > def someFunc(obj): > try: > print obj.name > except AttributeError: > print "obj %s has no name" % obj > > import types > m = MyObj('parrot') > m.someMeth = types.MethodType(someFunc, obj, obj.__class__) > m.someMeth() I posted the only part that needs modification. Here it is again with the entire segment: class MyObj(object): def __init__(name): self.name = name <== interpreter binds name 'self' to object instance. compiler adds 'self' to method sig as 1st param. def someFunc(obj): try: print obj.name <== 'obj' gets bound to first arg passed. when bound as a method, first arg will be object instance. when called as func, it will be first actual arg. except AttributeError: print "obj %s has no name" % obj import types m = MyObj('parrot') m.someMeth = types.MethodType(someFunc, obj, obj.__class__) <== binds obj to first parameter of someFunc as usual m.someMeth() > You see, wrapping a function into a method is not done at compile-time, > but at runtime. And it can be done manually outside a class statement. > In the above example, someFunc() can be used as a plain function. All the parameter information has been preserved. Method signatures are unchanged from their current form, so the interpreter has no trouble deducing arguments. You just don't actually declare self yourself. When binding a function to an object as above, the interpreter sees and does exactly the same thing as now. > This > wouldn't work with some automagical injection of the instance in the > function's local namespace, because you would then have to write > "method"'s code diffently from function's code. Maybe this will make it clearer: Programmer's view Compiler Interpreter's view def func (a, b) func (a, b) -> func (a, b) func (a, b) def method (a)method (a) -> method (self, a) method (self, a) IOW the compiler adds 'self' to the front of the parameter list when processing a method declaration. Interpreter sees the same signature as now, only programmer doesn't have to write 'self' anymore. >> And the rest should work fine. When the interpreter sees a method >> declaration, > > The interpreter never sees a 'method declaration', since there is no > such thing as a 'method declaration' in Python. The def statement > creates a *function* object: Fine, whatever, compiler sees method declaration, interpreter sees function object. The point is, the interpreter sees the same thing it does now. >> Complete non-sequitor, what does this have to do with self? > > It has to do that the obj.name() syntax doesn't imply a *method* call - > it can as well be a plain function call. Ok I see your point, but it doesn't matter because the interpreter sees the same function object as before. This confusion is partly (mostly? ;) my fault. I haven't been distinguishing precisely between the interpreter and the compiler because usually with Python it doesn't matter (in practice). This is clearly one place it does. In the words of Douglas Adams: We apologize for the inconvenience. > Also, and FWIW: def moduleFunc(): > ... print self.name > ... moduleFunc() > Traceback (most recent call last): > NameError: global name 'self' is not defined Exactly, that was my point in the first place. -- http://mail.python.org/mailman/listinfo/python-list
Re: noob question: "TypeError" wrong number of args
Edward Elliott wrote: > bruno at modulix wrote: > >>>that 1) b is an object not a module*, and 2) objects pass references to >>>themselves as the first argument to their methods. >> >>Nope. It's the MethodType object (a descriptor) that wraps the function >>that do the job. The object itself is totally unaware of this. > > > It's shorthand, not to be taken literally. > It is to be taken literally. Either you talk about how Python effectively works or the whole discussion is useless. > >>>Making people pass 'self' >> >>s/self/the instance/ >> >> >>>explicitly is stupid >> >>No. It's actually a feature. > > potato, potahto. > tss... > >>>the first argument, leading to these kinds of mistakes. The compiler >>>should handle it for you > >> >>I don't think this would be possible if we want to keep the full >>dynamism of Python. How then could the compiler handle the following code >>? >> >>class MyObj(object): >> def __init__(self, name): >>self.name = name > > > class MyObj(object): > def __init__(name): > self.name = name You skipped the interesting part, so I repost it and ask again: how could the following code work without the instance being an explicit parameter of the function to be used as a method ? def someFunc(obj): try: print obj.name except AttributeError: print "obj %s has no name" % obj import types m = MyObj('parrot') m.someMeth = types.MethodType(someFunc, obj, obj.__class__) m.someMeth() You see, wrapping a function into a method is not done at compile-time, but at runtime. And it can be done manually outside a class statement. In the above example, someFunc() can be used as a plain function. In fact, almost any existing function taking at least one argument can be turned into a method (in theory at least - practically, you of course need to make sure the first argument is of a compatible type). This wouldn't work with some automagical injection of the instance in the function's local namespace, because you would then have to write "method"'s code diffently from function's code. > And the rest should work fine. When the interpreter sees a method > declaration, The interpreter never sees a 'method declaration', since there is no such thing as a 'method declaration' in Python. The def statement creates a *function* object: >>> class Parrot(object): ... def test(self): ... pass ... print "type(test) is : ", type(test) ... type(test) is : >>>but in practice you don't declare >>>self as a parameter to module functions >> >>def someOtherFunc(): >> print "hello there" >> >>m.someFunc = someOtherFunc >>m.someFunc() > > Complete non-sequitor, what does this have to do with self? It has to do that the obj.name() syntax doesn't imply a *method* call - it can as well be a plain function call. Also, and FWIW: >>> def moduleFunc(): ... print self.name ... >>> moduleFunc() Traceback (most recent call last): File "", line 1, in ? File "", line 2, in moduleFunc NameError: global name 'self' is not defined >>> HTH -- bruno desthuilliers python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in '[EMAIL PROTECTED]'.split('@')])" -- http://mail.python.org/mailman/listinfo/python-list
Re: noob question: "TypeError" wrong number of args
bruno at modulix wrote: >> that 1) b is an object not a module*, and 2) objects pass references to >> themselves as the first argument to their methods. > > Nope. It's the MethodType object (a descriptor) that wraps the function > that do the job. The object itself is totally unaware of this. It's shorthand, not to be taken literally. >> Making people pass 'self' > > s/self/the instance/ > >> explicitly is stupid > > No. It's actually a feature. potato, potahto. >> the first argument, leading to these kinds of mistakes. The compiler >> should handle it for you > > I don't think this would be possible if we want to keep the full > dynamism of Python. How then could the compiler handle the following code > ? > > class MyObj(object): > def __init__(self, name): > self.name = name class MyObj(object): def __init__(name): self.name = name And the rest should work fine. When the interpreter sees a method declaration, it can automatically 1) add the object instance parameter to the signature, and 2) automatically bind the name self to the object instance on dispatch. Everything else is just as before. >> but in practice you don't declare >> self as a parameter to module functions > > def someOtherFunc(): > print "hello there" > > m.someFunc = someOtherFunc > m.someFunc() Complete non-sequitor, what does this have to do with self? -- http://mail.python.org/mailman/listinfo/python-list
Re: noob question: "TypeError" wrong number of args
Edward Elliott wrote: > Holger wrote: > >>oops, that was kinda embarrassing. > > > It's really not. You got a completely unhelpful error message saying you > passed 2 args when you only passed one explicitly. The fact the b is also > an argument to b.addfile(f) is totally nonobvious until you know that 1) b > is an object not a module*, and 2) objects pass references to themselves as > the first argument to their methods. Nope. It's the MethodType object (a descriptor) that wraps the function that do the job. The object itself is totally unaware of this. > The syntax "b." is completely > different from the syntax of any other type of parameter. > > The mismatch between the number of parameters declared in the method > signature and the number of arguments actually passed There's no mismatch at this level. The arguments passed to the *function *object wrapped by the method actually matches the *function* signature. > is nonobvious, > unintuitive, and would trip up anybody who didn't already know what was > going on. It's ugly and confusing. It's definitely a wart on the > langauge. I do agree that the error message is really unhelpful for newbies (now I don't know how difficult/costly it would be to correct this). > Making people pass 'self' s/self/the instance/ > explicitly is stupid No. It's actually a feature. > because it always has to be > the first argument, leading to these kinds of mistakes. The compiler > should handle it for you I don't think this would be possible if we want to keep the full dynamism of Python. How then could the compiler handle the following code ? class MyObj(object): def __init__(self, name): self.name = name def someFunc(obj): try: print obj.name except AttributeError: print "obj %s has no name" % obj import types m = MyObj('parrot') m.someMeth = types.MethodType(someFunc, obj, obj.__class__) m.someMeth() > - and no, explicit is not *always* better than > implicit, just often and perhaps usually. While it's easy to recognize > once you know what's going on, that doesn't make it any less of a wart. > > * technically modules may be objects also, s/may be/are/ > but in practice you don't declare > self as a parameter to module functions def someOtherFunc(): print "hello there" m.someFunc = someOtherFunc m.someFunc() -- bruno desthuilliers python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in '[EMAIL PROTECTED]'.split('@')])" -- http://mail.python.org/mailman/listinfo/python-list
Re: noob question: "TypeError" wrong number of args
Steve Holden wrote: > Objects don't actually "pass references to themselves". The interpreter > adds the bound instance as the first argument to a call on a bound method. Sure, if you want to get technical For that matter, objects don't actually call their methods either -- the interpreter looks up the method name in a function table and dispatches it. I don't see how shorthand talk about objects as actors hurts anything unless we're implementing an interpreter. > Sorry, it's a wart on your brain. Fine it's a wart on my brain. It's still a wart. > Read Guido's arguments in favor of an > explicit self argument again before you assert this so confidently. I would if I could find it. I'm sure he had good reasons, they may even convince me. But from my current perspective I disagree. > It's > certainly confusing to beginners, but there are actually quite sound > reasons for it (see next paragraph). While confusion for beginners is a problem, that's not such a big deal. It's a trivial fix that they see once and remember forever. What I mind is its ugliness, that the language makes me do work declaring self when it knows damn well it won't like my code until I do what it wants (yes I'm anthropomorphizing interpreters now). The interpreter works for me, I don't work for it. Things it can figure out automatically, it should handle. > Hmm. I see. How would you then handle the use of unbound methods as > first-class objects? If self is implicitly declared, that implies that > methods can only be used when bound to instances. I fail to see the problem here. I'm taking about implicit declaration on the receiving end. It sounds like you're talking about implicit passing on the sending end. The two are orthogonal. I can declare def amethod (a, b): and have self received implicitly (i.e. get the object instance bound by the interpreter to the name self). The sender still explicitly provides the object instance, e.g. obj.amethod (a,b) or class.amethod (obj, a, b) IOW everything can still work exactly as it does now, only *without me typing self* as the first parameter of every goddamn method I write. Does that make sense? > How, otherwise, would > you have an instance call its superclass's __init__ method if it's no > longer valid to say > > myClass(otherClass): > def __init__(self): > otherClass.__init__(self) > ... > Like this: myClass(otherClass): def __init__(): otherClass.__init__(self) self is still there and still bound, I just don't have to type it out. The interpreter knows where it goes and what it does, automate it already! >> * technically modules may be objects also, but in practice you don't >> declare self as a parameter to module functions > > The reason you don't do that is because the functions in a module are > functions in a module, not methods of (some instance of) a class. > Modules not only "may be" objects, they *are* objects, but the functions > defined in them aren't methods. What, in Python, *isn't* an object? If it looks like a duck and it quacks like a duck... Functions and methods look different in their declaration but the calling syntax is the same. It's not obvious from the dot notation syntax where the 'self' argument comes from. Some interpreter magic goes on behind the scenes. Great, I'm all for it, now why not extend that magic a little bit further? -- http://mail.python.org/mailman/listinfo/python-list
Re: noob question: "TypeError" wrong number of args
No way. You didn't deserve it. Unless you came from another OO language, the Guido tutorial on Classes is unintelligible. It assumes way too much knowledge. But I found something else that looks promising that you may want to peek at: http://pytut.infogami.com/node11-baseline.html rd Reply -- http://mail.python.org/mailman/listinfo/python-list
Re: noob question: "TypeError" wrong number of args
Just my opinion, but I think the Guido tutorial on Classes is unintelligible unless you're coming from another OO language. But I found something else that looks promising that you may want to peek at: http://pytut.infogami.com/node11-baseline.html rd -- http://mail.python.org/mailman/listinfo/python-list
Re: noob question: "TypeError" wrong number of args
Edward Elliott wrote: > Holger wrote: > >>oops, that was kinda embarrassing. > > > It's really not. You got a completely unhelpful error message saying you > passed 2 args when you only passed one explicitly. The fact the b is also > an argument to b.addfile(f) is totally nonobvious until you know that 1) b > is an object not a module*, and 2) objects pass references to themselves as > the first argument to their methods. The syntax "b." is completely > different from the syntax of any other type of parameter. > Specifically, perhaps it would be better to say "b is an instance of some Python class or type". Objects don't actually "pass references to themselves". The interpreter adds the bound instance as the first argument to a call on a bound method. I agree that the error message should probably be improved for the specific case of the wrong number of arguments to a bound method (and even more specifically when the number of arguments is out by exactly one - if there's one too many then self may have been omitted from the parameter list). > The mismatch between the number of parameters declared in the method > signature and the number of arguments actually passed is nonobvious, > unintuitive, and would trip up anybody who didn't already know what was > going on. It's ugly and confusing. It's definitely a wart on the > langauge. > Sorry, it's a wart on your brain. Read Guido's arguments in favor of an explicit self argument again before you assert this so confidently. It's certainly confusing to beginners, but there are actually quite sound reasons for it (see next paragraph). > Making people pass 'self' explicitly is stupid because it always has to be > the first argument, leading to these kinds of mistakes. The compiler > should handle it for you - and no, explicit is not *always* better than > implicit, just often and perhaps usually. While it's easy to recognize > once you know what's going on, that doesn't make it any less of a wart. > Hmm. I see. How would you then handle the use of unbound methods as first-class objects? If self is implicitly declared, that implies that methods can only be used when bound to instances. How, otherwise, would you have an instance call its superclass's __init__ method if it's no longer valid to say myClass(otherClass): def __init__(self): otherClass.__init__(self) ... > * technically modules may be objects also, but in practice you don't declare > self as a parameter to module functions The reason you don't do that is because the functions in a module are functions in a module, not methods of (some instance of) a class. Modules not only "may be" objects, they *are* objects, but the functions defined in them aren't methods. What, in Python, *isn't* an object? regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Love me, love my blog http://holdenweb.blogspot.com Recent Ramblings http://del.icio.us/steve.holden -- http://mail.python.org/mailman/listinfo/python-list
Re: noob question: "TypeError" wrong number of args
Holger wrote: > oops, that was kinda embarrassing. It's really not. You got a completely unhelpful error message saying you passed 2 args when you only passed one explicitly. The fact the b is also an argument to b.addfile(f) is totally nonobvious until you know that 1) b is an object not a module*, and 2) objects pass references to themselves as the first argument to their methods. The syntax "b." is completely different from the syntax of any other type of parameter. The mismatch between the number of parameters declared in the method signature and the number of arguments actually passed is nonobvious, unintuitive, and would trip up anybody who didn't already know what was going on. It's ugly and confusing. It's definitely a wart on the langauge. Making people pass 'self' explicitly is stupid because it always has to be the first argument, leading to these kinds of mistakes. The compiler should handle it for you - and no, explicit is not *always* better than implicit, just often and perhaps usually. While it's easy to recognize once you know what's going on, that doesn't make it any less of a wart. * technically modules may be objects also, but in practice you don't declare self as a parameter to module functions -- http://mail.python.org/mailman/listinfo/python-list
Re: noob question: "TypeError" wrong number of args
I guess I deserved that. :-( I *did* read the tutorial, but then I forgot and didn't notice... My brain is getting is slow - so thx for the friendly slap in the face ;-) -- http://mail.python.org/mailman/listinfo/python-list
Re: noob question: "TypeError" wrong number of args
"Holger" <[EMAIL PROTECTED]> writes: > > TypeError: addFile() takes exactly 1 argument (2 given) > > > > import sys > > class KeyBase: > def addFile(file): > print "initialize the base with lines from this file" You've misunderstood -- or never followed -- the tutorial, especially how Python does object methods. Please follow the whole tutorial through, understanding each example as you work through it. You'll then have a solid basis of knowledge to go on with. http://docs.python.org/tut/> -- \ "We are not gonna be great; we are not gonna be amazing; we are | `\gonna be *amazingly* amazing!" -- Zaphod Beeblebrox, _The | _o__)Hitch-Hiker's Guide To The Galaxy_, Douglas Adams | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: noob question: "TypeError" wrong number of args
oops, that was kinda embarrassing. But thx anyway :-) -- http://mail.python.org/mailman/listinfo/python-list
Re: noob question: "TypeError" wrong number of args
Holger wrote: > Tried searching for a solution to this, but the error message is so > generic, that I could not get any meaningfull results. > > Anyways - errormessage: > > TypeError: addFile() takes exactly 1 argument (2 given) > > > The script is run with two args "arg1" and "arg2": > > import sys > > class KeyBase: > def addFile(file): > print "initialize the base with lines from this file" when defining your own classes, you must spell out the "self" argument in your method definitions: def addFile(self, file): print "initialize the base with lines from this file" see: http://pyfaq.infogami.com/what-is-self -- http://mail.python.org/mailman/listinfo/python-list