<div dir="ltr"><div class="gmail_quote"><div dir="ltr">[Victor Stinner]</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">FYI I'm trying to use assignment expressions on the stdlib because<br>
*all* examples of the PEP 572 look artificial to me.<br></blockquote><div><br>All the examples in my Appendix A were derived from real. pre-existing code (although mostly my own).  It's turned out that several others with your complaint above never read the PEP after that Appendix was added, so it's possible that applies to you too.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Like "group = re.match(data).group(1) if re.match(data) else None"<br>
which is followed by "(TODO: Include Guido's evidence, and do a more<br>
systematic search.)" I cannot find such inefficient code in the<br>
stdlib. I'm not saying that nobody writes code like that, just that<br>
developers with a good Python expertise would avoid to write such<br>
code.<br></blockquote><div><br>Sure.  It happens, but it's rare.  As I've said many times already, I was slightly surprised to conclude that the PEP was a win, but very surprised to conclude it was the frequent dead- obvious little wins that added up to its strongest case.<br><br>But that's mostly from staring at my code, and there's really nobody on Earth better qualified to make my tradeoffs than I am ;-)<br><br>I don't discount Guido's impressions either.  While it's unlikely you're going to find needlessly inefficient code in my Python, or the std lib, to save a line, I'm not surprised at all that he found people writing worse (on several counts - readability, maintainability, and speed) code _ just_ to save a line in "industrial Python".  Rather than dismiss the value for them because they're not as expert as I am, or as our std lib authors have been, I take it as evidence that the PEP provides value to others in ways that don't really apply to bona-fide-Python-expert code.  I suspect, but don't know, Guido is more moved by _that_ factor than by the dead obvious little wins in experts' code.</div><div><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> "filtered_data = [y for x in data if (y := f(x)) is not None]" also</blockquote></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
seems artificial. In the 711,617 lines of Python code of the stdlib, I<br>
only found *one* example:<br></blockquote><div><br></div><div>Well, you can't have it both ways.  That is, you can't fret that the feature will be massively used while simultaneously claiming there are almost no plausible uses at all ;-)<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">   ...</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">And I also only found a single for loop which can be converted to a<br>
list comprehension thanks to assignement expression.</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
    lines = []<br>
    for raw_line in raw_lines:<br>
        match = line_pat.search(raw_line.strip())<br>
        if match:<br>
            lines.append(match.group(1, 2))<br></blockquote><div><br>And I don't see it as "an obvious win" _to_ change it, so wouldn't rewrite it anyway.  Then again, my bar for "obvious win" may be higher than others'.</div><div><br><br></div><div>[Tim] </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> Wholesale changes to the std lib are unlikely to happen regardless.  Broad<br>
> patches just to spell things differently without _need_ are discouraged.<br></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So PEP 572 is purely syntax sugar? It doesn't bring anything to the<br>
stdlib for example?<br></blockquote><div><br></div><div>Insert the standard tedious observation about "Turing complete" here.  I'm too old to bear it again ;-)<br><br>Patches to make widespread more-or-less mindless changes are _always_ frowned on, unless it's truly necessary (because, e.g., a language change means the existing idiom will no longer work in the next release, or the existing idiom is known to be 10x slower than a new alternative, or ...).  It clutters the history, greatly obscures who is "really responsible" for the line that just showed up in a critical-failure traceback, and any code churn risks introducing bugs.  Especially when people with little knowledge of a module are changing it.  No matter how careful they are, they suffer brain farts when making widespread changes to code they've basically never seen before, and do introduce errors.  That's empirical historic fact.<br><br>Instead module experts introduce such changes incrementally while going about their regular business, if they so choose.  If, for example, Raymond despises assignment expressions. it's fine by me if itertools and random.py (two modules for which he's the primary maintainer) never use them - and it's a Bad Thing if someone else forces them on him without his approval.<br><br>In any case, I'd be -1 on your current approach regardless, until you drop the outer parens in<br><br>    if (name := f()):<br><br>etc.  It reads better as the intended:<br><br>    if name := f():<br><br>and that can matter.  There _is_ a side effect going on here, and on general principle it's better to avoid "hiding it" inside parentheses unless there's a need to.  There's no possible way to misread the unparenthesized form in this context, so there's no point at all to adding redundant parens.  "But some earlier version of the PEP may or may not have required them - I don't recall" is no longer a real point ;-) <br><br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
My current 3 pull requests showing how assignment expressions can be<br>
used in the stdlib:<br>
<br>
while True: <a href="https://github.com/python/cpython/pull/8095/files" rel="noreferrer" target="_blank">https://github.com/python/cpython/pull/8095/files</a><br>
match/group: <a href="https://github.com/python/cpython/pull/8097/files" rel="noreferrer" target="_blank">https://github.com/python/cpython/pull/8097/files</a><br>
list comp: <a href="https://github.com/python/cpython/pull/8098/files" rel="noreferrer" target="_blank">https://github.com/python/cpython/pull/8098/files</a><br></blockquote><div><br></div><div>And again I'm very happy you're doing this!  Just drop the uselessly distracting parens cluttering the dead obvious little wins ;-)</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Right now, I'm still not really excited by the new code.<br></blockquote><div><br>Me neiither - but I'm not looking for excitement here, and never was.  There's nothing exciting about little wins.  They're ...  little ;-)<br><br>I'm more _intrigued_ by the possibilities created by assignment expression targets living in the scope enclosing the outermost comprehension/genexp, but I don't expect to find existing code just waiting to be slightly rewritten to take advantage of that.  Although I certainly have "search loop" code that could be rewritten with some real effort to exploit the possibility of "exporting" the value that causes an `any(genexp)` or `all(genexp)` to terminate early.  If assignment expressions had been there, I would have written them with any/all from the start (even in Python 2, for-target names are "hidden" in genexps).<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">If you spotted other parts of the stdlib where assignment expressions<br>
would be appropriate, please tell me and I will try to write more pull<br>
requests :-)</blockquote><div><br>I will if it comes up, but don't expect that.  I did my code spelunking already, and stopped when I ceased learning anything new from it.</div><div><br></div></div></div>