How to use: "Never" & "NoReturn" in Python (Tutorial)

In Python we have 2 type annotations that are incredibly similar. In fact, they are so similar that they are the same thing actually with different names. Let's learn how we can use Never & NoReturn in Python!
Learn more about "NoReturn" & "Never" here:
typing.readthedocs.io/en/late...
▶ Become job-ready with Python:
www.indently.io
▶ Follow me on Instagram:
/ indentlyreels
00:00 Learning Python made simple
00:05 Intro
00:36 Where to use Never/NoReturn In Python
01:31 Using Never
01:48 Using NoReturn
02:03 Another way to use Never
04:05 So… what did that do?
06:23 Summing it all up
06:50 What are your thoughts?

[@Indently]

Hey guys, one of you were nice enough to point out that I mixed up which one was new. It turns out that "Never" was introduced in Python 3.11, and "NoReturn" came before. They both do the exact same thing and can be used interchangeably, so the information I taught you in the video would still be the same, I just mixed up the versions. Sorry about that!

[@MechMK1]

I really like when languages have explicit types for "This should never happen"

[@glitchedpixelscriticaldamage]

use another programming language then, C or C++ should be your primary choices.

[@DrDeuteron]

@@glitchedpixelscriticaldamage get that C stuff OUT-A-HERE. take it to usenet. this is for pythoneers, pythonistas, and pystros.

[@DrDeuteron]

assert

[@gaby1491]

Neat little trick to get more people working together on a bigger project without breaking things thank you

[@backfire10z29]

Geez, it seems like the people in this comment section either don’t know Python, have never programmed anything larger than a todo list, or are being intentionally dense. Nice video.

[@swolekhine]

Thanks for this! I didn't know about Never and NoReturn.

[@jjpaq]

"I don't know what it means, but that's what it's going to be." ~me, after finally getting TypeScript to accept some combination of quotation marks, parentheses, interfaces, and curly brackets.

[@FolkOverplay]

OMG! I love the example with if-statement! 🤯 I have always written Else: raise RuntimeError as a guard but this is really neet!

[@gesuchter]

Great video:) i haven't heard about these type hints yet and will definitely use them in the future! I am a huge fan if mypy.

[@utarasama]

Nice video! I didn't now about typing before discovering your channel, thanks!

[@Indently]

Welcome to the typing club, my friend :)

[@anshusarkar7113]

​@@Indently So you used if __mian__=='__main__': to prevent execution of another main() function isn't it ? If not pls correct me.... Pls

[@thomasturner1065]

if __name__ == "__main__: basically says "run this code if the file is being executed (and NOT imported)." If you don't have it, importing your .py file will execute all of the code in the body of the file, which often you don't want.

[@mahmoudshihab]

I love this!!! I need to do this more often!!!

[@JakobWierzbowski]

Awesome content. Thank you. Knowing what you do is good, typing (control) is better 🤣

[@martin_460]

This was an excellent explanation and great example when to use this. Thank you!

[@davidlloyd1526]

That's a very complicated way of implementing an unreachable(); statement. Are there better uses for these types?

[@tthaz]

really good tip!

[@murphygreen8484]

Why so much hate? I think this was a great video!

[@Indently]

Don't worry, it looks like a lot of hate because people that have strong opinions AGAINST static type checking in Python tend to let loose in the comments section. The video is actually performing very positively, and I'm sure that the people who enjoy the benefits of static type checking appreciate it :) Thank you though!

[@staryibashmak8212]

Where is that?

[@ricgondo]

Wow, this was nice! Thanks!

[@Indently]

Thank you :)

[@briansalkas349]

Never is amazing. I miss features like the rust case statement that warns when you forgot to add a case, this is the next best thing but for python

[@AngelHdzMultimedia]

Thank you so much for the MyPy Type Checker extension info! I was using types but without checking, I was blinddd! 😂🔥👀🤯

[@amortalbeing]

thanks good stuff

[@aaronsteers]

