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. <humble> Votre serviteur, Messire. </humble> > 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
