This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author steven.daprano
Recipients emilyemorehouse, eric.smith, gvanrossum, koobs, rhettinger, steven.daprano, tim.peters, veky, vstinner, willingc, xtreak
Date 2019-03-29.22:45:15
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <20190329224508.GS31406@ando.pearwood.info>
In-reply-to <1553872740.4.0.216721787424.issue35224@roundup.psfhosted.org>
Content
You are one person, who has used this feature for what, a month elapsed 
time? 300 person-hours actual experience with it? Allowing top-level 
unparenthisized walrus expressions will affect hundreds of thousands of 
people, for collectively millions of hours over a decade or more of 
elapsed time. What's the rush about lifting this restriction?

If the restriction turns out to be "pointless", then we can remove it 
later, and no harm done. You say this is ugly in the notebooks:

    (variable := expression)

but it is surely still an improvement over the status quo:

    variable = expression; variable

But if we remove it now, and it turns out that it wasn't as pointless as 
you thought, then we're stuck with a design mistake that will be very 
hard to fix without breaking people's code.

I'm glad you've found an excellent use-case for unbracketed assignment 
expressions, and I don't oppose your suggested change, I'm just 
advocating caution.

Besides, Jypiter already allows interactive code that would be a syntax 
error outside of their environment. They can probably relax that 
restriction within Jypiter, while still leaving the language alone.
History
Date User Action Args
2019-03-29 22:45:15steven.dapranosetrecipients: + steven.daprano, gvanrossum, tim.peters, rhettinger, vstinner, eric.smith, koobs, willingc, veky, emilyemorehouse, xtreak
2019-03-29 22:45:15steven.dapranolinkissue35224 messages
2019-03-29 22:45:15steven.dapranocreate