Really helpful video! I create a bunch of SDKs in Python and I learned something new here. There's another use case which I'd love to see a video on - which is using type checking and using Never/NoReturn to detect if a subclass is implemented, in order to implement backup functionality when available. For instance, I can let users of my SDK overwrite a specific method, which in the base class returns NoReturn and raises NotImplemented. Then, rather than having them give be a Boolean flag to say "supports_feature_x", I can in the base class simply check the return type of the method, presumably. If the return type is not NoReturn, then I can assume it's implemented and safe to call Would this work? Would love to see a video on it if so. Thanks!

[@Gwalchaved86]

What if the method implemented by user function also returns NoReturn?

[@DrDeuteron]

the method should return NotImplemented until it is implemented, and that can be really useful with reflected operator overloads in algebras in which left and right operations are very different,

[@sfermigier]

I tend to prefer the match statement to a list of ifs, when it's possible to use it.

[@TheFeriner]

hmm I feel like match statements are more sensible as mentioned in the video, and switching to use if elses just kinda makes it more confusing i’m still kinda struggling to see a non-convoluted use for never but i’m sure there is one

[@V0W4N]

is it made like an error raise on edge cases but for compilers? wouldnt putting a raise by itself in the unreachable code part be enough or compiler would just ignore it?

[@philipvandenakker7885]

Using just a raise would work to stop the program at runtime but the NoReturn type makes it get flaged by the mypy type checker. This would notify the programmer to check the code to fix the problem before it can become a problem

[@vytah]

Raising an exception is a completely normal thing to do in a program, programs reach exceptions all the time. What was important in this example was using the type system to check that the set of possible values of a variable is empty (and Never is the empty type). Since {2}⊈∅, mypy complains.

[@nigh_anxiety]

Besides the benefit of MyPy catching the issues by using the function, that function might also include some additional calls to logging or clean-up operations before it raises the error.

[@mohamedsajjadh8340]

Hey quick question. Are you still using the M1 that you reviewed a year back? any counter opinion on what you mentioned in the video?

[@Indently]

I'm still using it. My only regret is that I wish the screen was bigger sometimes when I'm travelling. But it runs super nicely still!

[@mohamedsajjadh8340]

@@Indently cool thanks man for the reply. I was kinder worried if i should go for 16GB, because that’s little costly. It’s for my personal use, coding, studies. Have a pc for other heavy stuff.

[@nico32433]

@@mohamedsajjadh8340 I personally don't think that you will need it if you do not have really RAM expensive applications like video editing big files. In my experience, macOS generally needs less RAM than Windows and my 8GB MB Air never had any issues with RAM

[@mohamedsajjadh8340]

I too hope, but not sure what the future holds :D :D @@nico32433

[@rondamon4408]

Sehr cool!!

[@doresearchstopwhining]

I always put my own version of `assert_never` but it didn't have any of this fancy stuff so I never got good static type checking. This is way better thank you!

[@lumipakkanen3510]

By the way, typescript implements the latter functionality with "state satisfies never" which is more understandable than a custom function call in my opinion.

[@vikingthedude]

<a href="#" class="seekto" data-time="345">5:45</a> we do the same thing in typescript, except we usually don’t create a function for the assertion, we just write a statement such as “should_never: Never = state”. Would this alone be enough for mypy (ie no need to throw assertion error)

[@johng6235]

Better state satisfies never

[@DuncanBooth]

The satisfies keyword was only added to typescript near the end of 2022 and before that it was common to write an equivalent to asserts_never(), or at least it was for me when writing typescript. Python's use of 'never' is a few years behind typescript so perhaps we'll get satisfies as well some year.

[@xsamueljr]

What if the function raises an exception sometimes? Like a guard clause

[@herogpi1]

The function annotation should be the usual (non-error) case. If it raises an error, it's responsibility of the upper scope to catch the error

[@xsamueljr]

​@@herogpi1 Then I should still use just `None`? Since that's exactly what it returns when everything is ok. Or should I use `None | NoReturn`? (Bad English, I hope my answer makes sense)

[@vytah]

The return type specifies what values the function may return if it returns normally. The type can be though as a set of values, and Never/NoReturn is just an empty type (and therefore X|NoReturn = X).

