[Python-ideas] Augmented assignment syntax for objects.

Erik python at lucidity.plus.com
Fri Apr 28 18:04:00 EDT 2017


On 28/04/17 10:47, Paul Moore wrote:
> 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?

I know you already understand the following, but I'll spell it out 
anyway. Here's a module:

-----------------
$ cat foo.py
def foo():
   global sys
   import sys

   current_namespace = set(globals().keys())
   print(initial_namespace ^ current_namespace)

def bar():
   before_import = set(locals().keys())
   import os
   after_import = set(locals().keys())
   print(before_import ^ after_import)

initial_namespace = set(globals().keys())
-----------------

Now, what happens when I run those functions:

$ python3
Python 3.5.2 (default, Nov 17 2016, 17:05:23)
[GCC 5.4.0 20160609] on linux
Type "help", "copyright", "credits" or "license" for more information.
 >>> import foo
 >>> foo.foo()
{'sys', 'initial_namespace'}
 >>> foo.bar()
{'before_import', 'os'}
 >>>

... so the net effect of "import" is to bind an object into a namespace 
(a dict somewhere). In the case of 'foo()' it's binding the module 
object for "sys" into the dict of the module object that represents 
'foo.py'. In the case of 'bar()' it's binding the module object for "os" 
into the dict representing the local namespace of the current instance 
of the bar() call.

Isn't binding an object to a namespace the same operation that 
assignment performs?

So it's a type of assignment, and one that doesn't require the name to 
be spelled twice in the current syntax (and that's partly why I took 
offense at a suggestion - not by you - that I was picking "random or 
arbitrary" keywords. I picked it for that specific reason).

I realize that there are other semantic changes (importing a module 
twice doesn't do anything - and specifically repeated "import * from 
mod" will not do anything if the module mutates) - and perhaps this is 
your point.

> 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

self.a = a

>
> OK, but self is just a variable name, so we can reasonably use a different name:
>
> def __init__(foo, a):
>     foo import a

foo.a = 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

x.calc = calc

> And of course there's nothing special about __init__
>
> def my_method(self, a):
>     self import a

self.a = a

> Or indeed about methods
>
> def standalone(a, b):
>     a import b

a.b = b

> or statements inside functions:
>
> if __name __ == '__main__:
>     a = 12
>     b = 13
>     a import b

a.b = b

> Hmm, I'd hope for a type error here. But what types would be allowed
> for a?

I think you're assuming I'm suggesting some sort of magic around "self" 
or some such thing. I'm not. I've written above exactly what I would 
expect the examples to be equivalent to. It's just an assignment which 
doesn't repeat the name (and in the comma-separated version allows 
several names to be assigned using compact syntax without spelling them 
twice, which is where this whole thing spawned from).

> See what I mean? Things get out of hand *very* fast.

I don't see how that's getting "out of hand". The proposal is nothing 
more complicated than a slightly-different spelling of assignment. It 
could be done today with a text-based preprocessor which converts the 
proposed form to an existing valid syntax. Therefore, if it's "out of 
hand" then so is the existing assignment syntax ;)

FWIW, I should probably state for the record that I'm not actually 
pushing for _anything_ right now. I'm replying to questions asked and 
also to statements made which I think have missed the point of what I 
was trying to say earlier. So I'm just engaging in the conversation at 
this point - if it appears confrontational then it's not meant to.

> 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

To be honest, I still don't understand what the serious technical issues 
are (other than the parser probably doesn't handle this sort of 
keyword/operator hybrid!). Is it just that I'm seeing the word "import" 
in this context as a type of assignment and you're seeing any reference 
to the word "import" as being a completely different type of operation 
that comes with baggage?

Regards, E.


More information about the Python-ideas mailing list