I'm sure that only 1 or 2 people cares about my opinion on this, but I will say that PEP 572 is taking one of my least favorite features of C/C++ and adding it to Python. About the only good thing I can say about it is that it might make some things more convenient to write. Worse to read, worse to debug, and definitely less clear unless you've got a comment to explain.
At least in my case, the places I use them in C are places I feel *bad* about later. Partly because I know I'm usually trying to over-optimize, but partly because inline assignments are a big enough source of enough security vulnerabilities to make me question *any* language that decides to add them (especially 25+ years after the fact). Like... an entire async syntax and asyncio was modified in 3.6 (coroutine trampolines are tough without syntax, I get you, I did threads instead of dealing with them back in '05 because I couldn't get them quite right), but inline assignments just now? I'm at a loss. On the Python side, I wouldn't accept any patches in any of my projects to include := assignments, because those colons look like monitor grit, and/or a mistake (like someone wanted != but got := ), and means that my 2.6-3.6 compatible code is now 3.7+ only. I get that language evolution is a thing (my failures to try move *this* language in a direction I thought useful is part of why I stopped posting here), but hiding a colon in the middle of a line is not particularly explicit. And it definitely doesn't help for maintaining any of the software that I'm personally responsible for maintaining across the range of Python versions. I know you all don't care about me and my libraries, but at least consider the thousands of other libraries written and maintained by other folks. I mean, unless you all want 3.7+ - only libraries. To me, it seems like a lot of movement to support a feature that a lot of folks straight up don't want. But I don't have my finger on the pulse of Python or Python-dev, so maybe there are a bunch of folks coming from Go, Pascal, Smalltalk, etc., who are jonesin' for a hit of that :=, or have use-cases where this is a huge productivity improvement, and not a glaring security hole waiting to get them. I just don't know. But I also don't see a burning need; I'm 19 years in on this Python train, and I've never needed := before. Reading the PEP, the PR for changes to the Python standard library, email threads in support of the feature, etc., it just doesn't feel compelling. My $2, because that was a bit more than 2 cents worth of opinion, - Josiah On Sun, Jul 8, 2018 at 10:14 AM, Giampaolo Rodola' <g.rod...@gmail.com> wrote: > > > On Sun, Jul 8, 2018 at 6:45 PM Steve Holden <st...@holdenweb.com> wrote: > >> On Sun, Jul 8, 2018 at 10:41 AM, Giampaolo Rodola' <g.rod...@gmail.com> >> wrote: >> >>> [...] >>> I find that (space between the parentheses of a function call >>> statement) too unnatural as a place where to put an assignment. It is >>> not even "guarded" by a keyword like "if" or "while" which can help as >>> indicators that an assignment may occur. Also, I think it's way too easy to >>> confuse it with a keyword argument: >>> >>> >>> foo(x = 1) # keyword arg >>> >>> foo(x := 1) # assignment + value passing >>> [...] >>> >> >> But the PEP 8 spellings are >> >> foo(x=1) >> >> and >> >> f(x := 1). >> >> The extra spacing makes it obvious that this isn't a regular named >> argument. >> > > What if the author of the code I'm reading didn't respect PEP-8? I don't > think it's fair to invoke PEP-8 as a counter-measure to obviate a syntax > which can clearly be mistaken with something else simply by omitting 2 > spaces. Not to mention that I don't see why anyone would want to declare a > variable in there in the first place. > > -- > Giampaolo - http://grodola.blogspot.com > > > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ > josiah.carlson%40gmail.com > >
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com