python: what is assert? (beginner) anthony explains

[@v0id_d3m0n]

Thanks. Great concise explanation. Thanks for explaining the use cases as well

[@nadew.02]

Thank you for the video. I understood well

[@1234minecraft5678]

i think it is very weird, that -O sets __debug__ to false, which i would assume would be the normal behaviour. So you dont habe to enable debug, but disable it

[@jewdude6785]

Thanks for the video! Personally I would like to watch videos about best practices for how to structure python projects and repositories for different kinds of projects - web app, bot, command line utils etc.

[@anthonywritescode]

a lot of those would be opinion based -- that said I've done one on libraries already: ua-cam.com/video/sW1qUZ_nSXk/v-deo.html and one about a testable command line utility: ua-cam.com/video/sv46294LoP8/v-deo.html -- I'm probably going to do a video about flask at some point

[@andrepinto275]

@@anthonywritescode An opinion based video regarding project structure for a web app would be great!

[@anthonywritescode]

if you search my channel I did a video on my project structure

[@johnwight6041]

Not only did I learn about assert statements but also was exposed to pytest, breakpoint() and pass. Thank you for the great video!

[@GOZES]

It would be nice to see a video(s) about working with the python AST :)

[@anthonywritescode]

check this out: ua-cam.com/video/ot5Z4KQPBL8/v-deo.html -- is there mode you'd like to see?

[@GOZES]

@@anthonywritescode in one of your recent streams you quickly showed how pytest does assert rewrite. I found the ast rewrite stuff super interesting so I it would be great to see a video about that. Also it would be a great extension to the fleak8 video :) I'm also looking forward to when you do a video about namespace packages

[@anthonywritescode]

do you mean source rewriting or just ast rewriting? pytest doesn't do the former and the latter isn't really all that helpful for most. the former is also really really difficult (pyupgrade / etc. use a particular technique, other code formatters use other techniques)

[@GOZES]

@@anthonywritescode oh I didn't know it was two different technics 😅 then I guess the fleak8 video will have to do. Btw it was really good :)

[@anthonywritescode]

yep yep, the "A" in AST is "Abstract" -- in order to do source manipulations you need a CST ("Concrete Syntax Tree")

[@patskanteam]

-O disables asserts, -OO disables asserts + docstrings

[@akshaymestry971]

Does it makes sense to use asserts for building contracts?
The gist is I'm working on a package and in that I want to have a module that enforces module/function/class level annotations. The annotations actually don't help much in the process of execution for the library user but it helps the library itself to find its way around the passed arguments. To solve this I've been watching your videos on `typing` module particularly the overload method video and it has certainly helped. But does it really makes sense to implement that many things (asserts based contracts which enforces types and overload which returns true values) in a library where chances are many user are aware of -O notation and can potentially use it thus disabling the whole feature? I hope I was able to explain my dilemma. This has been bugging me since I started off on the project.

[@anthonywritescode]

I guess the rule of thumb I'd use is asserts are nice for the developer, but probably shouldn't be depended on at runtime (unless you're sure about how all of your consumers run your code). if you want them to be used as actual guards in code you probably want to write a separate helper instead of using the assert statement directly (and perhaps even raise your own special error type such that a consumer could react to that instead)

[@akshaymestry971]

Also can you please explain what should* be the ideal way to type hint *args and **kwargs in context of being aware of *args and **kwargs arguments. In some cases I'm aware I'll passing all strings as arguments hence I use *args: str (is this correct?) or in some cases where I'm uncertain of the keyword args I tend to use **kwargs: Dict[str, Any] which feels wrong on so many levels but type checkers are fine by it so I usually call it a day and move on. But really wanted to know if there is a `CORRECT` way of annotating *args and **kwargs

[@anthonywritescode]

yep! I go over precisely that topic in this video: ua-cam.com/video/CqafM-bsnW0/v-deo.html -- the "correct" answer is going to change eventually with variadic typing and ParameterSpec (I don't remember the exact name, but it's being workshopped as a PEP right now)

[@akshaymestry971]

@@anthonywritescode Sir, you're the BEST!

[@hiiiiiiii7808]

Is there going to be a video on PEP 634.??

[@anthonywritescode]

mayyyybe, I was hoping the implementation would get done before doing a video in case it changes too much after that

[@jerepovedamartinez4574]

Hi, I work in deep learning and I am developing a "framework" for internal use. I want to force the shape of my tensors, I'm doing it with asserts but all the strings dancing around make the code less readable, any suggestions?

[@anthonywritescode]

you might be able to use a type checker and the new variadic generics -- ua-cam.com/video/hAj3nGzeSiQ/v-deo.html

[@zououoz3588]

I got an error when trying to do that {x=}

[@anthonywritescode]

you need python3.8+

[@zououoz3588]

@@anthonywritescode Ah i see ty

[@angelcaru]

b-but isn't assert the thing you put to make mypy shut the f up?? /s

[@EW-mb1ih]

Why do you state that using "assert" is not a security issue?

[@anthonywritescode]

did you watch the video? I go over it