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

What’s New in Python 3.8

docs.python.org

Post reply on HN
Print view View original

301–310 of 381 posts

Re: What’s New in Python 3.8

#301

Post by ash »

bhl wrote: post #150
airstrike wrote: post #4

The expansion of f-strings is a welcome addition. The more I use them, the happier I am that they exist https://docs.python.org/3/whatsnew/3.8.html#f-strings-suppor...

Why didn’t Python ship with the opposite functionality as well? Parsing instead of formatting. Given a string and a format string, return a list of variables (or a dictionary).

Are you talking about parsing f-strings? How would that look like?

As far I understand the following:

    print(f"your name is {name}")
is roughly equivalent to:

    print(f"your name is " + format(name))
What is there to parse?

Re: What’s New in Python 3.8

#302

Post by Razengan »

grincho wrote: post #85
robocat wrote: post #56

Earlier quoted context omitted.

There are programming fonts that use ligatures to convert >= to ≥, or -> to →, so the source code remains in ASCII but symbol sequences show as unique Unicode characters. A next step could be for common dev environments to actually convert symbol/key sequences to operators (how do APL programmers do it?) Avoiding ambiguity and semantic overloading of ASCII symbols would surely help beginners (if also given a UI that…

The Mac has provided easy access to symbols since 1984, with nice mnemonics like these: option-= ≠ option- ≥ option-/ ÷ option-o ø option-w ∑ I don't know why other OSes haven't adopted something similar. The first couple of these were even idiomatic in HyperCard's scripting language.

I like to use characters like those as custom operators whenever I can. :)

Re: What’s New in Python 3.8

#303

Post by Grue3 »

diminoten wrote: post #23
lidHanteyk wrote: post #18

Earlier quoted context omitted.

It's almost as if the Python Software Foundation isn't capable of killing the Python 2 language unilaterally without the Python community's consent.

It's almost as if people were given 12 fucking years (or admittedly fewer, depending on when your favorite library was migrated) to move over, didn't, and are now obstinately standing in the way of forward progress.

It's almost as if programming languages live forever as long as there's production code that uses them. See: COBOL.

Re: What’s New in Python 3.8

#304

Post by metalforever »

paulddraper wrote: post #73
CivBase wrote: post #22

As a developer who has primarily developed applications in Python for his entire professional career, I can't say I'm especially excited about any of the "headlining" features of 3.8. The "walrus operator" will occasionally be useful, but I doubt I will find many effective uses for it. Same with the forced positional/keyword arguments and the "self-documenting" f-string expressions. Even when they have a use, it's us…

> As a developer who has primarily developed applications in Python for his entire professional career, I can't say I'm especially excited about any of the "headlining" features of 3.8. Python is a fairly old, mature language. What features would you have been especially excited about?

I would honestly like an option to "compile" python to check for typing inconsistencies with the type hinting introduced in Python 3. Also, the multithreading story is kinda shitty

Re: What’s New in Python 3.8

#305

Post by ktpsns »

Grue3 wrote: post #298
paulddraper wrote: post #73

Earlier quoted context omitted.

> As a developer who has primarily developed applications in Python for his entire professional career, I can't say I'm especially excited about any of the "headlining" features of 3.8. Python is a fairly old, mature language. What features would you have been especially excited about?

Multi-line/multi-expression lambdas. "end" statement which would enable automatic indentation. "switch" statement instead of "if/elif/.../else" hell.

Oh yes, too all of them!

Correctly done multi-line lambdas/expressions could bring Python's expressivitiy to where ECMAScript is nowadays, where you can write both foo = function(...) or function foo().

Perl 6 has a great switch statement, called "given" https://docs.perl6.org/language/control#given

Re: What’s New in Python 3.8

#306

Post by varelaz »

Everything of this looks like syntax sugar. I would expect more work on internals. Python has a lot of awkward edge cases in standard lib. In a lot of cases None is valid output for not-done states. Also I hate multithreading programming in Python 3, it has all drawbacks of C with additions of GIL.

Re: What’s New in Python 3.8

#307

Post by xamuel »

Xophmeister wrote: post #241

This got missed from the release announcement, but now there's `functools.singledispatchmethod`,[1] as the class method sibling to `functools.singledispatch`.[2] This allows you to overload the implementation of a function (and now a method) based on the type of its first argument. This saves you writing code like: def foo(bar): if isinstance(bar, Quux): # Treat bar as a Quux elif isinstance(bar, Xyzzy): # Treat bar…

I don't understand why anyone would want singledispatch. Instead of having the function defined in one place where you can look it up, now the function is potentially scattered all over the place. (I'm not talking hypothetically. I've had the 'pleasure' of working on a codebase where different singledispatch cases of the same function were defined in different files!)

Re: What’s New in Python 3.8

#308

Post by Liquid_Fire »

probably_wrong wrote: post #270
omginternets wrote: post #253

I stepped away from Python for about a year, and now I'm coming back to it. I hardly recognize the language. I'm not happy about this at all. I don't really have a point, except that Python 3 feels like a moving target.

I feel the same way as you do. For me, which version of an interpreter I'm using should be the kind of issue I only need to worry when solving extremely specific, deep-level problems. Python 3+ breaks this pact too often for my taste. Considering this f-string example taken from another announcement: f"Diameter {(diam := 2 * r)} gives circumference {math.pi * diam:.2f}" This is valid Python 3.8, but it's not valid in…

I'm not sure why you frame this as an issue with Python 3. This has always been the case, even in the 2.x days every release added new features, and if you ran code using them in an older version it wouldn't work.

The minor releases are always backward-compatible, so just run the latest version and everything will work.

Re: What’s New in Python 3.8

#309

Post by tvelichkov »

trymas wrote: post #228
CivBase wrote: post #22

As a developer who has primarily developed applications in Python for his entire professional career, I can't say I'm especially excited about any of the "headlining" features of 3.8. The "walrus operator" will occasionally be useful, but I doubt I will find many effective uses for it. Same with the forced positional/keyword arguments and the "self-documenting" f-string expressions. Even when they have a use, it's us…

IMHO walrus operator goes against the zen of python. https://www.python.org/dev/peps/pep-0572/#differences-betwee... https://www.python.org/dev/peps/pep-0572/#relative-precedenc... Even examples of the spec shows how unintuitive and "unpythonic" this is. Explicit is better than implicit. IMHO adding features to the language to save 1 line of code for 10% of cases when you need it (I agree that there's occasional case…

Well the zen of python also states:

- Complex is better than complicated.

Using the walrus operator makes the code more complex, but less complicated.

Re: What’s New in Python 3.8

#310

Post by CreRecombinase »

xamuel wrote: post #307
Xophmeister wrote: post #241

This got missed from the release announcement, but now there's `functools.singledispatchmethod`,[1] as the class method sibling to `functools.singledispatch`.[2] This allows you to overload the implementation of a function (and now a method) based on the type of its first argument. This saves you writing code like: def foo(bar): if isinstance(bar, Quux): # Treat bar as a Quux elif isinstance(bar, Xyzzy): # Treat bar…

I don't understand why anyone would want singledispatch. Instead of having the function defined in one place where you can look it up, now the function is potentially scattered all over the place. (I'm not talking hypothetically. I've had the 'pleasure' of working on a codebase where different singledispatch cases of the same function were defined in different files!)

Because if you need to branch based on type more than a few times in your function it can get pretty hard to read. Am I right that the basis of your complaint is that it's now harder to find all the members of (what you'd call in C++) the "overload set" for a particular function? If so I can see your point.
Post reply on HN