Oh, that's actually another common misconception with terminology. Python IS a strongly typed language. People tend to mix two separate ways of classification, which are Strong/weak vs static dynamic. Python has a strong dynamic typing.
@@mattizzle81 a great way to import "dummy" modules just for type hinting is to do the following: from typing import TYPE_CHECKING if TYPE_CHECKING: from dummy.module import DummyType now it will only import "DummyType" when intellisense is type checking.
Personally I only use type hints in function definitions because it helps with documentation. Not having to do that for every variable is like half the reason I’m using python in the first place 😅
Most of the times good IDEs can infer what a variable is supposed to contain. So I agree But some hairy functions with complex innards, I'd sparingly add some type annotations to maintain my sanity
One thing that I do since type hints are ment to improve readability and IDE workflow is only using them if the type is not explicit, either for the user or the IDE, like return types after calling a function. This means that, for me, creating variables using the primitive data types or using the class constructor don't really need type hinting because it's obvious. For example: banana = Fruit() In this case, both the IDE and the user know that banana is a Fruit, so adding annotations wouldn't do anything or make your code just more verbose. That's my opinion though, what you guys think about it?
I think it’s a respectable view on it. And I think most people will probably also disagree with my: banana: Fruit = Fruit() But that’s now a huge habit of mine. Even if it looks redundant, I enjoy having it because it feels even extra explicit in my mind. I think what you said makes sense though!
And it's a good habit to have for when you have to learn\switch to strongly typed language. Learning something like TypeScript or Dart is so much easier if you practice sound typing in Python.
@@Indently Well, map() function in both JS & Python is my instance problem, even though it should be so simple, I just need to convert a huge list with 3 to 4 levels deep nested lists, only need a list from only one element. Also, please don't forget about the banana, he is our favorite friend 🍌
I sometimes wish there was a strict python debug mode that automatically asserted that your objects in fact conformed to your type hints at runtime. In my opinion, debugging python code in larger projects can be hard at times.
Look at mypy if that's what you are looking for. I would say though that enforcing restrictions on everything is not very useful and could easily limit your options and make your code worse, since it takes a lot of effort to annotate everything correctly, maintain that and not put unnecessary restrictions that prevents you from reusing your code. Personally I tend to annotate public interfaces as much as it looks reasonable, but not internals. I found that if your code is structured well enough, you normally should be able to comprehend what's going on in short functions without spending time on maintaining type hints for them. Also keep in mind that linters could use not just explicit annotations, but could also infer possible type from the code itself. So if you write something like. x = 1 if cond else "1", then linter after consuming this line would infer that x could be an int or a str and use this information later.
All developers that have been writing dynamic code for years have been snorting that copium, Python couldn't last too long without type hints, proving once again that dynamic programming is not to be worshipped. It's nice to have every now and then, but definitely not for full systems, without any sort of type information. Same reason why we also got TS on top of JS
Thanks for the video! In my case, I am using type annotations super often (at least in all function definitions) + mark type hint warning as error in the IDE ; it saved a terrific number of hours (not to mention forcing myself to improve my interfaces).
2:30 this will cause an error in python 3.8, and not just for typings, it will break the whole code, and the fix is: from typing import List and use it with capital L. Same with Dict and Tuple. Backwards compatibility makes life easier for people with low storage space / slow internet speed that already have dependencies installed with a lower python version.
I currently write in what I call "Python 2+" ... working on a system with both py2 and py3, I write in such a way, the code will work in either. (2.7 and 3.11)
I also like those typehints, and I think you missed that they're helping also for overloading functions if I'm correct. Coming from C++ , I appreciate types anyway 😉
@@Indently Not exactly. Overload is possible via functools.singledispatch decorator and it uses typehints to distinguish, which implementation to call. Typehints are not enforced in any way by language itself (unless you use something like mypy instead of regular cpython to run scripts, but that's a different story). However nothing prevents your code from reading function annotations and do some magic around them. That's exactly what singledispatch does, so it's rather a syntax sugar than a feature of language itself.
3:11 Guido has hinted that there are no current plans to use type hints to speed up the interpreter, but that it’s something they’re going to look into down the road (5, 10 years time). So it’s not crazy to think that the hint could speed up the code when it’s running one day
Ahahaha the bleep, lol 😂 I love type hinting. It makes IDEs much more useful. And also makes me more disciplined in writing my code. Next video suggestion if you haven't: The amazing power of "for unpacking" 😎
Worth mentioning that I've found type hinting plays very nicely with tools such as GitHub Copilot. This massively speeds up development. I do wonder if cPython or pypy interpreters, for example, have any optimisations, or might get some in the future, where type hints improve JIT compilation speeds.
Thank you for this video. I've seen these type hints in various videos, and wasn't sure what's the purpose, since in my tests (by copying things in vids) ... it seems to have no effect. And since I've been writing code in vi for 40+ years, these type hints don't seem to have any benefit to me. BUT, I _DO_ believe in good commenting, good variable names, and using plenty of """ Very explanatory doc strings with examples including Use Cases """ so I hope programmers that follow me, will not be mad at me.
Do people out there actually think that type annotations "speed up" your code? Seems like you'd actively have to avoid reading any documentation to have this misconception.
3:17 "...no type checking is occurring at run time." That doesn't sound right. Python always does type checking at run time, and type hints doesn't change that (because Python ignores them). That's one of the reasons Python is slow. On the other hand, in languages like Go and Rust, BECAUSE the type checking happens at compile time, there is no need for it at run time.
Even though vim does not give me any warning if I'm assigning values against the type hints, I find it very useful and handy when I'm tracing some code.
Ah, it doesn't do what PHP 8 does, yet. It doesn't care about the type hints at compile time. PHP does generate more efficient bytecode when you use type annotations, and does do type checking - it's still opt-in, but it's now standard usage.
@@Indently No worries. I figured as much. I don't know much more than what I shared about PHP bytecode generation anyway. I figure Python will get there too at some point.
That's the return type (the type of the value returned from the function). If you don't specify it, it would mean that your function returns None (or anything else really, as Indently said, type hints in Python are completely optional and not checked by cpython at all). If you mean why does his -> look like a real arrow, that's probably down to his IDE configuration, or eventually the font he's using (some specialized fonts use ligatures to make common code combination like -> or
Please at least use them as arguments and return values... I do not use it in cases like variable declaration when the value assigned is static and easily resolved by the Python's LSP server.
I like to think of Python as a free language. It lets you do what you want, even if what you want isn't always what you want ahah. They shouldn't require it in vanilla Python, but possibly provide us an option for enabling that, such as a special import, or with a special version of Python that replicates TypeScript.
Idently: Python is meant for simplicity, if you want something else just use a lower level language also Idently: uses typing that low level need to work anyway me: *confused thinking*
Typing does not determine the level of your language though. You have very high level languages that are typed (try Haskell) and you can do most low level stuff in any language (try embedded programming in Python, it sure is higher level than in C but you'll often find yourself sending binary codes to explicit pins on the board and so on) though that is not recommended for speed and memory control. Dynamic typing (types are attached to values, variables and functions don't have specific types, all typing is done at runtime) vs Static typing (variables and functions have specific types, which are decided at "compile" time) is more a matter of practical implementation and philosophy around programming. Note that some developers think they dislike static typing but they in fact lack experience with modern languages and confuse static typing with explicit typing (every variable/function type has to be explicitly written when they're declared) whereas almost all modern typed language can infer most types without specifying them in your code (even if the recommendation is generally to put type annotations at least on your top-level declarations, to get better error messages). Type inference is such a win that most traditional languages have been retrofitted with it in the last decade.
For those of us coming from strongly typed languages, type hinting is a nice little security blanket.
Oh, that's actually another common misconception with terminology. Python IS a strongly typed language. People tend to mix two separate ways of classification, which are Strong/weak vs static dynamic. Python has a strong dynamic typing.
@@evlezzz Oh interesting. So what the commenter ment is more the Static Typing part?
I mostly care about intellisense. Sometimes I even create “dummy” modules to import just with type information to allow intellisense to work.
@@mattizzle81 a great way to import "dummy" modules just for type hinting is to do the following:
from typing import TYPE_CHECKING
if TYPE_CHECKING:
from dummy.module import DummyType
now it will only import "DummyType" when intellisense is type checking.
this can also help prevent import cycle errors
Personally I only use type hints in function definitions because it helps with documentation. Not having to do that for every variable is like half the reason I’m using python in the first place 😅
Most of the times good IDEs can infer what a variable is supposed to contain. So I agree
But some hairy functions with complex innards, I'd sparingly add some type annotations to maintain my sanity
True. Python is like a beach that topless is allowed. Some people just don’t feel secure without it.
It really helps with auto-completion when dealing with custom modules and classes. I have been leaning heavily on this of late.
One thing that I do since type hints are ment to improve readability and IDE workflow is only using them if the type is not explicit, either for the user or the IDE, like return types after calling a function. This means that, for me, creating variables using the primitive data types or using the class constructor don't really need type hinting because it's obvious.
For example:
banana = Fruit()
In this case, both the IDE and the user know that banana is a Fruit, so adding annotations wouldn't do anything or make your code just more verbose.
That's my opinion though, what you guys think about it?
I think it’s a respectable view on it. And I think most people will probably also disagree with my:
banana: Fruit = Fruit()
But that’s now a huge habit of mine. Even if it looks redundant, I enjoy having it because it feels even extra explicit in my mind.
I think what you said makes sense though!
the problem is when you reuse a variable, without knowing. the changed type can give you a warning
Even in C++ I'd write "auto banana = Fruit()" in that case and not write the type name twice.
And it's a good habit to have for when you have to learn\switch to strongly typed language. Learning something like TypeScript or Dart is so much easier if you practice sound typing in Python.
Your voice is sooooo relaxing man, love to hear you teach forever, please give some advanced topics as well, not all of us are beginners
I will get to them next year, any recommendations for topics you'd like to see?
@@Indently Well, map() function in both JS & Python is my instance problem, even though it should be so simple, I just need to convert a huge list with 3 to 4 levels deep nested lists, only need a list from only one element.
Also, please don't forget about the banana, he is our favorite friend 🍌
I will keep it in mind! I never forget about banana 😉
I sometimes wish there was a strict python debug mode that automatically asserted that your objects in fact conformed to your type hints at runtime. In my opinion, debugging python code in larger projects can be hard at times.
Try a static type checker like mypy
It's not quite what you're talking about, but check out pydantic. It allows you to create data models and allows some type enforcement.
Look at mypy if that's what you are looking for. I would say though that enforcing restrictions on everything is not very useful and could easily limit your options and make your code worse, since it takes a lot of effort to annotate everything correctly, maintain that and not put unnecessary restrictions that prevents you from reusing your code.
Personally I tend to annotate public interfaces as much as it looks reasonable, but not internals. I found that if your code is structured well enough, you normally should be able to comprehend what's going on in short functions without spending time on maintaining type hints for them.
Also keep in mind that linters could use not just explicit annotations, but could also infer possible type from the code itself. So if you write something like. x = 1 if cond else "1", then linter after consuming this line would infer that x could be an int or a str and use this information later.
should try pyre-checker
All developers that have been writing dynamic code for years have been snorting that copium, Python couldn't last too long without type hints, proving once again that dynamic programming is not to be worshipped. It's nice to have every now and then, but definitely not for full systems, without any sort of type information. Same reason why we also got TS on top of JS
Thanks for the video! In my case, I am using type annotations super often (at least in all function definitions) + mark type hint warning as error in the IDE ; it saved a terrific number of hours (not to mention forcing myself to improve my interfaces).
I like using type hints and return type in function definition. It makes reading the code , writing documentation and debugging easier.
Type hints are wonderful for documentation, absolutely love this.
2:30 this will cause an error in python 3.8, and not just for typings, it will break the whole code, and the fix is: from typing import List and use it with capital L. Same with Dict and Tuple. Backwards compatibility makes life easier for people with low storage space / slow internet speed that already have dependencies installed with a lower python version.
I currently write in what I call "Python 2+" ... working on a system with both py2 and py3, I write in such a way, the code will work in either. (2.7 and 3.11)
@@josephgaviotabut that's just... old python lol
@@gerardonavarro3400 Yes, but one has to work with what one has.
It's also great adapting this habit if you are learning non-dynamic programming languages!
had a good laugh at your int initialiser reaction :D:D
I also like those typehints, and I think you missed that they're helping also for overloading functions if I'm correct.
Coming from C++ , I appreciate types anyway 😉
Python doesn’t support overloading as far as I remember
@@Indently Not exactly. Overload is possible via functools.singledispatch decorator and it uses typehints to distinguish, which implementation to call. Typehints are not enforced in any way by language itself (unless you use something like mypy instead of regular cpython to run scripts, but that's a different story). However nothing prevents your code from reading function annotations and do some magic around them. That's exactly what singledispatch does, so it's rather a syntax sugar than a feature of language itself.
3:11 Guido has hinted that there are no current plans to use type hints to speed up the interpreter, but that it’s something they’re going to look into down the road (5, 10 years time). So it’s not crazy to think that the hint could speed up the code when it’s running one day
Typython
Ahahaha the bleep, lol 😂
I love type hinting. It makes IDEs much more useful. And also makes me more disciplined in writing my code.
Next video suggestion if you haven't: The amazing power of "for unpacking" 😎
Thanks for the suggestion!
Great video, truly loved it! More on the subject would be nice!
Very interesting. Almost as interesting as Copenhagen, where I was over the weekend. Thank you. ☺
Worth mentioning that I've found type hinting plays very nicely with tools such as GitHub Copilot. This massively speeds up development.
I do wonder if cPython or pypy interpreters, for example, have any optimisations, or might get some in the future, where type hints improve JIT compilation speeds.
The "typing" module includes broader and slightly better options for "typehints".
Thank you for this video. I've seen these type hints in various videos, and wasn't sure what's the purpose, since in my tests (by copying things in vids) ... it seems to have no effect.
And since I've been writing code in vi for 40+ years, these type hints don't seem to have any benefit to me.
BUT, I _DO_ believe in good commenting, good variable names, and using plenty of
"""
Very explanatory doc strings
with examples including Use Cases
"""
so I hope programmers that follow me, will not be mad at me.
I think one instance where it does check the hints is when cythonizing to produce .pyd files.
I hope the type hints will be used to facilitate the just-in-time compilation. It looks so reasonable.
At 2:42 why was there a pi and beta when you tried to write list[str] is that a option i can turn on
That's me miss-typing on my keyboard actually ahahaha
@@Indently i also keep typing greek everywhere by accident. my keyboard layout switching shortcut is a bit too convenient.
@@chri-k European keyboards are a pain for coding ahahah.
Do people out there actually think that type annotations "speed up" your code? Seems like you'd actively have to avoid reading any documentation to have this misconception.
If you every used a language that is statically typed before, it's very easy to make this mistake in Python if you're new to it.
I thought that
3:17 "...no type checking is occurring at run time." That doesn't sound right. Python always does type checking at run time, and type hints doesn't change that (because Python ignores them). That's one of the reasons Python is slow. On the other hand, in languages like Go and Rust, BECAUSE the type checking happens at compile time, there is no need for it at run time.
Even though vim does not give me any warning if I'm assigning values against the type hints, I find it very useful and handy when I'm tracing some code.
Nice I would have just used ChatGPT! I've been learning that way. I share the stuff I build too.
Good on you mate.
Thanks! Maybe a n00b question, can you also specify the parameter and return type to be e.g. a dataframe?
sure, you can
thanks bro for your clarification'👍👍 ,btw what is your favorite IDE for python programming?
I love PyCharm
Mypy has a compiler that should speed-up your code. I believe that type-hints are required.
Did you worked with mypyc?
With type hints, you help intellisense help you better :D
yep
You made my day. Thanks 🙏
I don't know what is the use of dynamically typed
can you make a video about the docstring, sir?
Love your stuff!
Grazie bello :)
Ah, it doesn't do what PHP 8 does, yet. It doesn't care about the type hints at compile time. PHP does generate more efficient bytecode when you use type annotations, and does do type checking - it's still opt-in, but it's now standard usage.
Do you mean PEP? Or is there something with PHP that I’m missing?
@@Indently PHP, the programming language, competitor to Python on the web, but not so much on data crunching
Excuse my ignorance, I'm not really familiar with PHP so I thought you meant PEP ahah.
@@Indently No worries. I figured as much. I don't know much more than what I shared about PHP bytecode generation anyway. I figure Python will get there too at some point.
Type hints does speed things up if you Cythonize the class
Type hints actually can speed up your code, but you have to compile it with mypyc.
Does this only work in PyCharm or can this work in something like VS Code?
It's part of Python, you can do it everywhere
Is it possible to tell the compiler to consider these type definitions?
There is no compiler in python, it has an interpreter.
In Future releases of python this will be used in runtime. so, it is good practice
Do you know where I can find the docs for this?
Guido, Python creator, and other maintainers have said there are no plans for this as it goes against pythons core values.
That's what I thought as well, but maybe Aman has some article that we don't know about that he is willing to share with us.
@@Indently have you heard Guido on the lex Fridman podcast? If not, highly recommend. He was on twice, the most recent one was stellar.
Thanks for the recommendation! I've never heard of it no, I will check it out though.
You can also run typecheckers
What some people think type hinting does, JIT tracing actually will do.
Explicit is better than implicit - Zen of python
ok, but what is that "->" ???
That's the return type (the type of the value returned from the function). If you don't specify it, it would mean that your function returns None (or anything else really, as Indently said, type hints in Python are completely optional and not checked by cpython at all).
If you mean why does his -> look like a real arrow, that's probably down to his IDE configuration, or eventually the font he's using (some specialized fonts use ligatures to make common code combination like -> or
Dang... I was hoping for it to optimize the performance.
Apparently it can if you look into some called "mypyc"
@Indently Thank you, I will definitely look into that right away.
Please at least use them as arguments and return values...
I do not use it in cases like variable declaration when the value assigned is static and easily resolved by the Python's LSP server.
I thought it was just to make source code bigger
type hints must absolutely throw an exception if you mismatch types. let's go towards static typing, dynamic is an old tradition guys.
I like to think of Python as a free language. It lets you do what you want, even if what you want isn't always what you want ahah. They shouldn't require it in vanilla Python, but possibly provide us an option for enabling that, such as a special import, or with a special version of Python that replicates TypeScript.
@@Indently type #@type=static... something like that.
That would be neat!
Idently: Python is meant for simplicity, if you want something else just use a lower level language
also Idently: uses typing that low level need to work anyway
me: *confused thinking*
I can't believe you called me Idently, twice, Simon 😅
@@Indently hahahahaha didn't even notice
Typing does not determine the level of your language though. You have very high level languages that are typed (try Haskell) and you can do most low level stuff in any language (try embedded programming in Python, it sure is higher level than in C but you'll often find yourself sending binary codes to explicit pins on the board and so on) though that is not recommended for speed and memory control.
Dynamic typing (types are attached to values, variables and functions don't have specific types, all typing is done at runtime) vs Static typing (variables and functions have specific types, which are decided at "compile" time) is more a matter of practical implementation and philosophy around programming.
Note that some developers think they dislike static typing but they in fact lack experience with modern languages and confuse static typing with explicit typing (every variable/function type has to be explicitly written when they're declared) whereas almost all modern typed language can infer most types without specifying them in your code (even if the recommendation is generally to put type annotations at least on your top-level declarations, to get better error messages). Type inference is such a win that most traditional languages have been retrofitted with it in the last decade.
__int__ lol haha