Steven D'Aprano <[EMAIL PROTECTED]> wrote: ... > > Why shouldn't > > def self.x(): > > declare two new identifiers ("x" and "self"), too? > > Sure, but now the call foo.bar
"call"? > has special meaning inside a def statement > than elsewhere. Elsewhere, foo.bar is an attribute access, looking up > attribute bar in foo's namespace. or setting it, as in foo.bar=23, or setting both names, as in import foo.bar > Using your syntax, in a def statement > foo.bar is a pair of declarations: it declares a name "foo", and it > declares a second name "bar". "declares" isn't really pythonic -- let's talk about binding or setting names, instead. > This inconsistency is, I think, worse than the implicit use of self. I don't think there's any inconsistency in deciding that syntax x.y has different meanings (as to what gets looked up or bound) in different contexts, because it already does: mostly "look up y in namespace x", but in x.y=... it's "bind y in namespace x" and in "import x.y" it's "bind x AND then bind y in namespace y". Since "def x.y(..." is currently a syntax error, it would introduce no backwards compatibility to assign a meaning to it. Since the 'def' statement binds something to the name that follows it (which currently must be a plain identifier), that's what it should do if it allowed the following name to be a compound one, too. Unfortunately, none of this suggests that it's reasonable to have def x.y(z): ... mean the same as def y(x, z): ... and I have no idea of how it would generalize to def x.y.z(t): ... (while import x.y.z generalizes in a pretty obvious way wrt import x.y). So, I'm not supporting the OP's idea; just rejecting the specific objections to it. Alex -- http://mail.python.org/mailman/listinfo/python-list