On Fri, 03 Feb 2006 07:40:38 -0800, Alex Martelli wrote: > 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"?
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. -- http://mail.python.org/mailman/listinfo/python-list