This video is rather misleading. The `typing` module is not getting deprecated. Many aliases, like the ones shown in the video, are deprecated since Python 3.9. Types such as `Any`, `Self`, `Optional`, `Literal`, and more are still accessed through the `typing` module.
I still think it's a bad idea to mark a function deprecated and silently alias it to the replacement. It leads to terrible UX/habits because the LS cannot tell you that you're having a bad practice by using the deprecated version.. And even for backward compatibility, having a warning when using a deprecated alias isn't a lot to ask.
@@Oler-yx7xjThe typing/collections version allows you to also specify the type of whatever is contained inside of that list, set, dict, etc. too though (e.g. List[str] or Set[int]). So, I would stick to that for most use-cases to be even more clear on the type that's expected to go in or out of your function.
The documentation and the PEP (585) do state their reason for not annotating it as deprecated. Type checking is left to type checkers, not the interpreter. Quote, "It is expected that type checkers will flag the deprecated types when the checked program targets Python 3.9 or newer." Removal is also documented: "Removal will occur no sooner than Python 3.9’s end of life, scheduled for October 2025." I think it's fair of Python to expect type checkers to do their job properly, but I also understand the confusion it might cause if the types are eventually just gone.
@@cach_diesbecause it was nobody's job. Nobody was asked to mark it as deprecated, only suggested to do so, and so it probably won't happen because the buck will keep getting passed.
@@cach_dies Because of PEP 563, which defined/changed how annotations work, you can not have annotations on typings without impacting runtime performance of the typing system.
To be fair: Your types are not evaluated during runtime, so python cannot give you a deprecation warning. But I guess PyCharm could have added a rule to show you this deprecation warning. ruff does so.
They've been deprecated since 3.9, but weirdly there are (currently) no concrete plans to actually remove these aliases. Even looking forward as far as 3.16 there's nothing. I think they might be "soft-deprecated" or something, as yeah Pylance doesn't mark them as deprecated either. I forget how I found out initially actually, I remember something flagged it to me, though I still use typing lmao.
There are plans to remove them some time after 3.9’s end of life in 2025. And type checkers are meant to flag this deprecation when targeting 3.9+, but have failed to do so for whatever reason.
This actually makes sense when you take into account that the old capitalized types like List, Dict and Optional from typing have been replaced with more straightforward syntax. So now many programs won't need to use the typing module at all.
Those are ones that, unlike the built-in list and collections.abc.Iterable, have nothing to do with subscripting for generics and don’t have the same justification for removal.
View any video by Raymond Hettinger (the creator of itertools), he's a great teacher, esp "super considered super" if you're doing multiple inheritance. Also the somewhat dated "Loop like a native" by Ned Batchelder...if you ever find yourself looping over indices, yeah: that needs a refactor.
I just discovered it now! Thank you very much for the info. I absolutely agree on your opinion about typing, was great to have the typing module and I also not received any warning (vscode).
I always like to think that the people who work on these things put loads of energy and thought into it. I personally did not share the vision in their PEP completely. I prefer that all types remain available in the typing module because that's an incredibly intuitive place to find "types" for your code. I mean what's next? Moving all the types to their respective modules? Like next thing you know you will have to import Iterator from itertools. I'm looking forward to reading more sides and opinions to this, because as it stands, from what I've seen and read, they're just silently removing duplicates from Python.
A lot of comments already talked about the fact that it is the checkers that should display a deprecation warning and not the interpreter. However this video doesn't explain the change that occurred in Python 3.9 in itself. At least, not entirely. Type hints before 3.9 were using at the same time standard built-in Python types (like int and str) and the typing module for more complex type hints. The best example I can think of right now is "List". To type hint a list of strings you had to do something like from typing import List def foo(bar: List[str]) -> None: After 3.9, the [] notation is now available for native Python types. That's why you don't need typing anymore. So, our example above becames: def foo(bar: list[str]) -> None: Without any import and using the native list type. Same thing for collections.abc.Callable or Iterable which are the real fully-fledged Python types instead of some cluncky aliases that could only be use for type hints. I do think this was a really cool update, it simplified my code and is way less confusing than having two types for the same thing
I was aware of all the variations, but presumed that typing was the preferred option due to it being newer and more precise of a description in my opinion. I looked into it, and the reason for this change is obvious now. When generic variations of the types in abc were introduced, they could not be applied to the type itself because of limitations in Python. Since 3.9, it became possible to apply the generic typing to the classes itself. Therefore, the use of the typing module is now obsolete. Looking into it it makes sense. But not a single editor has ever provided any indication of the deprecation. So I falsely made an assumption that the new version would be preferred. I think this is a completely reasonable assumption to make if you are not aware of the relevant context, so this should have been communicated more clearly.
The title/thumbnail of this video is super misleading and frankly harmful. The parts of typing that are getting deprecated are the parts that are useless aliases, for example typing.List is now just an alias to the normal list. I think this is a very good thing, since it moves people away from having to care about the split from normal classes and typing classes. This is even more of a non issue since from future import __annotations__ exist.
I'm surprised python developers didn't put a deprecated action on the actual code to let us all know. I appreciate you bringing this to my attention. I'm erked too.
I also had no idea. Honestly they should have made it more explicit, not just in documentation. If it was deprecated then i personally I would have liked an error or some sort of warning from pycharm. But oh well i guess we have to read the whole documentation, from start to end to find out.
As far as I am aware, a type such as _collections.abc.Iterable_ is an actual, valid type, checkable at runtime with _isinstance_ . I am not sure if _typing.Iterable_ can be used to the same effect. I will admit, I'm not a huge fan, but I guess it makes sense if they are checkable at runtime to move them into more relevant modules
Well, almost everything related to typing in python is quite chaotic and doesn't seem to have a single direction. The idea behind removing Iterable and things like that from typing is that they are not just for type hints, you could actually inherit from them and automatically receive implementation of some collection-related methods. That is runtime and not type checking. The decision to not generate DeprecationWarning is weird too. BTW, that leaves a question: what the hell is Callable doing in collections.abs? :-D
@@IndentlyTwo things I think happened. First it didn't fit into how typing was being narrowed. Might be wrong about this since I'm still expanding my knowledge on Python but doesn't Generators get typed as Callable so can return in that way return a collection? Might also just be they knew it did fit in typing so just kicked it down the road by moving it to collections instead😉
While it's not a replacement for Iterable since that's broader, I'd say one of the most useful things they could do is accept syntax like list[int] and dict[str, int], but alas.
ok so, I don't mind putting the type representative classes in the location where they're used; collection types should go in the collections module, that's just common sense. What really gets ME is that "Callable" is in collections. WHY?? That's clearly not a collection! If anything it should've gone in functools or sth!
If you use pyupgrade or ruff, rule UP035 will warn you to use the proper import. There are other relevant typing rules too, such as UP006 (use list[T] instead of typing.List[T]) and UP007 (use X | Y instead typing.Union[X, Y]).
If you think of it from a Java dev perspective, it makes sense that all the ...able are moved to abc. If an object is ...able, this is a behavior, and it is not implemented in Java as a strict type. Java uses interfaces for that, which is a kind of abstraction. So, moving ...able types to the "abstract base class" makes more sense than leaving them in "typing"
Finally somebody realizes it! I was confused ever since 3.9 and wasn't able to find any information about typing and it becoming more and more obsolete. By now typing as a logically (in)complete module should be looked at as a messy result of overthought concepts of which language part should be responsible for type hints.
Oy. Single-letter package renames are disgusting. Stop it. It’s convenient for you at exactly one moment, when you’re writing it. It will be inconvenient for you and anyone else who ever has to read that dogshit, in perpetuity. Stop it. Please.
honestly, i think they should deprecate the entire module. Make all its features baked in to the standard library types or even to the language syntax itself
As someone who enjoys functional programming, I am wary of the demo code you showed, because it makes the implicit assumption that you can print() the elements of the iterable, which in Haskell isn't a given. that is, in Haskell you would need to specify it as Iterable, and the elements as printable.
Most of the type annotation tutorials I've found describe it using older versions of Python, and then I have to hunt for what has changed and how. They are also frequently incomplete because they only explain the new features (this is fine, just not what I need). Do any of you know where I would find a complete tutorial on the topic using 3.11 at least?
Noticed that too. It's a bit annoying. Not gonna say it's pointless, but it feels like yet another "just use this to do this, don't ask" parts of python, which is hardly a desired approach if you want to make a beginners friendly language.
Please don't, the tools around TS are what made me quit learning it. Nothing seems to "just work", unless you use something like Vite or Deno. But if you do that, you won't understand how TSC works. But if you try to figure out the TS tooling you'll run into insane error messages like: "unknown file extension '.ts'" When you try to use ts-node with ESM modules. 💀
I agree, they should have made it better known. Removing the call to typing may affect existing code, not knowing when or if makes it difficult to judge how important it is to examine existing code to make changes. Hopefully they will make it more explicit if they chose to remove the call and give sufficient time for programmers to make adjutments.
When you run the code ALL typing is ignored anyway since it's not part of the runtime it's just there for the external type checkers to use. As far as python itself is concerned everything is just type ANY😉😂
Maintaining an open-source language is such a tough job, make a decision wrong and it's very hard to undo, we can't satisfy everyone, just try to minimize the impact of inevitable changes.
I would be surprised if the typing module ever went away purely for backward compatibility reasons. Maybe with Python 4 but not 3.x. Edit: the guidance that it is "deprecated" just means its not the official path but the code should still run until Python decides to break its API.
I miss a tutorial for the type checking. On the Python website I can find a Python tutorial, but nothing about type annotations. Can I define my own types? When are two types compatible?
If you read the mypy current documentation (1.11.2) then all of the examples happily use `from typing import Iterator, Iterable, ...`. I guess the mypy authors didn't get that memo either.
so everything that can be used from `typing` library can also be done with `collections.abc`? you just need to swap importing `typing` --> `collections.abc`? (for python 3.9+)
tuples, lists, dicts and sets are not in `collections.abc`, they should be just subscripted as is `list[str]` and a couple of other things are also renamed
it seems that collections abc are catching up to support type annotations by allowing subscripting. Thus these 'aliases' from typing library are no longer necessary. using the from module import type method seems more maintainable than using import aliases in this case.
I guess because Python still remains a dynamically typed language this might have something to do with it? But I don't see why this has been moved to the collections package. Is there even any difference in functionality?
I think you're just a month or so early about this, once Python 3.8 is EOL this october, type checkers should start complaining about it as minimum Python version everywhere becomes 3.9
Makes me wonder if using "external" libraries are worth the risk of the additional dependency. Writing your own libraries has two benefits: first, it can't be depricated on you; and second, it can be as lean as you want. You can't control the bloat of external libraries.
@@kc12394 Makes no difference to me if they are "out-of-the-box" Python or not. Any library you import that you didn't write exposes you to an external dependency; which is a future risk.
@@mikesmith6838yeah next thing you know there will be a new version of python and it'll change something in the language and make me change my code. Guess I better just write my own language instead🤔🙄🤦♂️
@@mikesmith6838i am pretty much agreeing with you, except that if everyone publish their own version of basic libraries in each project, first you have to "reinvent the wheel" everytime and second PyPI will quickly explode from data overloading
@@mikesmith6838 This is pretty backwards. Makes sense if it's a thing or two here and there but are you going to rewrite your own IO library, TCP server, multithreading library in python every single time just to avoid it being deprecated in the future? By your logic the only way forward is to create your own language, since languages also get deprecated too, look at python 2.
Great change. Never understood why there is distinct list and typing.List and etc. It’s a big skill issue that static typers dont mention about deprication and python devs decided not to do this either.
First time since I heard about it, since I am learning python lool.. But in my opinion, it is just unnecessary change to go from one module to another which provides identical functionality
They should never be removed and even should be un-deprecated. Why? Because List[T] looks like a real class. For context - they also deprecated typing.List, .Dict, and other when they changed typing in the last releases
In the end, the typing module, along with type annotations, is just a tool to give linters and type-checkers more information about the code. Deprecated or not, the interpreter will just ignore annotations at runtime. The code will keep the same behavior.
Well it makes a huge difference if it's deprecated and then removed, because then linters might not recognise it anymore eventually, and Python might give you an ImportError if they remove it.
So you were happy and productive before learning of the type deprecation. Perhaps ignorance really is bliss. Similar to the James Webb Space Telescope, a great engineering achievement that "deprecated" many commonly believed astronomical theories.
This just means yet another reason to pin your code to a specific range of Python versions. I don't think I have ever encountered a programming language that didn't require pinning to a specific version.
python annotations are not forcing python developer to check the data types, other languages like typescript is much better than python in dealing with types.
Do you realize it is done on purpose, so you have more flexible language? Tyle hints/ annotations is just a bad feature, but so many people love it for some reason
No... Just no. Type hint is incredibly important even if you are not shipping a library. It's so easy to just put your cursor on a function and see the argument types and attributes the function or class expects.
![ประสบการณ์ จ้าง Developer ที่ผมจะไม่มีวันลืม [ภาค1]](http://i.ytimg.com/vi/bzivN4KDg-k/mqdefault.jpg)
I think typing shouldn't be deprecated because I usually use my hands and a keyboard to type in my code.
This video is rather misleading. The `typing` module is not getting deprecated. Many aliases, like the ones shown in the video, are deprecated since Python 3.9. Types such as `Any`, `Self`, `Optional`, `Literal`, and more are still accessed through the `typing` module.
yea. I feel like we have a revival of super clickbaity titles. The titles are often flat out wrong and you only realize that half way into the video
Wait, so now we have to use 2 modules for typing?!
@ilya238 No, just use what you like. They are aliases to the real module anyway.
I still think it's a bad idea to mark a function deprecated and silently alias it to the replacement. It leads to terrible UX/habits because the LS cannot tell you that you're having a bad practice by using the deprecated version.. And even for backward compatibility, having a warning when using a deprecated alias isn't a lot to ask.
Actually instead of writing Optional[str], you should rather write str | None
But I agree with you otherwise
Now I have to type an extra dot in my imports, with everything going on in the world, I have to deal with too!?
I've never related to a comment so much as this one.
For lists, dicts and sets, you don't even need to import anything, so there is some good to it
It’s 9 extra chars though!
@@Oler-yx7xjThe typing/collections version allows you to also specify the type of whatever is contained inside of that list, set, dict, etc. too though (e.g. List[str] or Set[int]). So, I would stick to that for most use-cases to be even more clear on the type that's expected to go in or out of your function.
@@dantemendez3743 are you not using the most recent version? You can index the builtins now. dict[K, V] is a thing.
The documentation and the PEP (585) do state their reason for not annotating it as deprecated. Type checking is left to type checkers, not the interpreter. Quote, "It is expected that type checkers will flag the deprecated types when the checked program targets Python 3.9 or newer."
Removal is also documented:
"Removal will occur no sooner than Python 3.9’s end of life, scheduled for October 2025."
I think it's fair of Python to expect type checkers to do their job properly, but I also understand the confusion it might cause if the types are eventually just gone.
What is the reason for not annotating as deprecated?
@@cach_diesbecause it was nobody's job. Nobody was asked to mark it as deprecated, only suggested to do so, and so it probably won't happen because the buck will keep getting passed.
@@cach_dies Because of PEP 563, which defined/changed how annotations work, you can not have annotations on typings without impacting runtime performance of the typing system.
To be fair: Your types are not evaluated during runtime, so python cannot give you a deprecation warning.
But I guess PyCharm could have added a rule to show you this deprecation warning. ruff does so.
Exactly, it is the job of the tools that analyze type annotations.
It can give you one for merely importing the typing module.
I found out about this from ruff
@@HaganeNoGijutsushi but the typing module as a whole is not deprecated only the container types
Which rule in the ruff does this?
They've been deprecated since 3.9, but weirdly there are (currently) no concrete plans to actually remove these aliases. Even looking forward as far as 3.16 there's nothing. I think they might be "soft-deprecated" or something, as yeah Pylance doesn't mark them as deprecated either. I forget how I found out initially actually, I remember something flagged it to me, though I still use typing lmao.
I love the term "soft-deprecation" (added in version 3.9)
There are plans to remove them some time after 3.9’s end of life in 2025. And type checkers are meant to flag this deprecation when targeting 3.9+, but have failed to do so for whatever reason.
@@GiveMeSomeMeshuggah Given that python does not do BC, I don't really believe that it will really be removed at the risk of having surprises.
This actually makes sense when you take into account that the old capitalized types like List, Dict and Optional from typing have been replaced with more straightforward syntax. So now many programs won't need to use the typing module at all.
Note that not everything in the typing module is being deprecated, for example 'Literal' and 'Optional' are staying (for now).
Those are ones that, unlike the built-in list and collections.abc.Iterable, have nothing to do with subscripting for generics and don’t have the same justification for removal.
Except optional is the same as “type1 | None” so you should just use that instead.
@@soupoverflow except for when you use a string to refer to your type (e.g. Singleton pattern), where afaik you need Optional.
And NamedTuple
@@Marc-ElianBegin isn’t it possible to use a forward reference by putting the whole thing in quotes like:
“MyType | None”
I am just learning python at my job. This is my "go to" channel to learn python stuff. Focused and straight to the point videos. Awesome.
View any video by Raymond Hettinger (the creator of itertools), he's a great teacher, esp "super considered super" if you're doing multiple inheritance.
Also the somewhat dated "Loop like a native" by Ned Batchelder...if you ever find yourself looping over indices, yeah: that needs a refactor.
I just discovered it now! Thank you very much for the info. I absolutely agree on your opinion about typing, was great to have the typing module and I also not received any warning (vscode).
I always like to think that the people who work on these things put loads of energy and thought into it. I personally did not share the vision in their PEP completely. I prefer that all types remain available in the typing module because that's an incredibly intuitive place to find "types" for your code.
I mean what's next? Moving all the types to their respective modules? Like next thing you know you will have to import Iterator from itertools.
I'm looking forward to reading more sides and opinions to this, because as it stands, from what I've seen and read, they're just silently removing duplicates from Python.
We're obsessed with typing module 🥺❤
A lot of comments already talked about the fact that it is the checkers that should display a deprecation warning and not the interpreter.
However this video doesn't explain the change that occurred in Python 3.9 in itself. At least, not entirely.
Type hints before 3.9 were using at the same time standard built-in Python types (like int and str) and the typing module for more complex type hints. The best example I can think of right now is "List". To type hint a list of strings you had to do something like
from typing import List
def foo(bar: List[str]) -> None:
After 3.9, the [] notation is now available for native Python types. That's why you don't need typing anymore. So, our example above becames:
def foo(bar: list[str]) -> None:
Without any import and using the native list type. Same thing for collections.abc.Callable or Iterable which are the real fully-fledged Python types instead of some cluncky aliases that could only be use for type hints.
I do think this was a really cool update, it simplified my code and is way less confusing than having two types for the same thing
Also built in types (list, tuple, dict) can be used for type annotation, instead of typing.List, etc.
I was aware of all the variations, but presumed that typing was the preferred option due to it being newer and more precise of a description in my opinion. I looked into it, and the reason for this change is obvious now. When generic variations of the types in abc were introduced, they could not be applied to the type itself because of limitations in Python. Since 3.9, it became possible to apply the generic typing to the classes itself. Therefore, the use of the typing module is now obsolete.
Looking into it it makes sense. But not a single editor has ever provided any indication of the deprecation. So I falsely made an assumption that the new version would be preferred. I think this is a completely reasonable assumption to make if you are not aware of the relevant context, so this should have been communicated more clearly.
The title/thumbnail of this video is super misleading and frankly harmful. The parts of typing that are getting deprecated are the parts that are useless aliases, for example typing.List is now just an alias to the normal list. I think this is a very good thing, since it moves people away from having to care about the split from normal classes and typing classes. This is even more of a non issue since from future import __annotations__ exist.
I'm surprised python developers didn't put a deprecated action on the actual code to let us all know.
I appreciate you bringing this to my attention. I'm erked too.
It just feels so silent and sneaky, even if they gave us 5 years to prepare for this before they might remove it.
I also had no idea. Honestly they should have made it more explicit, not just in documentation. If it was deprecated then i personally I would have liked an error or some sort of warning from pycharm. But oh well i guess we have to read the whole documentation, from start to end to find out.
Why's callable under collections???
Because you iterate over collections, one assumes.
@@talideonWhat does callable have to do with iteration?!
technically... a callable with bound arguments is a collection because it stores the bound arguments
@@MagicGonads Technically a collection is a function, because it maps indices to other values, so clearly all of this should be in functools. :P
@@blenderpanzi collections do not map indices to values in general
As far as I am aware, a type such as _collections.abc.Iterable_ is an actual, valid type, checkable at runtime with _isinstance_ .
I am not sure if _typing.Iterable_ can be used to the same effect.
I will admit, I'm not a huge fan, but I guess it makes sense if they are checkable at runtime to move them into more relevant modules
Well, almost everything related to typing in python is quite chaotic and doesn't seem to have a single direction. The idea behind removing Iterable and things like that from typing is that they are not just for type hints, you could actually inherit from them and automatically receive implementation of some collection-related methods. That is runtime and not type checking. The decision to not generate DeprecationWarning is weird too.
BTW, that leaves a question: what the hell is Callable doing in collections.abs? :-D
whats wrong about callable being in the abc?
@@kezif Nothing is wrong with abc. Why Callable is a collection?
I'm also curious to hear why Callable is a collection ahah
@@IndentlyTwo things I think happened. First it didn't fit into how typing was being narrowed. Might be wrong about this since I'm still expanding my knowledge on Python but doesn't Generators get typed as Callable so can return in that way return a collection? Might also just be they knew it did fit in typing so just kicked it down the road by moving it to collections instead😉
While it's not a replacement for Iterable since that's broader, I'd say one of the most useful things they could do is accept syntax like list[int] and dict[str, int], but alas.
Thanks for the video! Most of the linters such as Ruff were warning about this deprecation long time ago
Ah good to know that some linters catch this! Like it's shameful that Mypy doesn't even mention it in my opinion.
but pylint don't do that...
What’s that lint called in ruff?
@@AlexandreJasminsuper linter implemented with Rust.
Give it a try with pip install ruff
ok so, I don't mind putting the type representative classes in the location where they're used; collection types should go in the collections module, that's just common sense. What really gets ME is that "Callable" is in collections. WHY?? That's clearly not a collection! If anything it should've gone in functools or sth!
Awesome to know! I had no idea that library even existed until I watched this video! Great info and thank you for the knowledge you bestow!
If you use pyupgrade or ruff, rule UP035 will warn you to use the proper import. There are other relevant typing rules too, such as UP006 (use list[T] instead of typing.List[T]) and UP007 (use X | Y instead typing.Union[X, Y]).
+1 for pyupgrade. It really helps with replacing older style type hints as well as doing other useful things.
I noticed something fishy with this some time ago but was too lazy to investigate. Thank you!
This is news to me! And I agree with you: typing is such a convenient module for, well, typing. :)
If you think of it from a Java dev perspective, it makes sense that all the ...able are moved to abc. If an object is ...able, this is a behavior, and it is not implemented in Java as a strict type. Java uses interfaces for that, which is a kind of abstraction.
So, moving ...able types to the "abstract base class" makes more sense than leaving them in "typing"
Finally somebody realizes it!
I was confused ever since 3.9 and wasn't able to find any information about typing and it becoming more and more obsolete. By now typing as a logically (in)complete module should be looked at as a messy result of overthought concepts of which language part should be responsible for type hints.
Wow, didn't know that! Thanks for the video!
Ever used the 'ruff' linter? It warns about many defacto deprecations like to use 'dict' instead of 'Dict' from the typing Module.
I haven't, but a few comments suggested it so I will try it
Oy. Single-letter package renames are disgusting. Stop it. It’s convenient for you at exactly one moment, when you’re writing it. It will be inconvenient for you and anyone else who ever has to read that dogshit, in perpetuity.
Stop it. Please.
honestly, i think they should deprecate the entire module. Make all its features baked in to the standard library types or even to the language syntax itself
As someone who enjoys functional programming, I am wary of the demo code you showed, because it makes the implicit assumption that you can print() the elements of the iterable, which in Haskell isn't a given. that is, in Haskell you would need to specify it as Iterable, and the elements as printable.
Thanks - I had missed that one as well.
Sounds like you want to make a PR for mypy...
Most of the type annotation tutorials I've found describe it using older versions of Python, and then I have to hunt for what has changed and how. They are also frequently incomplete because they only explain the new features (this is fine, just not what I need). Do any of you know where I would find a complete tutorial on the topic using 3.11 at least?
Imo just read the documentation.
I just used typing callable now I learnt this from this video.
Im using python every day since 12 years... This is just fresh news to me...
Noticed that too. It's a bit annoying.
Not gonna say it's pointless, but it feels like yet another "just use this to do this, don't ask" parts of python, which is hardly a desired approach if you want to make a beginners friendly language.
Perhaps, in the future we expect a TypePython language that forces typing, which will be the equivalent of TypeScript/JavaScript. :)
Please don't, the tools around TS are what made me quit learning it. Nothing seems to "just work", unless you use something like Vite or Deno.
But if you do that, you won't understand how TSC works. But if you try to figure out the TS tooling you'll run into insane error messages like:
"unknown file extension '.ts'"
When you try to use ts-node with ESM modules. 💀
SOP for all deprecations. Python is complicated, and it is hard to keep up with minutia like this. Thanks for pointing the deprecation out.
I agree, they should have made it better known. Removing the call to typing may affect existing code, not knowing when or if makes it difficult to judge how important it is to examine existing code to make changes. Hopefully they will make it more explicit if they chose to remove the call and give sufficient time for programmers to make adjutments.
When you run the code ALL typing is ignored anyway since it's not part of the runtime it's just there for the external type checkers to use. As far as python itself is concerned everything is just type ANY😉😂
I haven't really seen this question in any previous videos, but what code editor to you use?
The PEP considered adding deprecation warnings for this but decided against it as those warnings would have a negative impact on runtime performance.
Congrats on 200k!! You deserve it.
Maintaining an open-source language is such a tough job, make a decision wrong and it's very hard to undo, we can't satisfy everyone, just try to minimize the impact of inevitable changes.
I would be surprised if the typing module ever went away purely for backward compatibility reasons. Maybe with Python 4 but not 3.x.
Edit: the guidance that it is "deprecated" just means its not the official path but the code should still run until Python decides to break its API.
I miss a tutorial for the type checking. On the Python website I can find a Python tutorial, but nothing about type annotations. Can I define my own types? When are two types compatible?
If you read the mypy current documentation (1.11.2) then all of the examples happily use `from typing import Iterator, Iterable, ...`. I guess the mypy authors didn't get that memo either.
Can you create videos explaining all the python builtin modules? 1 video per module is also fine.
Typing was the right module name. I would continue using it
so everything that can be used from `typing` library can also be done with `collections.abc`? you just need to swap importing `typing` --> `collections.abc`? (for python 3.9+)
tuples, lists, dicts and sets are not in `collections.abc`, they should be just subscripted as is `list[str]` and a couple of other things are also renamed
it seems that collections abc are catching up to support type annotations by allowing subscripting. Thus these 'aliases' from typing library are no longer necessary.
using the from module import type method seems more maintainable than using import aliases in this case.
What happens with Any?
I guess because Python still remains a dynamically typed language this might have something to do with it? But I don't see why this has been moved to the collections package. Is there even any difference in functionality?
Me using 3.8 at my org, still strong with typing module.
I know 3.8 is reaching end of life though, it's good to be annoying migrating
I just use list[str] 😅
I see how it's easy to miss this! How did you notice in the end?
I just kept getting comments telling me that typing was deprecated and didn’t believe them until I checked.
but wait, if I can still use t.Iterable, what does deprecated even mean? why should I stop using it?
Deprecated things are removed in the future versions
I’m only finding this out from your video lmao
I never understood why you'd have to import a module for getting typing in the first place.
‘typing’ now ‘collections.abc’ just creates a bunch of classes that aren’t built into python. You can use type annotations without either.
How do you replace `typing.TypedDict`?
Nice video, didn't know that
I think you're just a month or so early about this, once Python 3.8 is EOL this october, type checkers should start complaining about it as minimum Python version everywhere becomes 3.9
I will definitely make an update video on that if that's the case
every single popular interpreted language evolves to have a type system
It's especially weird because Python is all about explicit is better than implicit. 😅
I'm probably sticking with the Typing module until these types don't need an import at all
Time to learn Rust.
Makes me wonder if using "external" libraries are worth the risk of the additional dependency. Writing your own libraries has two benefits: first, it can't be depricated on you; and second, it can be as lean as you want. You can't control the bloat of external libraries.
What do you mean external library? Typing is in the standard library that comes with python.
@@kc12394 Makes no difference to me if they are "out-of-the-box" Python or not. Any library you import that you didn't write exposes you to an external dependency; which is a future risk.
@@mikesmith6838yeah next thing you know there will be a new version of python and it'll change something in the language and make me change my code. Guess I better just write my own language instead🤔🙄🤦♂️
@@mikesmith6838i am pretty much agreeing with you, except that if everyone publish their own version of basic libraries in each project, first you have to "reinvent the wheel" everytime and second PyPI will quickly explode from data overloading
@@mikesmith6838 This is pretty backwards. Makes sense if it's a thing or two here and there but are you going to rewrite your own IO library, TCP server, multithreading library in python every single time just to avoid it being deprecated in the future? By your logic the only way forward is to create your own language, since languages also get deprecated too, look at python 2.
Well why don't you use pydantic... if I am not wrong, it will handle everything much more elegantly.
Great change. Never understood why there is distinct list and typing.List and etc. It’s a big skill issue that static typers dont mention about deprication and python devs decided not to do this either.
How have you got a responsive mypy popup in pycharm? 😍
If you check the plugin store it's there!
I think is something is working well why change it...🤨
First time since I heard about it, since I am learning python lool.. But in my opinion, it is just unnecessary change to go from one module to another which provides identical functionality
An i18n name collision in Oxford dictionary with "typing"? And a half-hearted attempt to use a mechanism to use "collection"?
I am really tired of using shitty things that then deprecates. Just stuck to vanilla.
They should never be removed and even should be un-deprecated. Why? Because List[T] looks like a real class. For context - they also deprecated typing.List, .Dict, and other when they changed typing in the last releases
Ok, if I could get slice of a pizza you have made, this would not upset me as much 😊
Nice, so I don't even have to type in python anymore? is this some new fancy auto programming AI?
In the end, the typing module, along with type annotations, is just a tool to give linters and type-checkers more information about the code. Deprecated or not, the interpreter will just ignore annotations at runtime. The code will keep the same behavior.
Well it makes a huge difference if it's deprecated and then removed, because then linters might not recognise it anymore eventually, and Python might give you an ImportError if they remove it.
"You cannot use A, you must use B instead", where A in fact is an alias to B. Seems legit.
for a moment i thought you meant the whole keyboard thing, how you would enter python code
I use voice to text usually
Python’s getting as bad as M$ with the, _”We know better than you. So too bad!”_ attitude.
Implicit language, implicit change.. you wouldn't
It’s because they keep axing all the white developers from the Python org
Shouldn't have been done silently like that. 😠
I dont like this typing : (
Well, mypy is kinda shitty then. Use another thing. Lol. It's mypy's fault.
🎉😂
So you were happy and productive before learning of the type deprecation. Perhaps ignorance really is bliss. Similar to the James Webb Space Telescope, a great engineering achievement that "deprecated" many commonly believed astronomical theories.
Anyone thinking about cohabitation?
That's a no bueno to me
if you think you need to annotate types in python, then something is wrong
This just means yet another reason to pin your code to a specific range of Python versions. I don't think I have ever encountered a programming language that didn't require pinning to a specific version.
That seems like a relatively new language feature - for example, is C pinned to a specific version?
python is an abomination
python annotations are not forcing python developer to check the data types, other languages like typescript is much better than python in dealing with types.
Typescript has less type safety than python.
Do you realize it is done on purpose, so you have more flexible language? Tyle hints/ annotations is just a bad feature, but so many people love it for some reason
@@rafapedziwiatr2386 type safety is important for maintainability
second
🥈
🏳️🌈🏳️🌈🏳️🌈
mindblowing
Easy solution, don't use type hints and let Python still be Python.
No... Just no. Type hint is incredibly important even if you are not shipping a library. It's so easy to just put your cursor on a function and see the argument types and attributes the function or class expects.
If you didn't notice since v3. 9, it means you never use it. Which validates their decision.
hey man, you're talking to an obsessive typer, i can bet by this comment you have not watched many of his videos