On 01.06.2016 17:42, Paul Moore wrote:
On 1 June 2016 at 16:10, Sven R. Kunze <firstname.lastname@example.org> wrote:
That's the current way. If now, the compiler would assign "x" to a special
dunder attribute/variable, that would allow __init__ to extract that name
and use it as if it were a parameter:
self.name = __assigned_name__ # that's me :)
Why doesn't the assignment here set __assigned_name__ too, and
override the value assigned by the "outer" assignment?
What's point with regards to the current discussion?
We need the name from the outer assignment. __assigned_name__ would
solve that as it provides us with the needed piece of information. I
don't see why an assignment on the same level where
__assigned_name__ is used, should override this very
__assigned_name__ variable. The assignment inside of __init__ might
do so at a even deeper level but __assigned_name__ would stay
constant for __init__ throughout the execution of
To me __assigned_name__ is just a magic variable as __module__ is.
It is different from module to module. __assigned_name__ is
different from function execution to function execution.
Also, as someone else pointed out, in
a = b = c = AutoSymbol()
what would __assigned_name__ be?
That depends on which approach you choose. It's either dynamic and
changes with each assignment or it is just set on the first
assignment and never changes then.
I suspect most usecases need the latter. So, that speaks for the
magic variable approach (independently of how characters are used
for assignment operator and how we name that variable).
The advantage of a special operation
is that it gives you a way of pointing out precisely *which* name
assignment we want to remember...
I don't know. I can't make a difference between = and ->. Just
special characters. The one I know has a relatively clear meaning is
=. So, I stick to it.