On Fri, 21 Jul 2017 at 10:08 Jason H wrote:

I experimented with Python in college and I've been for close to 20 years now. (Coming and going as needed) I love the language. But there is one annoyance that I continually run into.

There are basically two assignment operators, based on context, = and : a = 1 { a: 1 }

So the latter is not an assignment. `=` is an assignment as it creates a new entry in a namespace, while the later just associates a key with a value in a dictionary.

They cannot be used interchangeably: a: 1 # error {a=1} # error

I don't think I should be this way.

But it's on purpose as they do different things. Thanks for sharing the idea but I don't see this changing. -Brett

There are times when I have a bunch of variables that I want to collect into an object or destructure. This involves adding commas, and swapping the :/=. I don't have a good fix for the adding of commas (maybe a newline?) but I think : should at least be accepted as = everywhere except in ifs: a: 1 # same as a = 1

One area where it might help (although the python parser already catches it) is in ifs: if a:1 # always error ? if a=1 # currently error, but might be accepted shorthand for == ?

Ideally, I could take a: 1 b: 2 then in 3 edits: 1. first line prepend 'x: {' 2. last line append '}' 3. indent between { }

I guess his would imply that { open up an assignment scope, where newlines are commas if the last line did not end with an operator or the next line did not start with an operator: x: { a: x - # - operator f(x) b: # : operator 5487234728394720348988734574357 c: 7 # c is 13, no trailing operator but next line has a preceding operator + 6 }

The only issue then is how do we address a? x.a # looks fine to me x['a'] # as a dict, but the conversion of a to string 'a' could be confusing.

Additionally, I was also thinking about : as an implied await: a = await f() # await generator a: f() # await generator, or direct assignment if return type is not a generator/async func

Thoughts? Please be gentle :-) _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

2017-07-21 10:07 GMT-07:00 Jason H :

I experimented with Python in college and I've been for close to 20 years now. (Coming and going as needed) I love the language. But there is one annoyance that I continually run into.

There are basically two assignment operators, based on context, = and : a = 1 { a: 1 }

They cannot be used interchangeably: a: 1 # error {a=1} # error

I don't think I should be this way.

There are times when I have a bunch of variables that I want to collect into an object or destructure. This involves adding commas, and swapping the :/=. I don't have a good fix for the adding of commas (maybe a newline?) but I think : should at least be accepted as = everywhere except in ifs: a: 1 # same as a = 1

One area where it might help (although the python parser already catches it) is in ifs: if a:1 # always error ? if a=1 # currently error, but might be accepted shorthand for == ?

Ideally, I could take a: 1 b: 2

This conflicts with PEP 526 variable annotations: "a: int" already means "a is of type int", but with your syntax there would be no way to distinguish between "a = int" and "a: int".

then in 3 edits: 1. first line prepend 'x: {' 2. last line append '}' 3. indent between { }

I guess his would imply that { open up an assignment scope, where newlines are commas if the last line did not end with an operator or the next line did not start with an operator: x: { a: x - # - operator f(x) b: # : operator 5487234728394720348988734574357 c: 7 # c is 13, no trailing operator but next line has a preceding operator + 6 }

The only issue then is how do we address a? x.a # looks fine to me x['a'] # as a dict, but the conversion of a to string 'a' could be confusing.

Additionally, I was also thinking about : as an implied await: a = await f() # await generator a: f() # await generator, or direct assignment if return type is not a generator/async func

Thoughts? Please be gentle :-) _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/