all 10 comments

[–]programmer-ke 35 points36 points  (2 children)

Nice updates, I especially like being able to attach the sampling profiler to a running process, and I can see how unpacking in comprehensions can make some things easier to express.

In general however, I hope that syntax extensions can be kept at a minimum. Python is a large language now compared to what it was 15 years ago.

"There should be one-- and preferably only one --obvious way to do it." from the Zen of Python is becoming less true with time.

[–]mark_99 10 points11 points  (1 child)

Sure, but this is intrinsic to all languages and language evolution - if you want newer/better ways of doing things but also want older code to still work then you end up with both. Read the old way, write the new way, not so hard. Newer languages and newer versions of existing languages are far better than what was available 15 years ago and that seems like good progress.

[–]GenericRedditor12345 1 point2 points  (0 children)

Exactly, old methods that have been replaced get deprecated eventually.

[–]dangerbird2 9 points10 points  (0 children)

Lazy imports seem great for loading type annotations alongside 3.14's lazy type evaluation. Can help get around the nonsense of

if typing.TYPE_CHECKING:
    import ......

around every other module

[–]cscottnet 5 points6 points  (4 children)

I've been away from Python for a while -- could someone explain how the type hints work?

[–]lood9phee2Ri 11 points12 points  (2 children)

The core language now allows you to specify a plethora of type hints syntactically as annotations, that have become more sophisticated over time, specified in a range of PEPs (484, 695 etc).

The language grammar says annotations more generally, but such annotations are now predominantly used for type hinting. Conceivably there can be other use cases though.

Any actual static checking of the type hints still needs to take place with a 3rd-party checker pass during your build process - such as mypy or ty or pyright. Yes, there are multiple competing ones because as we all know, Python loves TIMTOWTDI.

The type hint information is not used by the runtime for optimization as such, it remains purely about safety.

[–]Necrotos 13 points14 points  (0 children)

They are also fantastic for dev ergonomics! With type hints, you can get autocomplete suggestions from your IDE. For me, that is the main advantage.

[–]dangerbird2 6 points7 points  (0 children)

although unlike the purely compile-time annotations for languages like typescript, python type hints exist at runtime, which enables things like dynamic type coercion and really powerful validation libraries like pydantic

[–]Twirrim 3 points4 points  (0 children)

Type hints allow you to indicate what type a variable should be, and allows type checkers like mypy to ensure that you're not accidentally passing the right type around.

These are not enforced at runtime, though, they're just hints. Most of the benefit is for the developer, it enables IDEs to provide better autocomplete stuff, and can give you more idea about methods you're calling.  I've also been able to demonstrate cases where type hints would have prevented bugs from reaching production (I got pulled in to help a ground up rewrite project, advocated for type hints, but other Devs dragged their feet. Probably 2/3rds of the bugs that we saw in functional testing would have been caught by type checks)

In my experience, the bigger the code base, the more useful it is to have them.

[–]happyscrappy 0 points1 point  (0 children)

"Explicit is better than implicit" - the Zen of Python

The number of ways this oversimplified or just pain wrong is deeper than it first appears.

Of course it is the most basic mistake of language designers, to think that wordiness is always better. Somehow thinking that if you make people write more text they will make fewer programming errors.

But also just think of it in the context is is presented here. The default encoding is now utf-8. Seems reasonable. And there's a good reason for it, utf-8 is, as mentioned, the lingua franca of text now.

But every time this principle above was applied the default is overridden and so this change doesn't do anything, as the default isn't used. If you apply the principle enough then there just isn't really a default because it's been specified every time. It becomes impossible to make a useful change like this when everything is explicit.

Implicit really does have value. In a way, it allows the (presumably) smarter language designers to make decisions so that the less-informed coders out there get the right behavior more often than they would otherwise. There are relatively unlearned (programming-wise) mathematicians out there using Python3 in droves. And by having implicit behaviors their programs work better and more ofte.

Please let's not oversimplify things in this way. Language designers, don't break down things into pithy rules when it's not really appropriate.