On 01.06.2016 17:42, Paul Moore wrote:

On 1 June 2016 at 16:10, Sven R. Kunze <srkunze@mail.de> 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:

class AutoSymbol:
    def __init__(self):
        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 __init__.

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.

Best,
Sven