Another try at Python's selfishness

[Steven D'Aprano]

On Fri, 03 Feb 2006 07:40:38 -0800, Alex Martelli wrote:

> 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"?

Call? Who said anything about a call?

*wink*

Okay, poor choice of words. I'm not exactly sure what a better choice
would be. Token? Too specific. Maybe it would have been better to just
have just said "...but now foo.bar has ...".


>> 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, 

Conceptually, both setting and getting an attribute involves a "look up"
in the general sense: you need to look up the attribute to get its value,
or to find out where to put its value. You are correct (of course!) that
foo.bar can either be a get or a set, but I'm doing lots of hand-waving
here and I didn't think it was necessary to get bogged down in too much
detail.

> or setting both names, as in
> 
> import foo.bar

Ah, I completely forgot about import. But see below.


>> 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.

Yes, you're right, it is a bad habit. Years of Pascal don't die easily.



>> 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" 

Which from my perspective are conceptually two sides of the coin. The
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?


> 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".

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]

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.



-- 
Steven.