[Python-Dev] PEP 572: Why not := as standard assignment operator? (original) (raw)

Terry Reedy tjreedy at udel.edu
Thu Apr 26 16:00:38 EDT 2018

On 4/26/2018 11:38 AM, Gustavo Carneiro wrote:

On Thu, Apr 26, 2018 at 11:13 PM, Martin Teichmann <lkb.teichmann at gmail.com <mailto:lkb.teichmann at gmail.com>> wrote: > when reading PEP 572 I actually liked it a lot - I think it's actually > a cool idea. I think it's actually that cool an idea that it should be > made the default way of doing an assignment, over time phasing out the > good ole =.

Please no, I really, really appreciate not having to see add ':' all the time. Plus, it already has two other uses: end of header and dict key-item separator. Plus, see below.

In the interest of that, do you think := can be made illegal, by the grammar, if used outside an expression?

a = 1  # legal a := 1  # Syntax error if a := 1:  # legal

Please no.

PEP 572 does not discuss top-level interactive assignments. But it should, because having two forms of assignment that lets one choose to echo or not is a plus.

Sometimes one wants to see the result of an assignment. After

a, b = 14387, 344

it would be nice to be able to write

diff := a - b 14343

instead of

diff = a - b diff 14343

I consider this a significant positive feature of the proposal.

On the other hand, sometimes one does not want the see the result. A long result is often useless to view and may scroll previous results out of the window. A very long result may scroll previous results out of a finite console buffer altogether. (For Windows Command Prompt, the default is 300 lines, with a max of 9999.)

And sometimes the result must not be printed. Tk text widgets (and hence IDLE's Shell) do not have a particular limit on the number of lines. On the other hands, long lines drasticly slow down a text widget, and a long enough line will freeze it. (This is supposed to be fixed in Tcl/Tk 8.7, now in a1 stage.) For instance, ">>> [None]*1000000" in IDLE freezes the process.

-- Terry Jan Reedy

More information about the Python-Dev mailing list