[@herogpi1]

​@@xsamueljr I think you shouldn't use 'None | NoReturn', only 'None'. From what I see in some libraries, they don't explicit say all the errors it can raise. As example, search for 'numpy.eye' function on google : It expects an integer as argument, but it doesn't say what will happen if I pass a string. From my experience, I expect to receive an 'ValueError' or 'TypeError', although it's not explicit in the documentation.

[@barneylaurance1865]

@@xsamueljr You can just use None. `None | NoReturn` is exactly equivalent to `None`, because NoReturn is a subtype of None. In fact NoReturn is the "bottom type", which means it is a subtype of every other type.

[@Dalmen]

Limbo is between 0 and 1, like the limbo dance.

[@sharpfang]

Should I also add noReturn if I intend to stay in the function forever, in an infinite loop?

[@insertcreativenamehere492]

sure, but why would you want that?

[@haihonghuang]

​Maybe a service, expected to keep running till losing power?​@@insertcreativenamehere492

[@sharpfang]

@@insertcreativenamehere492 Embedded, you exit the program by switching power off.

[@TotalTimoTime]

A main() function might very well look like: def main(): while True: do_the_thing()

[@vytah]

You can, but it's not necessary. Fun fact: in Rust, infinite loops have the type !, which is Rust equivalent of Never/NoReturn.

[@MarcioBrenerCosta]

Awesome. Congrats 🎉

[@PythBuster]

Just wow :D

[@martink.2836]

'Never' is the newer one in Python 3.11, and 'NoReturn' was already present before (see Python docs). The docs also recommend to use 'Never', though I would agree that 'NoReturn' is the more natural read for return types.

[@Indently]

Oh my god, I absolutely switched those two around. Thank you for pointing it out. This sentence: "New in version 3.11: On older Python versions, NoReturn may be used to express the same concept. Never was added to make the intended meaning more explicit." absolutely twisted my mind it seems. I imagine I read it as "New in version 3.11: NoReturn may be used to express the same concept."

[@aliwelchoo]

Seems helpful. I'd raise NotImplementedError rather than AssertionError but otherwise good to know

[@nigh_anxiety]

According to the Python Docs, NotImplementedError is intended to be used by abstract methods of a base class that require derived classes to override the method.

[@aliwelchoo]

@nigh_anxiety that makes sense. Thanks for the reminder

[@Heavy_Lvy]

how do i like a video multiple times

[@AsgerJon]

import sys if sys.version_info.minor < 11: from typing import NoReturn as Never else: from typing import Never

[@Ma_X64]

"Never" is semantically wrong. Because by default our after_arrow block answers the question WHAT would this function return. So "Never" may be considered as some time-type or something. So explicit NoReturn breaks that question logic but it's obvious, explicit.

[@billyyank2198]

The next Python update will include the statement "WhenHellFreezesOver".

[@cayendar]

The docs are kind of confusing sometimes (c) I wonder, why there is no link to the documentation topic the video is based on. For those who are interested to see the original, it's easy googlable by 'Unreachable Code and Exhaustiveness Checking'. Surprisingly it has less words but more information.

[@Indently]

While this comment sounds like a conspiracy theory, it does make a valid point that it would be good to include the link. I have updated the description :)

[@cayendar]

@@Indently Thank you :)

[@helnoisemaker]

But... match case has O(1) time complexity, doesn't it? That's why you should always use match case if possible. Am I wrong? Not very familiar with Python. But time complexity is the main point to use match/switch etc. in every language.

[@loic.bertrand]

Great video! However, Python now has two types to do the same thing ^^ TypeScript has the "never" type, Kotlin the "Nothing" type, I don't see how this terminology is confusing. I'm afraid people will have endless debates on which one of Never or NoReturn they should use ^^

[@AnthonyBerlin]

Nah. Just follow the newest PEP standard for the version of Python you are using. No need to complicate anything and argue about stuff for no reason imo.

[@redpepper74]

Wait in Kotlin, is Nothing the same as void, or does it mean the execution never exits the function at all?

[@mathewrtaylor]

