Python 3.8.0a1 is now available for testing
41–50 of 59 posts
Re: Python 3.8.0a1 is now available for testing
#42Re: Python 3.8.0a1 is now available for testing
#43Earlier quoted context omitted.
It is definitely useful, but it severely reduces readability in my opinion. Your example is also a great example for this. The first version in way more readable than the second version with the walrus operator.
I agree with you. It's very exciting to remove these sorts of redundant lines, but I cannot train my brain to intuitively view that line as it will be interpreted. There is one case where the benefit, IMHO, far outweighs the negatives, and that can be seen in slides 30-31 of Dustin Ingram's slideshow[1]. PEP 572... the day Python jumped the walrus. 1. https://speakerdeck.com/di_codes/pep-572-the-walrus-operator...
Any C program can be written as a single line, with no linebreaks - that doesn't make it "better" by any metric.
Python is built around its readability, and slide 44:
> group = match.group(1) if (match := re.match(data)) else None
is anything but. 'match' is assigned after its first use, and it took me far to long to mentally parse what it was doing.
Re: Python 3.8.0a1 is now available for testing
#44Earlier quoted context omitted.
I find it always decreases readability. I literally cannot read C code that does this, now I'm going to have to worry about encountering unreadable Python code. Edit: Also, it violates both "explicit is better than implicit" and "there should be one and only one right way to do it". It's inherently Unpythonic.
I agree that it's a violation of the “one and only one” maxim, but that maxim is a bit hard to take as an absolute. I think the problem is that there are already a lot of ways to write things in Python, the biggest example that comes to mind is list comprehensions. outputs = [f(x) for x in inputs] Versus: outputs = [] for x in inputs: outputs.append(f(x)) The assignment expression lets you: outputs = [y for x in inpu…
outputs = [y for x in inputs
if (y := f(x)) is not None]
I can't stand this new syntax, y is declared and assigned after the first instance of its use.Re: Python 3.8.0a1 is now available for testing
#45Are assignment expressions the only linguistic change? For years,I've been holding my breath in Python for sum types, totality checking, and an enforced, complete type system -- one where you can say "this should be a list of lists of integers" and it won't let you put any other kind of thing there. (Yes, there are external typing solutions like PyPy, but last I checked they did not offer complete type systems (you c…
Python type annotations do support such use case: List[int].
Re: Python 3.8.0a1 is now available for testing
#46Are assignment expressions the only linguistic change? For years,I've been holding my breath in Python for sum types, totality checking, and an enforced, complete type system -- one where you can say "this should be a list of lists of integers" and it won't let you put any other kind of thing there. (Yes, there are external typing solutions like PyPy, but last I checked they did not offer complete type systems (you c…
> but not that it’s a list of ints Python type annotations do support such use case: List[int].
What about functions, and functions of functions, etc? Can I specify that the argument to function f should be some other function g which should receive a list of ints and return a dict of functions with keys that are ints and values that are functions from int to int?
Re: Python 3.8.0a1 is now available for testing
#47Earlier quoted context omitted.
> but not that it’s a list of ints Python type annotations do support such use case: List[int].
Omg really? Sweet! What about functions, and functions of functions, etc? Can I specify that the argument to function f should be some other function g which should receive a list of ints and return a dict of functions with keys that are ints and values that are functions from int to int?
Re: Python 3.8.0a1 is now available for testing
#48Notably new is the assignment expressions [1]. This was quite controversial and the battle around it caused Guido to step down as BDFL [2]. I personally think it's quite a nifty feature. I often end up writing something along the lines of: result = do_something() if result: do_more(result) Now that can be expressed as: if result := do_something(): do_more(result) It definitely has the potential to be abused and reduc…
It is definitely useful, but it severely reduces readability in my opinion. Your example is also a great example for this. The first version in way more readable than the second version with the walrus operator.
Even if you accept that there is some continuum of "...ability" of these things, it's completely arbitrary and unique to everyone as to where the line between "this should be in" and "this should be out" lies.
Re: Python 3.8.0a1 is now available for testing
#49Earlier quoted context omitted.
It is definitely useful, but it severely reduces readability in my opinion. Your example is also a great example for this. The first version in way more readable than the second version with the walrus operator.
I agree with you. It's very exciting to remove these sorts of redundant lines, but I cannot train my brain to intuitively view that line as it will be interpreted. There is one case where the benefit, IMHO, far outweighs the negatives, and that can be seen in slides 30-31 of Dustin Ingram's slideshow[1]. PEP 572... the day Python jumped the walrus. 1. https://speakerdeck.com/di_codes/pep-572-the-walrus-operator...
I... don't believe you. "Will not", "refuse to"? Sure. But "cannot", no.
Re: Python 3.8.0a1 is now available for testing
#50Notably new is the assignment expressions [1]. This was quite controversial and the battle around it caused Guido to step down as BDFL [2]. I personally think it's quite a nifty feature. I often end up writing something along the lines of: result = do_something() if result: do_more(result) Now that can be expressed as: if result := do_something(): do_more(result) It definitely has the potential to be abused and reduc…
I find it always decreases readability. I literally cannot read C code that does this, now I'm going to have to worry about encountering unreadable Python code. Edit: Also, it violates both "explicit is better than implicit" and "there should be one and only one right way to do it". It's inherently Unpythonic.
Hogwash. You choose to not.