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 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
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
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 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
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)
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.
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)
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.
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?
"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)
@@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?
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']) ```
@@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 :)
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
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.
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
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.
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
![[#2024MAMA] ROSÉ (로제), Bruno Mars - APT. | Mnet 241122 방송](http://i.ytimg.com/vi/dgGqD28J6aQ/mqdefault.jpg)
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".
Incognito mode exists
it does exist -- but this is just raw google chrome with history on
For me "p" directs to "pytorch".
@@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
this is great, very Rust-like
I think they should use for generics
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
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
@@rosmelylawliet It's already used for type hinting, though, like list[int]
@@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
Well I don't know if I like this new syntax but I know I've always hated the weirdly redundant TypeVar syntax.
why didn't they just use the industry standard of ? oh well
@@BenjaminWheeler0510 wasnt industry standard when python first introduced typing. Now they have to keep with it for backwards compatibility
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)
if it is possible, please make a video about variants; thank you.
Maybe I've been brainwashed by C++ but I find the new syntax very readable and natural.
Looks a lot like Go generics syntax, thanks for the video!
5:08 That's the most logical syntax to me, what would you have preferred?
Good stuff, as per usual!
Thank you for sharing
for someone who uses typevars a lot this syntax kinda grew in me tbh…
So cool! Hype 🎉
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.
Hi Anthony, nice video as always! would be nice to hear your thoughts on typing.Annotated!
tbh I haven't really used it, I steer far away from runtime annotations
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)
it's familiar if you've worked with generics in other languages -- though they tend to use angle brackets instead
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.
What is the video talking about covariance ?
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
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?
"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)
@@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?
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'])
```
@@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 :)
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
I like types, yes I do. I like types, how about you?
after watching this video i have only one question: python wtf are you doing?
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.
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.
@@float32but swift is not good outside of macos. What do you use Python for?
How do you remember all the syntaxs without any code completion or autosuggesions? 🙄
Some people are just built different
That kind of skill is built over time. Eventually, you get used to it.
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
Hurray! Good riddance to "from ___future___ import annotations."
3:00 AI grifters fuming right now
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.
it's not for the runtime, it's for type checkers
No performance gain, just useless syntax stuff that is littering Python.
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
yada yada, try supporting a project without type hints, where everything is a plain dict
then we'll talk about 'littering'