So let's say I have a add function that all it does is sum two numbers and print the result. Since it's not returning the value and just printing, this is the use case for NoReturn and Never?

[@Indently]

If your function doesn't specify a return, then it returns None by default.

[@redpepper74]

If the program execution never exits the function, then it’s NoReturn. If it does exit but just returns nothing, it’s None. (Returning nothing is different than not returning at all.)

[@Jamiered18]

Same as Typescript then

[@williammcenaney1331]

I've heard that Python programs run about 100 times slower than native code does. So I would think static typing would speed them up. In a functional programming language like OCaml, typing is always static. That's partly why I traded procedural and object oriented languages for functional ones. What would our teacher think of this code fragment? def is_integer(what): return type(what) = type(0) def count_integers_in(list): return len(filter(is_integer, list)) I write functions like those two because they're clearly correct ones without explicit loops.

[@herrpez]

Python is slow to run. Type checking primarily adds dev comfort and subsequent speed improvements. Respectfully, if you are at the "I've heard that" stage, I strongly doubt that Python's speed (or lack thereof) is even remotely a concern for you. Do what you need to do. Learn stuff. Find out when, if ever, performance becomes a concern of yours. Overcome it then. Don't get me wrong, branching out and learning more stuff is rarely a bad idea. The bad idea here is simply that you are focusing on something that may never be an issue for you. Hope that makes sense!

[@williammcenaney1331]

@@herrpez Python is excellent partly because it's ultra-high level and easy to read. That makes me admire Mr. Von Possum for the fine language he invented. But Python's evident slowness still matters to me because I sometimes programmed in that language. I now write in functional languages instead for many reasons. There are ways to prove that functional programs are correct. They're more concise than procedural programming languages and object-oriented ones. Functional languages also eliminate classes of bugs that procedural and object oriented languages can "catch." Functional languages excel at parallelism, too. Year ago, I programmed professionally and taught programming. But today computer science still interests me because I prefer theory to practice. For me, programming and compiler writing are mere hobbies. So no one in any industry will run any program I write.

[@herrpez]

@@williammcenaney1331 Ah, upon initial reading your post came across to me as speculation from a curious learner. But if you already know these things, there's hardly any point in me telling you to go learn things and figure out if limitations affect you in practice... you know that already! 😂

[@williammcenaney1331]

@@herrpez The slowness my already be a problem for me if I use Python again. Meanwhile, that slowness is easy to see when I watch a video when a computer takes more than a second to print about 10 two-digit numbers. During that video, the teacher explained how Cython can speed up a Python program any why programmers should use Python's inbuilt features written in C. When I programmed professionally, my coworkers didn't care much about how slowly their programs ran. Craftsmanship rarely mattered to them either, They thought it was normal to spend two weeks looking for a bug in a 200-page program. Execution speed still mattered, though, when customers for paid for computer time on the company's mainframe. When the other programmers reminded me that processors rand fast and that main storage was inexpensive, my answer sounded something like this. Guys, I want to hire you to write the software for a network of TRS-80 Model 1 computers with 4K of RAM each. But don't worry. I know you're brilliant enough to make a program fly in that tiny address space. I said that because my former coworkers seemed willing to let hardware make up for ridiculously slow memory-gluttons. If those people designed computers, would their standards plummet that far?

[@herrpez]

@@williammcenaney1331 It's hardly that bad. I regularly process hundreds of thousands of rows of tabular data, using pure Python. If it takes less than two seconds, I'm not too fussed. The system that then takes the data takes 20+ minutes (THAT is just staggering; I cannot fathom the amount of crap they have hidden away in the depths of their code). I should add that I do this processing on an underpowered laptop chip, and that a significant amount of time (20-40%) gets tacked on just for printing [a lot of debug data] to the terminal. I don't know whether or not I run a particularly slow/fast terminal, but it gets the job done without too much hassle. I had heard, same as you, that Python was just too slow. But I came in knowing there was stuff like NumPy, Pandas and whatnot to offset this. In the end I just didn't end up needing them for the size of data sets I get.

[@richardrisner921]

