Live data from Hacker News

What's Coming in Python 3.8

lwn.net

471–480 of 558 posts

Re: What's Coming in Python 3.8

#471

Earlier quoted context omitted.

F-strings have appeared 2 versions ago. All in all, the feedback we have has been overwhelmingly positive, including on maintenance and readability.

I second this. F-strings make string formatting so much more concise. I'm excited about the walrus operator for the same reason.

Not just more concise; less error prone.

A reasonably large number of the bugs I encounter relate to the order or number of formatting arguments not matching the slots in the format string. It's pretty hard to make that kind of mistake with an fstring.

Re: What's Coming in Python 3.8

#472
post #118

Despite controversy, walrus operator is going to be like f-strings. Before: "Why do we need another way to..." After: "Hey this is great". People are wtf-ing a bit about the positional-only parameters, but I view that as just a consistency change. It's a way to write in pure Python something that was previously only possible to say using the C api.

f-strings are the first truly-pretty way to do string formatting in python, and the best thing is that they avoid all of the shortcomings of other interpolation syntaxes I've worked with. It's one of those magical features that just lets you do exactly what you want without putting any thought at all into it. Digression on the old way's shortcomings: Probably the most annoying thing about the old "format" syntax was…

For me, the hugs thing about f-strings was that invalid string format characters become a compile time error (SyntaxError).

  print('I do not get executed :)')
  f'{!}'


  File "stefco.py", line 2
    f'{!}'
    ^
  SyntaxError: f-string: empty expression not allowed
This has the pleasing characteristic of eliminating an entire class of bug. :)

Re: What's Coming in Python 3.8

#473

Earlier quoted context omitted.

The problem with `while line := f.readline():` is that it takes preasure of library writers. You should really just do `for line in f:`. If the library only has a `next` function, it needs to be fixed.

`f` might be iterable / iterator with completely different semantics than doing by-line iteration. And that might even be a good idea.

In this case it isn't though. And if it were, you could provide an `f.lines()` iterator. The code would be much nicer that way.

Re: What's Coming in Python 3.8

#474

Earlier quoted context omitted.

Was the walrus operator really worth "The PEP 572 mess"? https://lwn.net/Articles/757713/ That post makes a few things very clear: * The argument over the feature did not establish an explicit measure of efficacy for the feature. The discussion struggled to even find relevant non-Toy code examples. * The communication over the feature was almost entirely over email, even when it got extremely contentious. There was l…

It may not have been a fair trade, but then it wasn't a trade in the first place. Those all seem to be problems with the process itself, meaning that it could have happened any time a contentious feature came up, this just happened to be the one to trigger the problem.

I agree that a mess looked (sadly) inevitable based upon that post and some of the other surrounding context. E.g. Guido citing Yoda conditions, how dumb that game can be, and getting ignored.

But just because the feature shipped and design-by-committee is upon us doesn't mean we need to accept the outcome. Why couldn't there have been a more evolutionary path for this feature? For example, there is surely a way to write a prototype library to accomplish the same effect with slightly different syntax. (How about a single function `walrus(a, b)` that does what `:=` does?). Then let real user adoption drive the change. Maybe somebody will discover case statements from scala and want that instead.

I hope the committee models some amount of their work after WG21. C++ hasn't evolved so effectively because some people were magic visionaries. For the past decade, C++ has mostly ridden on the proven success of boost. And skipped a lot of the parts of boost that suck.

Re: What's Coming in Python 3.8

#475

Earlier quoted context omitted.

Python 2.7 is not far from that language.

What's stopping people from forking the language at python 2.7? Let the pythonistas add whatever feature they feel like while people who need stability use "Fortran python" or whatever.

> What's stopping people from forking the language at python 2.7?

If you don't want to change/add something to the language, then why fork it?. You can just continue using it as it is!

Re: What's Coming in Python 3.8

#476
post #271

Earlier quoted context omitted.

It's wrong to frame this as resistance to change for no reason. See my other comment. I see some of this stuff as repeating mistakes that were made in the design of Perl. ...but there are quite few people around these days who know Perl well enough to recognize the way in which history is repeating itself, and that has at least something to do with age.

"resistance-to-change for-no-reason" vs "resistance-to change-for-no-reason" :)

Jeez. What number of people who read the same phrase with either of those two meanings then continue to form opinions and even make decisions based on the resulting meaning?

Re: What's Coming in Python 3.8

#477

Earlier quoted context omitted.

To be fair, Guido stepped down because of the way the community reacted. "The straw that broke the camel’s back was a very contentious Python enhancement proposal, where after I had accepted it, people went to social media like Twitter and said things that really hurt me personally. And some of the people who said hurtful things were actually core Python developers, so I felt that I didn’t quite have the trust of the…

It's really disappointing that people could get so worked up, over what is essentially deciding which color to paint the shed, that they chase off the project founder. I wonder if there is any way for open source communities to effectively promote the "take a step back and remember what really matters in life" approach to conflict resolution.

>I wonder if there is any way for open source communities to effectively promote the "take a step back and remember what really matters in life" approach to conflict resolution.

We've spent decades debating on the merits of spaces vs tabs, and Vim vs Emacs, and a ton of other completely pointless stuff.

What you're hoping is just a pipe dream, people will get invested in the most petty and asinine stuff out there, and take it as a personal insult if you disagree.

Re: What's Coming in Python 3.8

#478

I long for a language which has a basic featureset, and then "freezes", and no longer adds any more language features. You may continue working on the standard library, optimizing, etc. Just no new language features. In my opinion, someone should be able to learn all of a language in a few days, including every corner case and oddity, and then understand any code. If new language features get added over time, eventua…

Lua is a great small language.

Re: What's Coming in Python 3.8

#479

Earlier quoted context omitted.

I see this criticism every time the walrus operator is brought up. You do know that this: x := 1 Is going to be a syntax error, right? The walrus operator is not permitted in the case of a simple assignment statement. It's only in an expression.

But it used to be that any expression on its own was a valid statement. Is that going to change? When is an expression allowed to have := in it, is (x := 1) on its own allowed?

For contexts where the walrus is not allowed, see [0]. You'll find that it's generally possible to circumvent the restriction by parenthesising the expression. So yes,

    (x := 1)
is a valid (but poorly written) statement.

But while there are now two ways of doing assignment, I wonder how often people will actually encounter situations where it's difficult to figure out which choice is better.

[0] https://www.python.org/dev/peps/pep-0572/#exceptional-cases

Re: What's Coming in Python 3.8

#480

Speaking as someone who has written Python code almost every day for the last 16 years of my life: I'm not happy about this. Some of this stuff seems to me like it's opening the doors for some antipatterns that I'm consistently frustrated about when working with Perl code (that I didn't write myself). I had always been quite happy about the fact that Python didn't have language features to blur the lines between what…

> what's a statement vs what's an expression

never understood the need for this. why do you even need statements?

if there's one thing that annoys me in python it's that it has statements. worst programming language feature ever.

Post reply on HN