Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What's Coming in Python 3.8

lwn.net

Post reply on HN
Print view View original

451–460 of 558 posts

Re: What's Coming in Python 3.8

#451

Post by orf »

Redoubts wrote: post #374
orf wrote: post #314

Earlier quoted context omitted.

Fixing the entirely broken string/bytes mess up in Python 2 was worth it by itself. For bonus points old style classes went away, and the language got a significant speed boost. And now it’s not going to die a slow death, choking on the past poor decisions it’s burdened with. Trivializing that by suggesting it was some offhand, unneeded solution to a problem that some dreamy “language designer” thought up is at best…

> and the language got a significant speed boost. I have not seen a clear win in real benchmarks. 3 was slower for the longest time, and nowadays it seems head to head depending on the project.

Check out https://speed.python.org/comparison/. It’s not significantly faster, but it’s getting more so.

Re: What's Coming in Python 3.8

#452

Post by amedvednikov »

hexane360 wrote: post #369
noname120 wrote: post #160

Earlier quoted context omitted.

Really interesting. For the skeptics, this is not just a proof of concept. There is a real app made using this language: https://volt-app.com/

and the REPL only leaks 1MB [1] to compile and run a hello world program. 1: https://github.com/vlang/v/issues/514

It doesn't anymore.

There are lots of issues that are being fixed. Strange nitpicking on alpha software.

Re: What's Coming in Python 3.8

#453

Post by tasubotadas »

ben509 wrote: post #330
tasubotadas wrote: post #234

I'll just put a reminder here that it's the year 2019 and AMD and Intel has 10-core CPUs while Python is still stuck with GIL ¯\_(ツ)_/¯

It's the current year! This is slated for 3.9: https://www.python.org/dev/peps/pep-0554/

I think we both know that it's a poor substitute for proper threading.

Re: What's Coming in Python 3.8

#454

Post by riffraff »

masklinn wrote: post #446
riffraff wrote: post #365

Earlier quoted context omitted.

I also cannot honestly think of a case where I want that behaviour. The "pow" example looks more like a case where the C side should be fixed.

> I also cannot honestly think of a case where I want that behaviour. There's plenty of situations where a named argument does not help, and encoding it can only hurt. It makes little to no sense to name the first argument to `dict.update` for instance. Or the argument to `ord`. That, incidentally, is why Swift added support for positional-only parameters (though it has no concept of keyword-or-positional).

It does not help but doesn't hurt enough to grant a special syntax to avoid it.

Yes, it limits your ability to rename a local variable, but that seems minor.

Re: What's Coming in Python 3.8

#455

Post by agent008t »

raymondh wrote: post #402

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.

Isn't that already the case?

I thought that when you use multiprocessing in Python, a new process gets forked, and while each new process has separate virtual memory, that virtual memory points to the same physical location until the process tries to write to it (i.e. copy-on-write)?

Re: What's Coming in Python 3.8

#456

Post by zubspace »

hu3 wrote: post #102
londons_explore wrote: post #70

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…

From what I've seen, Go is the closest we have for mainstream language resistant to change.

Recently the Go team decided not to add the try-keyword to the language. I'm not a Go programmer and was a bit stumped by the decision until I saw a talk of Rob Pike regarding the fundamental principle of Go to stick to simplicity first. [1]

One of the takeaways is, that most languages and their features converge to a point, where each language contains all the features of the other languages. C++, Java and C# are primary examples. At the same time complexity increases.

Go is different, because of the simplicity first rule. It easens the burden on the programmer and on the maintainer. I think python would definitely profit from such a mindset.

[1] https://www.youtube.com/watch?v=rFejpH_tAHM

Re: What's Coming in Python 3.8

#457

Post by jashmatthews »

agent008t wrote: post #455
raymondh wrote: post #402

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.

Isn't that already the case? I thought that when you use multiprocessing in Python, a new process gets forked, and while each new process has separate virtual memory, that virtual memory points to the same physical location until the process tries to write to it (i.e. copy-on-write)?

That's true but running VMs mutate their heaps, both managed and malloced. CoW also only works from parent to child. You can't share mutable memory this way.

Empty space in internal pages gets used allocating new objects, refence counts updated or GC flags get flipped etc, and it just takes one write in each 4kb page to trigger a whole page copy.

It doesn't take long before a busy web worker etc will cause a huge chunk of the memory to be copied into the child.

There are definitely ways to make it much more effective like this work by Instagram that went into Python 3.7: https://instagram-engineering.com/copy-on-write-friendly-pyt...

Re: What's Coming in Python 3.8

#458

Post by jstimpfle »

fatbird wrote: post #213
jasonrhaas wrote: post #11

The walrus operator does not feel like Python to me. I'm not a big fan of these types of one liner statements where one line is doing more than one thing. It violates the philosophies of Python and UNIX where one function, or one line, should preferably only do one thing, and do it well. I get the idea behind the :=, but I do think it's an unnecessary addition to Python.

The unix philosophy of simplicity was on a per tool basis, not function or line of code. The walrus operator is Python version of what we can do now in C or in JS, doing plain assignment in an expression while evaluating it for truthiness. And more often than not, the point of that single-purposeness in Unix is so you can chain a bunch of piped commands that result in a perl-like spaghetti command that's three termin…

> while evaluating it for truthiness

no, it evaluates to the left side's value after assignment

Re: What's Coming in Python 3.8

#459

Post by heavenlyblue »

uranusjr wrote: post #426
vorticalbox wrote: post #414

Earlier quoted context omitted.

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

They can’t just deprecate the other two; f-string’s nature precludes it from being used in situations where formatting needs to occur lazily, e.g. i18n. This is the same reason why other languages with string interpolation also keep a format method around, e.g. Swift’s String(format:). I guess you could argue that they should at least deprecate %-formatting, and this has indeed been raised multiple times, even prior…

Nothing stops one from evaluating f-strings lazily. They could simply return a format string with parameters captured instead of interpolated string.

Re: What's Coming in Python 3.8

#460

Post by bvrmn »

strictfp wrote: post #76
ProjectBarks wrote: post #67

The changes to f-strings just seems like a step in the wrong direction. Don't make the string content implicit!

Also, why abandon printf-style? All languages tend to converge to printf over time, it's simply the most tried and tested model out there!

Format string is very inconvenient approach because you need to duplicate type information.

>>> '%i' % 's' Traceback (most recent call last): File "", line 1, in TypeError: %i format: a number is required, not str >>> '{}'.format('s') 's' >>> '{}'.format(10) '10'

Post reply on HN