[Python-ideas] Augmented assignment syntax for objects.

Paul Moore p.f.moore at gmail.com
Fri Apr 28 05:47:34 EDT 2017


On 28 April 2017 at 00:18, Erik <python at lucidity.plus.com> wrote:
>> The semantics are very different and there's little or no connection
>> between importing a module and setting an attribute on self.
>
> At the technical level of what goes on under the covers, yes. At the higher
> level of what the words mean in spoken English, it's really not so different
> a concept.

I disagree. If you were importing into the *class* (instance?) I might
begin to see a connection, but importing into self? Also, if you try
to make the obvious generalisations (which you'd *have* to be able to
make due to the way Python works) things quickly get out of hand:

def __init__(self, a):
    self import a

OK, but self is just a variable name, so we can reasonably use a different name:

def __init__(foo, a):
    foo import a

So the syntax is <variable> import <var-list>

Presumably the following also works, because there's nothing special
about parameters?

def __init__(x, a):
    calc = a**2
    x import calc

And of course there's nothing special about __init__

def my_method(self, a):
    self import a

Or indeed about methods

def standalone(a, b):
    a import b

or statements inside functions:

if __name __ == '__main__:
    a = 12
    b = 13
    a import b

Hmm, I'd hope for a type error here. But what types would be allowed
for a? Class instances? Well, a is an int, which is a class instance.
See what I mean? Things get out of hand *very* fast.

>> (If you don't like "inject", I'm okay with "load" or even "push".)
>
> No you're not, because that's a new keyword which might break existing code
> and that is even harder to justify than re-using an existing keyword in a
> different context.

Well, picking an existing keyword simply[1] to avoid using a new one
is an equally bad justification.

[1] I know that's not what you did, but without the "it's sort of like
importing" justification, which Steven has said he doesn't agree with,
and nor do I, you're only left with "because it means we don't need a
new keyword" - at which point suggesting that we need to bite the
bullet and consider whether a new keyword is justified is perfectly
reasonable. (IMO, a new keyword is *not* justified - nor is reusing an
existing one unless you can find a *much* more compelling parallel
than you did with import).

To summarise:

1. There's some serious technical issues with your proposal, which as
far as I can see can only be solved by arbitrary restrictions on how
it can be used
2. The use of import as a keyword is at best controversial
3. Using a new keyword for this construct is pretty much a non-starter

But I do agree that the proposal was a reasonable way to reframe the
debate here. It's just that what it's done is confirm my belief that
there's nothing here that needs improvement compared to the status quo
(even though I agree that long lists of "self.x = x" statements can be
tedious boilerplate).

Paul


More information about the Python-ideas mailing list