Another try at Python's selfishness

[Alex Martelli]

Steven D'Aprano <steve at REMOVETHIScyber.com.au> wrote:
   ...
> would be. Token? Too specific. Maybe it would have been better to just
> have just said "...but now foo.bar has ...".

Agreed.

> model I have is "y" is a label in some namespace x, and you have to (in
> some sense) look up where "y" should go regardless of whether you are
> setting the value or getting the value.
> 
> Do you think this model is so far from the actual behaviour of Python that
> it is useless? Or is it fair to lump getting and setting attributes/names
> together?

I think it's reasonable: Python does first check if type(x).y is an
overriding descriptor (==one with a __set__ method), at least in the
mainstream case (oldstyle classic are weird;-).

> > and in "import x.y" it's
> > "bind x AND then bind y in namespace y".
> 
> I assume that's a typo and you mean "bind y in namespace x".

Yep.  Differently from the other bots (tim and /f), I'm programmed to
randomly make errors once in a while -- makes it easier to pass the
Turing test (many people mistakenly think I'm human, since "to err is
human", while nobody would think THAT of impeccabile timbot and effbot).

> But even "import x.y" is conceptually a lookup, equivalent to x.y =
> __import__("x.y"), with the understanding that x = __import__("x") is
> automagically run first.
> 
> [hand-waving, hand-waving, hand-waving... of course imports do a lot more
> than just setting a name in a namespace]

Of course, but so do some other statements that ALSO bind a name (in the
current namespace only, in today's Python), such as class and def.
We're just focusing on the binding part;-).

 
> But in all three of:
> 
> foo.bar = something
> something = foo.bar
> import foo.bar
> 
> the hierarchy goes from left to right, with bar being "inside" foo, for
> some meaning of inside. The Original Poster's syntax would reverse that,
> with def foo.bar(x,y) creating parameter foo "inside" method bar.

True.  Of course, the OP might argue that if x.f() can CALL f(x)
[placing x ``inside'' f], it's fair that a def of a composite name
should also ``swap insideness and outsideness'' similarly.  But, as I
said, "I'm not supporting the OP's idea; just rejecting the specific
objections to it". For once, I have a hard time articulating exactly why
I'd dislike such semantics for hypothetic syntax "def x.y", besides
minor points such as the difficulties wrt generalizing to "def x.y.z"...
but I do know which objections are NOT the ones which make me feel such
dislike!-)


Alex