"no return" - it sounds like the control flow of my program is never going to come back to my primary stack...

[@CamiloSampedro]

"Never" also sounds like the function will never finish

[@Erlisch1337]

so basically void ?

[@climatechangedoesntbargain9140]

No, void returns without any return value. Is equivalent to None

[@sujitbiswas1995]

which vs code theme is this?

[@Indently]

It's PyCharm

[@sujitbiswas1995]

@@Indently thank you.

[@asagiai4965]

But doesn't that make the code weirder or longer?

[@Indently]

If you're not used to seeing types in code, it will most certainly look weird and longer.

[@asagiai4965]

@Indently I'm actually used to seeing types lol. It is just weird in python because it is technically not really implemented. And it just makes your if else longer

[@XerosOfficial]

​@@asagiai4965 It's not really implemented in TypeScript and also just makes things longer but it certainly has its uses.

[@asagiai4965]

@@XerosOfficial I guess that's true. Though I guess the problem is how people use it.

[@banatibor83]

The most fucked up void implementation ever :) As for Never type as a guard statement, nice if you have something which describes the possible values, but in real life cases that is very rarely the case. Others here said they raise an exception, which is the better way to handle it I think.

[@vytah]

Never lets you check the exhaustiveness at the typechecking level, and you can raise an exception from that helper function anyway. Or course it only works with small finite union types.

[@seppeljordan]

NoReturn is not equivalent with void.

[@vytah]

Also, Python's/Mypy's equivalent of void is None

[@wenbozhao4325]

In a large project or when unexpected runtime exceptions cause problems, static checker is far more valuable than raise exception in the given example code.

[@DrGreenGiant]

​@@vytah None is a testable value so contains information, which is more like NULL. Void contains no information at all because it doesn't exist in memory, it's inaccessible. There is no void type in python as there is no value without memory. Never is pretty close functionality when used as a type specifier for arguments. There are pragmas in C and attributes in C++ for noreturn although they are rare to see.

[@rastersoft]

Instead of "limbo", you should use "floating" 😀

[@SnoFitzroy]

as someone who prefers python for ease of use but is forced to use LUA and Java for circumstantial reasons I generally don't understand people's aggressive criticisms of python. then i actually am reminded of what python code looks like and I'm like "Oh, the C-heads think it looks like a kid language" (but coincidentally everything that makes the language look Like That happen to be the ease of use features I like about it so ig i just forget)

[@richardhaw9757]

"Nothing" makes more sense instead of "NoReturn"

[@Indently]

None already represents Nothing

[@michaelhoffmann2891]

😭

[@schlopping]

It seems a lot of people are coming into this with the mindset of Python being a prototyping language. I'll never understand all the comments about python being a mess. Out of all the languages I've worked in, Python and Rust seem to have the least weird and janky behaviour. I'd get it if they were talking about something like JavaScript, but Python? Really?

[@miguelvasquez9849]

Nice video, but i love to use None :S

[@khodis2002]

And it would be semantically incorrect, because it doesn't actually return None.

[@grawss]

Same. None of these options are particularly correct semantically, especially 'never'. Noreturn makes for the most clarity as a replacement in the usual return spot, but -> None is pretty clear.

[@viddeshk8020]

Static typing make no sense in python right? Because python is a dynamic type language and it can be changed right?

[@adam_fakes]

I agree. While I like many of these videos here, the series on typing in Python does not really make sense. Python is a brilliant language that does not need explicit types. It has types and you can interrogate those types. but you really don't need to tell the IDE (the python interpreter knows), don't try to be super tricky and Copilot will know too :-) . e.g my current roles forces the use of types so a valid statement like x = "-" * 20 is not allowed. (any many variations thereof) basically people tell me "what, why are you multiplying a character by an int", because I can and I want a ASCII line.

[@ingframin]

Types are very helpful to design functions correctly. Plus, mypy can compile annotated code to make it faster.

[@swolekhine]

In addition to what others have said, using type annotations + a type checker helps ensure your code is doing what you think it's doing.

[@AnthonyBerlin]

