Live data from Hacker News

What's Coming in Python 3.8

lwn.net

201–210 of 558 posts

Re: What's Coming in Python 3.8

#201
post #8

Python looks more and more foreign with each release. I'm not sure what happened after 3.3 but it seems like the whole philosophy of "pythonic", emphasizing simplicity, readability and "only one straightforward way to do it" is rapidly disappearing.

In my experience, every technology focused on building a "simple" alternative to a long-established "complex" technology is doomed to discover exactly _why_ the other one became "complex." Also spawn at least five "simple" alternatives. Doesn't mean nothing good comes out of them, and if it's simplicity that motivates people then eh, I'll take it, but gosh darn the cycle is a bit grating by now.

Could you provide some examples? Without having had that experience, I’m having trouble picturing a concrete example that I would be sure is of the same kind.

Re: What's Coming in Python 3.8

#202
post #8

Python looks more and more foreign with each release. I'm not sure what happened after 3.3 but it seems like the whole philosophy of "pythonic", emphasizing simplicity, readability and "only one straightforward way to do it" is rapidly disappearing.

Can you give an example of something like this happening to the language? IMO 3.6+ brought many positive additions to the language, which I also think are needed as its audience grows and its use cases expand accordingly. The walrus operator makes while loops easier to read, write and reason about. Type annotations were a necessary and IMO delightful addition to the language as people started writing bigger productio…

What would "do/while" look like in Python? Since blocks don't have end markers (e.g. "end", "}", etc.) there's nowhere to put the while expression if you want the syntax to be consistent with the rest of the language.

Re: What's Coming in Python 3.8

#203

Earlier quoted context omitted.

> The fact that there is now an operator that can only be used in certain statements just makes things more confusing The new operator (like many Python operators) can only be used in expressions (statements can contain expressions, but expressions are not a subset of statements.) > The fact that there is now an operator that can only be used in certain statements just makes things more confusing Because the “=” oper…

>it would be create potential readability difficulties for human reading I think the major argument (at least, the one I see most frequently) is that the walrus operator does create readability difficulties for humans, which is exactly why many people view it as non-pythonic. This is one of the few times I've seen someone argue that ":=" makes things more readable.

An argument against expression assignment is that it can create readability problems compared to separating the assignment from the expression in which the value is used. Even most supporters of the feature agree that this can be true in many cases and that it should be used judiciously.

This is in no way contrary to the argument that the walrus operator improves readability of expression assignments compared to using the same operator that defines assignment statements.

Re: What's Coming in Python 3.8

#204

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…

All you're doing then is moving the evolution of the language into the common libraries, community conventions, and tooling. Think of JavaScript before ES2015: it had stayed almost unchanged for more than a decade, and as a result, knowing JavaScript meant knowing JS and jQuery, prototype, underscore, various promise libraries, AMD/commonjs/require based module systems, followed by an explosion of "transpiled to vani…

It's apples and oranges.

Python was explicitly designed and had a dedicated BDFL for the vast majority of its nearly 30 year history functioning as a standards body.

JS, on the other hand, was hacked together in a week in the mid-90s and then the baseline implementation that could be relied on was emergent behavior at best, anarchy at worst for 15 years.

Re: What's Coming in Python 3.8

#205

Anyone else think the walrus operator is just plain ugly? There is a certain aesthetic quality that I've always appreciated about the Python language and the walrus operator looks like something straight out of Perl or Shell.

Looks pretty normal if you do any amount of Go.

Re: What's Coming in Python 3.8

#206
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.

I've literally been wanting something like the walrus operator since I first started using Python in '97. Mostly for the "m = re.match(x, y); if m: do_something()" sort of syntax.

Re: What's Coming in Python 3.8

#207
post #202

Earlier quoted context omitted.

Can you give an example of something like this happening to the language? IMO 3.6+ brought many positive additions to the language, which I also think are needed as its audience grows and its use cases expand accordingly. The walrus operator makes while loops easier to read, write and reason about. Type annotations were a necessary and IMO delightful addition to the language as people started writing bigger productio…

What would "do/while" look like in Python? Since blocks don't have end markers (e.g. "end", "}", etc.) there's nowhere to put the while expression if you want the syntax to be consistent with the rest of the language.

I envisioned it like "if/else" or "for/else" or "while/else", where a "do" block must be followed by a "while" block.

    x = 0
    do:
        x += 1
    while:
        x 

Re: What's Coming in Python 3.8

#208
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.

Was the controversy really about the need for the feature? I thought most people agreed it was a great feature to have, and most of the arguments were about `:=` vs re-using `as` for the operator.

I don't know in this case, but I do know that the Python community tends to have strong opinions about things. The := resulted in Guido stepping down, which I think is a good indicator that there wasn't agreement that it was "a great feature to have" and just down to syntax... :-(

Re: What's Coming in Python 3.8

#209

There's a lot of talk in this thread about Python going down-hill and becoming less obvious/simple. I rather like modern python, but I agree that some features (like async/await, whose implementation fractures functions and libraries into two colors [0]) seem like downgrades in "Pythonicity". That said, I think some things have unquestionably gotten more "Pythonic" with time, and the := operator is one of those. In c…

You are supposed to write

    for x in iter(f.readline, ""):
Or if you don't know what readline will return you can wrap it in your own lambda:

    for x in iter(lambda:f.readline() or None, None):
There is a lot you can do with iter to write the kind of loops you want but it's not well known for some reason. It's a very basic part of the language people seem to overlook. Walrus does however let you write the slightly more useful

    while predicate(x:=whatever()):
Which doesn't decompose easily into iter form.

Re: What's Coming in Python 3.8

#210
post #158

Earlier quoted context omitted.

I don’t see why. ‘Assign x’ and ‘is x truthy’ can be understood separately. Worry about what x is being assigned. Then worry about whether its value is truthy.

like I said, the whole pattern is more than two lines. the pattern is actually assign-test-fallback-test-fallback-test-etc. to quote the PEP: reductor = dispatch_table.get(cls) if reductor: rv = reductor(x) else: reductor = getattr(x, "__reduce_ex__", None) if reductor: rv = reductor(4) else: reductor = getattr(x, "__reduce__", None) if reductor: rv = reductor() else: raise Error( "un(deep)copyable object of type %s"…

[deleted]
Post reply on HN