Steven D'Aprano <[EMAIL PROTECTED]> 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
--
http://mail.python.org/mailman/listinfo/python-list
