NEW generic / alias syntax for python 3.12 (PEP 695) (intermediate) anthony explains

[@MostWantedracer]

Here's to Anthony: The only guy who's not afraid of opening a browser window in front of you *while recording* and typing something that starts with "P".

[@csanadtemesvari9251]

Incognito mode exists

[@anthonywritescode]

it does exist -- but this is just raw google chrome with history on

[@calebparks8318]

For me "p" directs to "pytorch".

[@hamzadlm6625]

​@@csanadtemesvari9251 either you don't know what incognito looks like, or you dare to assume he doesn't know that it exists, both are unrecoverably stupid

[@unvergebeneid]

Well I don't know if I like this new syntax but I know I've always hated the weirdly redundant TypeVar syntax.

[@BenjaminWheeler0510]

why didn't they just use the industry standard of ? oh well

[@Redstoner237Channel]

@@BenjaminWheeler0510 wasnt industry standard when python first introduced typing. Now they have to keep with it for backwards compatibility

[@anthonywritescode]

that's simply not true -- c# generics were 2005, java generics were 2004, c++98 had templates (and some compilers back until 1991 had some form of templates) all with angle brackets long before python typing was even an idea (mypy first released in 2009, python 3.0 syntax was 2008, the typing module was 2015)

[@rexase]

this is great, very Rust-like I think they should use for generics

[@rosmelylawliet]

i would have loved that, as `[...]` is already used for indexes/keys, whereas `` is invalid. i would need to check the pep to see the reason why they went this way, there's likely a reason

[@anthonywritescode]

my understanding is there's already usage of `[...]` in python so when generics were originally added it was "natural" with the syntax -- whereas angle brackets are only used for comparisons and would have needed a bigger lift to adopt them as a syntax construct maybe if they went back today and redid everything without regards for backwards compatibility it'd be with angle brackets -- but it'd be too much of a lift to just do it now

[@PanduPoluan]

​@@rosmelylawliet It's already used for type hinting, though, like list[int]

[@rosmelylawliet]

@@PanduPoluan true, i don't like that either, i think all hinting and generics should've been using however, i also don't mind THAT much, i'm fine as it is now, it is what it is :P

[@amirongoogle4795]

if it is possible, please make a video about variants; thank you.

[@workflowinmind]

5:08 That's the most logical syntax to me, what would you have preferred?

[@BrunoBeltran]

Maybe I've been brainwashed by C++ but I find the new syntax very readable and natural.

[@iliya-malecki]

why is it def f[T: (str, bytes)](x:T):... and not def f[T: str | bytes](x:T):...? i tried the version that is more intuitive to me and it works. Is it not guaranteed to work? whats the deal with the whole thing?

[@anthonywritescode]

"it works" -- nothing is checking these in python itself -- it would be up to the typechecker to validate those it's a tuple because that's how it is specced -- yours is different saying that T must be a subclass of a union of int and str -- which is impossible because there exists no class which is a subclass of both int and str (so the typechecker should produce an error)

[@iliya-malecki]

@@anthonywritescode No no when i say "it works" i mean pyright in strict mode doesnt complain. Also, "a subclass of both int and str" is an intersection type (which i know doesnt exist yet), not a union, so doesnt it mean that T is a subclass of a Union[int, str] if it is a subclass of either int or str?

[@anthonywritescode]

youtube deleted my response because it was too long -- I misspoke about this and got it backwards but they still mean different things (the union can be satisfied by a union whereas the tuple has distinct bounds) an example: ``` from collections.abc import Sequence def f[T: int | str](a: Sequence[T], b: Sequence[T]) -> list[T]: return [*a, *b] def g[T: (int, str)](a: Sequence[T], b: Sequence[T]) -> list[T]: return [*a, *b] f([1], ['2']) f([1], [2]) f(['1'], ['2']) # g([1], ['2']) not allowed: must be a uniform list g([1], [2]) g(['1'], ['2']) ```

[@iliya-malecki]

@@anthonywritescode wow, this is massive! This essentially solves the "cat in the list of animals" problem that plagues, among others, typescript. Another huge victory! Can we celebrate or should we wait for intersection types first? Also, I would love a video on intermediate/advanced typing tricks, do you plan on making one? Please do, love your content :)

[@anthonywritescode]

tbf this already exists but the syntax changes how it works -- you can do the same thing with TypeVar("T", int, str) vs TypeVar("T", bound=int | str) I do occasionally do some tricks like this but they're not always so universally applicable -- maybe I'll cover this one though

[@NicolasChanCSY]

This change does not look very intuitive... In addition, now the function signatures become so long when we add type hints, how should we cope with the 80-ish characters per line rule of PEP8? (Yes, I think 80-ish is still better even when we have much wider screens these days)

[@anthonywritescode]

it's familiar if you've worked with generics in other languages -- though they tend to use angle brackets instead

[@probablyskela]

You can have multiline function signatures with each argument on it's own line which should eliminate the problem unless you have very, very long function, argument, and type hint names.

[@RoyAAD]

What is the video talking about covariance ?

[@anthonywritescode]

I haven't released it yet. I wasn't happy with my first two attempts at recording it and set it aside for a while

[@mrswats]

Good stuff, as per usual!

[@qexat]

for someone who uses typevars a lot this syntax kinda grew in me tbh…

[@bradb4143]

Looks a lot like Go generics syntax, thanks for the video!

[@yorailevi6747]

At this point, almost all languages are functionally the same with different syntax. everything but maybe rust which can be emulated with robust linter in cpp.

[@hamzadlm6625]

Thank you for sharing

[@fuadnafiz98]

How do you remember all the syntaxs without any code completion or autosuggesions? 🙄

[@timbrap4693]

Some people are just built different

[@juniorceccon]

That kind of skill is built over time. Eventually, you get used to it.

[@IonizedComa]

its easier to do it with python because it's an easily read language, i'm able to do it with C as well. But Java and C++ I have problems remembering most things. Also depends on which language you use often

[@AceofSpades5757]

So cool! Hype 🎉

[@blanky_nap]

after watching this video i have only one question: python wtf are you doing?

[@float32]

I’m thinking of moving to swift. If I wanted all this complexity, I would use a compiled language and get 10x the performance, so might as well.

[@yomajo]

For most of my usecases I use built in types or my own classes for typehints, and have no idea what a Generic is... This seems like a woke trend in python. A shame.

[@lonterel4704]

​@@float32but swift is not good outside of macos. What do you use Python for?

[@ismailbello513]

Hi Anthony, nice video as always! would be nice to hear your thoughts on typing.Annotated!

[@anthonywritescode]

tbh I haven't really used it, I steer far away from runtime annotations

[@BenjaminWheeler0510]

I like types, yes I do. I like types, how about you?

[@loopingdope]

Yes

[@calebparks8318]

Hurray! Good riddance to "from ___future___ import annotations."

[@ericng8807]

3:00 AI grifters fuming right now

[@MrYevelnad]

IDK why python implemented generics when its a dynamically typed language. I'm kinda hyped when I first knew this and it is much simpler to implement in 3.12. I play with it a bit and came to a conclusion that it is pretty much useless in python.

[@anthonywritescode]

it's not for the runtime, it's for type checkers

[@mailoisback]

No performance gain, just useless syntax stuff that is littering Python.

[@anthonywritescode]

technically this performs better than TypeVar(...) calls since it's all lazily evaluated -- and 3.12 did improve performance quite a bit for basically everything not defending the syntax in any way -- just correcting your baseless complaints

[@user-qi5kb5th7y]

yada yada, try supporting a project without type hints, where everything is a plain dict then we'll talk about 'littering'