​​@@adam_fakes Geez. 😅 Type hints and implicit operator overloading are not the same thing so your style guide sounds like a mess for ignoring a simple language feature lol. Are all implicit conversions or operator overloads illegal in other languages as well, where you work? 😅 Type hints are a useful way to prevent bugs and to self document the code in a way that makes it easier for you to know what kind of data or object a function parameter is expecting as an argument. For obvious things (like a write-to-log function for example) they dont really serve a purpose. But when you have hundreds of classes in a huge code base it starts to matter way more. This way you dont need to inspect the code of every function or method you havent used in a while, speeding up the process and making it less likely to make mistakes that may still run (like two classes that have the same name for methods but that do different things, complicating the debug process immensely).

[@mickvel]

@@adam_fakes Well, you can as well define a rep() function an do x = rep("-", 20), it's not hard and may be more clear. I think that the typing in Python is useful to reason about more easily about your code, sure Copilot will now the types, but then you are left confused in the dark...

[@theantonlulz]

Am I missing something or are Never and NoReturn completely pointless?

[@AnthonyBerlin]

It's not necessary. It has more to do with making the code easier to understand, and the static type checker gets more semantic context.

[@vikingthedude]

These are build-time features, not runtime features

[@papernyd]

The video is difficult to understand....

[@tigidou3344]

Never understand why people want typing Python. Just use a another langage like Rust or C++.

[@Indently]

Out of curiosity, why do you click on videos about type annotations if they are irrelevant for you? (I don't mean this in a provocative way or anything, just curious)

[@mintx1720]

-> !

[@CemKavuklu]

With all due respect, "developers know what they are doing" is a rare breed among Python developers and get very quickly disenchanted with Python after realizing what a mess it is. I personally think static type checking is an awesome thing. But using it in Python is kinda like Joey trying to get girls using the cardboard Porsche 😁. It sure looks cool but doesn't do anything under the hood.

[@Indently]

I think the correct analogy for static type checking is the "traffic light", it literally does nothing in terms of stopping your car, and you can drive through it while its still red, or yellow, or even green, whatever it says doesn't affect our actual car. But at the end of the day, that "traffic light" still prevents many accidents. Plus Joey gets all the girls because he's damn handsome 😉

[@aouerfelli]

The annotations are like comments. They do nothing at all to the program.

[@AnthonyBerlin]

Im sure you dont use comments either then? ;)

[@Indently]

I always find it curious though how hard people try to convince others that using type annotations is a waste of time. I mean in real life I imagine these are the same people telling people on bikes that putting a helmet on your head is a waste of time xD

[@strivold4922]

@@Indently Well depending of the situation, that can be argued xD (And yes I ride bikes daily)

[@echobucket]

Too bad we don't have Errors as Types.

[@balcopc]

Great video, useless commands. Because I'm not that bright I have to K.I.S.S. 🤪

[@renaudcalmont]

Please people stop using broken languages like Python, PHP or Javascript and start learning the real stuff instead of endlessly trying to fix them

[@ErikS-]

AGAIN he stole someone else's video! This time from this guy: kzbin.info/www/bejne/m6XOf6Z5h9R-hLssi=tRyCEu-NWfgp_4MU 1) uses the same name! 2) uses the same enum class!

[@Indently]

1) I don't watch videos on KZbin (especially in Russian, because I don't understand Russian) 2) The examples appear the same because this guy "stole" it from the Python docs, just like I "stole" it from the Python docs. 3) Even on the off chance it was "stolen", creating the same tutorial in a different language, in your own wording, with your own examples, is perfectly acceptable.

[@kevincalebout3244]

How to shut up

[@wrichik_basu]

Maybe explain a bit what you didn't like about the video? I don't see an issue with using static type checks, if that is what you had in mind. In a pretty large program, static type checking can be very helpful. These are enhancements to the language that help with readability and debugging. Just like in Java, we originally didn't have options to check NullPointerExceptions, but nowadays, with a proper annotation library, you can track where a NullPointerException could be raised.

[@antoniofernandodiasjunior8896]

Oh my gosh, we are seen some rust influence here