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

461–470 of 558 posts

Re: What's Coming in Python 3.8

#461

Post by amelius »

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

Yes, the problem is sharing data between parent and child after the parent process has been forked.

Re: What's Coming in Python 3.8

#462

Post by n3k5 »

sammorrowdrums wrote: post #391
fny wrote: post #224

Earlier quoted context omitted.

I love string interpolation! But this seems to take it to a bizarre level place just to save a few keystrokes. Seriously, how is f"{now=!s}" substantially better than f"now={str(now)}"? Ergonomically, I see little benefit for the added complexity.

It really feels like it's very explicit at this point that you want to cast whatever value interpolated into your format string to a string... I don't want a type error for the most clear use case, in the same way I don't want one for print, because if I wanted a behaviour other than the basic string representation then I would still need to call something differently anyway. Given that explicit control of the __str_…

In GP's example, the call to str() isn't there to make sure you get a string instead of causing a type error; it's there to substitute str() for repr() (which also returns a string). Considering that this feature is mainly meant to make 'print debugging' more convenient, it makes sense that repr() is the default choice.

Re: What's Coming in Python 3.8

#463

Post by hjk05 »

heavenlyblue wrote: post #459
uranusjr wrote: post #426

Earlier quoted context omitted.

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.

They could... but then they wouldn’t return the interpolated string, and they’d be just like using format, just saving the characters “.format” which ruins the exact thing people like about them.

Re: What's Coming in Python 3.8

#464

Post by V-2 »

kragen wrote: post #336
RhodesianHunter wrote: post #293

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…

C# supports both conventions (in LINQ) - I mean the Kotlin one from the grandparent comment, and the Python's from parent's.

The method chaining syntax and the query syntax are alternatives. I think most devs lean towards the former, considered to be cleaner... whereas the latter is probably easier to learn in the beginning, to those unfamiliar with piping/functional style - owing to its SQL feel-alikeness.

ReSharper would offer converting the latter to the former, and that's how I learned method-chaining LINQ back in the day.

Re: What's Coming in Python 3.8

#465

Post by megla_ »

coldtea wrote: post #444
megla_ wrote: post #441

Earlier quoted context omitted.

I genuinely haven't heard of 13 of those and I'd say I'm quite interested in learning about languages. The few that I know, were just briefly mentioned by a professor, so I don't know anything apart from the name. What qualifies as prominent to you? How old are you? On Tiobe Index only Pascal and Go are in the first 50, while half of them aren't even listed in the first 100. Sure they're important and had an impact o…

> I genuinely haven't heard of at least a third of them and I'd say I'm quite interested in trying new (and possibly unusual) languages. But perhaps not as interested in trying old and significant languages? > What qualifies as prominent to you? On Tiobe Index only Pascal and Go are in the first 50, while half of them aren't even listed in the first 100. Sure they're important and had an impact on new languages, but…

>Well, Lisp was made 60+ years ago, and C 50 years ago, so?

Well, they're still seeing widespread use, that's why they're on Tiobe, while others faded into obscurity. Those languages are historically significant, but nowadays they're basically useless apart from scientific use and maintaning old software.

Maybe you should understand that the majority of programmers are younger than Python and don't study the same material they did 30 years ago, because a whole lot of history happened in that time. Also I'm not sure how not knowing about Simula makes me unqualified for anything.

I've noticed, not just in this reply, but in all of your comments; your condescending tone and indirect addressing make you seem like an unpleasant person.

Using these qualities makes one seem like some stuck-up pseudointellectual boomer.

Re: What's Coming in Python 3.8

#467

Post by quietbritishjim »

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.

It looks like this will make efficient data transfer much more convenient, but it's worth noting this had always been possible with some manual effort. Python has had `mmap` support at least as long ago as Python 2.7, which works fine for zero-overhead transfer of data.

With mmap you have to specify a file name (actually a file number), but so long as you set the length to zero before you close it there's no reason any data would get written to disk. On Unix you can even unlink the file before you start writing it if you wish, or create it with the tempfile module and never give it a file name at all (although this makes it harder to open in other processes as they can't then just mmap by file name). The mmap object satisfies the buffer protocol so you can create numpy arrays that directly reference the bytes in it. The memory-mapped data can be shared between processes regardless of whether they use the multiprocessing module or even whether they're all written in Python.

https://docs.python.org/3.7/library/mmap.html

Re: What's Coming in Python 3.8

#468

Post by uryga »

stakhanov wrote: post #132
ashton314 wrote: post #53

Earlier quoted context omitted.

Many languages don't distinguish between statements and expressions—in some languages, this is because everything is an expression! I'm most familiar with these kinds of languages. I'm not familiar much with Python, beyond a little I wrote in my linear algebra class. How much does the statement/literal distinction matter to readability? What does that do for the language?

The philosophy that most of Python's language design is based on is that for everything you want to do, there should be one and only one obvious way to do it. The first part of the statement (at least one obvious way to do it) goes to gaining a lot of expressive power from having learned only a subset of the language specification corresponding to the most important concepts. So you invest only a small amount of time…

> "iterate through a list of strings, and print each one"

  print(*lst, sep='\n')
:)

Re: What's Coming in Python 3.8

#469

Post by duckerude »

pmontra wrote: post #273
duckerude wrote: post #185

Earlier quoted context omitted.

f-strings need a prefix so old strings can keep working the same way. If `print("{x}")` printed "{x}" in Python 3.5, it shouldn't print something else in a newer version. But `print(f"{x}")` was a syntax error before f-strings, so no code is broken by giving it a meaning. JavaScript can't interpolate ordinary strings either, for the same reason. You need to use backticks (``).

You're correct about JavaScript. I forgot about the backticks. Thank you for the explanation of the f-strings. I'm pretty sure that migrating old strings to "\{x\}" could be automated but we can't force everybody to migrate their code. There is probably no other way than the one they followed.

"\{x\}" includes the backslashes into the string literally. So even if that worked for f-strings it would change the meaning for older Python versions. Requiring people to update common old code is also just something to avoid unless necessary.

The correct way to escape braces in f-strings is with double braces, so f"{{x}}". This is consistent with the way str.format works. f-string syntax is very similar to str.format syntax in general.

Re: What's Coming in Python 3.8

#470

Post by uryga »

ezrast wrote: post #134
ashton314 wrote: post #53

Earlier quoted context omitted.

Many languages don't distinguish between statements and expressions—in some languages, this is because everything is an expression! I'm most familiar with these kinds of languages. I'm not familiar much with Python, beyond a little I wrote in my linear algebra class. How much does the statement/literal distinction matter to readability? What does that do for the language?

It's natural for some operations to be used only for their side effects, and for those a return value is just noise. What does a while loop evaluate to in your favorite language? Are there any circumstances where you'd want to assign one to a variable? What do you lose by making that a parser error?

> What does a while loop evaluate to in your favorite language?

depends on what you want! for example this Haskell package¹ defines three versions of while:

  -- collect the result of each iteration into a list
  whileM :: Monad m => m Bool -> m a -> m [a]

  -- combine the result of each iteration together into a final result
  whileM' :: (Monad m, MonadPlus f) => m Bool -> m a -> m (f a)
  
  -- drop the results and return `()`
  whileM_ :: Monad m => m Bool -> m a -> m ()
by convention, the ones ending in an underscore (`forM_`, `whileM_`, `sequence_` etc) drop their results, i.e. are only used for their side-effects.

¹ http://hackage.haskell.org/package/monad-loops-0.4.3/docs/Co...

Post reply on HN