Live data from Hacker News

Python 3.8.0a1 is now available for testing

pythoninsider.blogspot.com

41–50 of 59 posts

Re: Python 3.8.0a1 is now available for testing

#43
post #4

Earlier 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 can't take a programming talk seriously if it declares in giant font "Less lines are better" (slide 38).

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

#44
post #13

Earlier 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

#45

Are 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].

Re: Python 3.8.0a1 is now available for testing

#46

Are 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].

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

#47

Earlier 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?

Yes, you can do that too.

Re: Python 3.8.0a1 is now available for testing

#48
post #4
post #2

Notably 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.

"readability" is such a crap excuse for or against things. Everything is unreadable until you learn to read it. Reading is simply a mapping of what you see, to internalized meaning.

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

#49
post #4

Earlier 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...

> but I cannot train my brain to intuitively view that line as it will be interpreted.

I... don't believe you. "Will not", "refuse to"? Sure. But "cannot", no.

Re: Python 3.8.0a1 is now available for testing

#50
post #13
post #2

Notably 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.

> I literally cannot read C code that does this,

Hogwash. You choose to not.

Post reply on HN