Live data from Hacker News

What's Coming in Python 3.8

lwn.net

411–420 of 558 posts

Re: What's Coming in Python 3.8

#411
post #24
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.

“I've come up with a set of rules that describe our reactions to technologies: 1. Anything that is in the world when you’re born is normal and ordinary and is just a natural part of the way the world works. 2. Anything that's invented between when you’re fifteen and thirty-five is new and exciting and revolutionary and you can probably get a career in it. 3. Anything invented after you're thirty-five is against the n…

Except that Python existed before I was born and I still appreciate the concept of 'Pythonic'. The language should stay true to its roots.

Re: What's Coming in Python 3.8

#412

To me, the headline feature for Python 3.8 is shared memory for multiprocessing (contributed by Davin Potts). Some kinds of data can be passed back and forth between processes with near zero overhead (no pickling, sockets, or unpickling). This significantly improves Python's story for taking advantage of multiple cores.

Oh no way. That has huge potential. What are the limitations?

Re: What's Coming in Python 3.8

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

By itself I agree, every now and then you write a few lines that will be made a little shorter now that := exists.

But there's a long standing trend of adding more and more of these small features to what was quite a clean and small language. It's becoming more complicated, backwards compatibility suffers, the likelyhood your coworker uses some construct that you never use increases, there is more to know about Python.

Like f-strings, they are neat I guess. But we already had both % and .format(). Python is becoming messy.

I doubt this is worth that.

Re: What's Coming in Python 3.8

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

By itself I agree, every now and then you write a few lines that will be made a little shorter now that := exists. But there's a long standing trend of adding more and more of these small features to what was quite a clean and small language. It's becoming more complicated, backwards compatibility suffers, the likelyhood your coworker uses some construct that you never use increases, there is more to know about Pytho…

they should pick f and put depreciation warnings on the other two, python is getting messy.

Re: What's Coming in Python 3.8

#415
post #336

Earlier quoted context omitted.

Python is a little more readable, but both Python and Kotlin are perfectly clear in this case: sorted((u for u in users if u.last_name.startswith("S")), key=lambda u: u.last_name )[:3] If last_name is a function, which it often would be in Python, it gets better: sorted((u for u in users if last_name(u).startswith("S")), key=last_name )[:3] However, I think you probably got the sort key wrong if you're taking the fir…

I disagree this python version is as readable and here’s why. It’s about as many characters but more complex. The Kotlin version performs several distinct actions, each being clear to its purpose. These actions have the same syntax (eg requires less parsing effort). The Python version mixes at least 4 different language syntax/features, being list comprehension, if special form in the list comprehension, keywords, an…

One thing that I like more in the Python version is that it contains less names: .asSequence and .take are replaced by operators of much greater generality, while the ugly implicitly declared identifier it is replaced by explicitly deciding that sequence elements are u.

It should also be noted that Python would allow a more functional style, possibly leaving out the list comprehension.

Re: What's Coming in Python 3.8

#416

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…

Why can't you do this with Python? No one said you had to use any of these new features...

Though to me that's like saying, "I want this river to stop flowing" or "I'd prefer if the seasons didn't change."

Re: What's Coming in Python 3.8

#417
post #336

Earlier quoted context omitted.

> In a language with less features, you might have to write slightly more code, but the code you write will be more readable to everyone else. I disagree with this, which is precisely why I prefer feature rich languages like Java or better yet Kotlin. It doesn't get much more readable than something like: users.asSequence() .filter { it.lastName.startsWith("S") } .sortedBy { it.lastName } .take(3) Now try writing tha…

Python is a little more readable, but both Python and Kotlin are perfectly clear in this case: sorted((u for u in users if u.last_name.startswith("S")), key=lambda u: u.last_name )[:3] If last_name is a function, which it often would be in Python, it gets better: sorted((u for u in users if last_name(u).startswith("S")), key=last_name )[:3] However, I think you probably got the sort key wrong if you're taking the fir…

This isn't very readable at all and certainly not any more readable than a chain of method calls, being that you've spread the operations out in different places. It's not even syntactically obvious what the `key` argument is passed to if one doesn't know that `sorted` takes it. None of those problems exist when piping through normal functions or chaining method calls.

Python is for the most part overrated when it comes to these things, IMO. It's a nice enough language but it's aged badly and has an undeserved reputation for concision, readability and being "simple".

Re: What's Coming in Python 3.8

#418

To me, the headline feature for Python 3.8 is shared memory for multiprocessing (contributed by Davin Potts). Some kinds of data can be passed back and forth between processes with near zero overhead (no pickling, sockets, or unpickling). This significantly improves Python's story for taking advantage of multiple cores.

For us who didn't follow:

"multiprocessing.shared_memory — Provides shared memory for direct access across processes"

https://docs.python.org/3.9/library/multiprocessing.shared_m...

And it has the example which "demonstrates a practical use of the SharedMemory class with NumPy arrays, accessing the same numpy.ndarray from two distinct Python shells."

Also, SharedMemory

"Creates a new shared memory block or attaches to an existing shared memory block. Each shared memory block is assigned a unique name. In this way, one process can create a shared memory block with a particular name and a different process can attach to that same shared memory block using that same name.

As a resource for sharing data across processes, shared memory blocks may outlive the original process that created them. When one process no longer needs access to a shared memory block that might still be needed by other processes, the close() method should be called. When a shared memory block is no longer needed by any process, the unlink() method should be called to ensure proper cleanup."

Really nice.

Re: What's Coming in Python 3.8

#419
post #62

Earlier quoted context omitted.

But now there are two ways to do assignment. That's not very pythonic, is it?

You think that's bad? Check out: a = 17 print("a=", a) print("a=" + str(a)) print("a=%s" % a) print("a={}".format(a)) print(f"a={a}") # python 3.8 => print(f"{a=}") So many ways to do it... But, if it sounds like I agree with you, I actually don't. I feel that the Zen of Python has taken on an almost religious level of veneration in people's minds, and leads to all sorts of unproductive debates. One person can latch…

> there should be one obvious way to do it

In cases like this, different ways to do it (all equally good) are needed to get a good coverage of different tastes in obviousness and different nuances in the task.

The point is not uniformity, but avoiding the unpleasant and convoluted workarounds caused by non-obviousness (thus making the language easy to use).

String formatting is not trivial: there is the split (sometimes architectural, sometimes of taste, sometimes of emphasis) between concatenating string pieces, applying a format to objects, setting variable parts in templates, and other points of view; and there is a variety of different needs (cheap and convenient printing of data, dealing with special cases, complex templates...)

Re: What's Coming in Python 3.8

#420

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…

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. "Understanding" what each individual line means is very different from understanding the code. There are always higher level concepts you need to recognize, and it's often better for languages to support those concepts directly rather than requiring developers to consta…

Sometimes a language introduces a concept that's new to you. Then you need way more time. For example, monads : I understood it (the concept) rather quickly, but it took a few weeks to get it down so I could benefit from it.
Post reply on HN