ALL Python 3.12's major typing improvements

Python 3.12 really hit the spot with typing aficionados, so here's a video looking at ALL the major typing improvements made!
-
If you enjoy my content, consider supporting me on Patreon or becoming a member!
patreon.carberra.xyz
join.carberra.xyz
If you need help with anything, feel free to join the Discord server:
discord.carberra.xyz
I get a lot of people asking, so here's my Visual Studio Code setup!
• My Visual Studio Code ...
-
If you have any questions, don't hesitate to ask in the comments! I'll try and answer as soon as I can, providing someone else hasn't already done so.
#python #coding #howto

[@Carberra]

I somehow managed to completely the new type keyword when doing my research for this; Indently made a great video showing it off for those who want to see it in action: ruclips.net/video/y8UUl-81_u0/видео.html

[@airatvaliullin8420]

this video is very nice, thanks!

[@fullstackspiderman]

Thank you for the great guidance..

[@truthmatters7573]

That was helpful! Python's type system is getting more and more powerful :) Maybe in the future fully typed code could even do something with types to make the code faster as an opt in feature

[@Carberra]

Some work was already done towards that in 3.11! Hopefully they go all the way with it, as I'm pretty sure it doesn't work for all code atm.

[@deadeye1982a]

Nice explanation. As a side note, return next(iter(seq)) is faster and saves memory. Think of a colossal list. Both versions fail with empty Iterables differently. Your example raises an IndexError, the next(iter(seq)) raises an StopIteration. You could raise in this case an IndexError, maybe. Second thought, perhaps a ValueError. Input is empty, that's bad.

[@notsobob]

Why is the return type of `__iter__` None? EDIT: oh fixed it later

[@senyai]

I was expecting to hear about 'type' statement.

[@khanra17]

this is the end of python. whats the point of this type of hacky implementations for type safety although its not safe? just use rust/java etc.
python is trying to be something it never can be. and forgetting its purpose "simplicity".
and no you can't just argue saying its optional. optional feature made it worse

[@Erliortmejurur]

Python is great for rapid prototyping. Sometimes those prototypes get a bit big, but you're close to making the client happy. So you want types, and you want to keep it in python. This improves on that.

[@GeorgeNoiseless]

Such keen insight! I for one am utterly swayed!
Any further argument would clearly be a waste of precious energy and word-smithing inspiration, thus let us put a capstone on this matter and proceed to greener discussant pastures with utter finality.

[@Indently]

"This is the end of Python" 🤣🤣🤣 I think you should take a break from coding and start your career in Fox News ahaha. That cracked me up big time.

[@maksimon519]

just learn how to program

[@lightningstrike2001]

"This is the end of python!" - people who said that before python 3.0 was released

[@kvelez]

from typing import TypedDict, Unpack, NotRequired
class Kwargs(TypedDict):
name: str
age: NotRequired[int]
def profile(**kwargs: Unpack[Kwargs]):
for k, v in kwargs.items():
print(f"{k}:{v}")
if __name__ == "__main__":
profile(name="Kevin")
===========================================
from typing import override
class Fruit:
def grow(self):
print("I grew")

def consume(self):
print("Enjoy meal.")
class Banana(Fruit):
@override
def consume(self):
print("Potassium for free")
fruit = Banana()
fruit.consume()
===========================================
from typing import TypeVar, Generic, Iterable, Iterator
T_co = TypeVar("T_co", covariant=True)
class ImmutableList(Generic[T_co]):
def __init__(self, items) -> None:
self.items = items
def __iter__(self) -> Iterator[T_co]:
return iter(self.items)

class Employee:
def __init__(self, name) -> None:
self.name = name
class Manager(Employee):
def __init__(self, name) -> None:
super().__init__(name)
if __name__ == "__main__":
people = ImmutableList([Employee("Kevin"), Manager("Jane")])
print(people)