Another try at Python's selfishness

[Alex Martelli]

Steven D'Aprano <steve at REMOVETHIScyber.com.au> 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