If I remember correctly, packages with graphing capability like pandas and seabourn use this to enable pass-through args to the underlying matplotlib graph object. One thing I'd love to see is improvements to the documentation of kwargs, it can get very frustrating, even though it'd very powerful.
kwargs are very powerful, especially when used with args, but the price you pay for the flexibility is obfuscation, if we could have all the benefits without the obfuscation, then that would be amazing
@@sebastianrodriguezcolina634Like most things in software engineering, there is a trade off between power/expressiveness and clarity/safety. Python already leans toward power/expressiveness in most aspects (dynamic typing, etc.), so using kwargs is at least pretty consistent with other conventions available in Python.
Nested quotes in f-strings is a useful feature when refactoring, and I think a good choice to allow (there was significant debate on this one). However, it also looks bad and is harder to quickly parse visually, thus I hope code formatters will reformat it when possible. This would make for a nice compromise, because if I refactor my code to place a string inside of an f-strings, I could get the ease of readability of alternating quote types with a simple call to my formatter.
I have two use cases for kwargs: 1. when creating a wrapper function for another function. 2. when passing around parameters for ML and data science projects. Typically I store these as json files, so it’s nice to use dictionaries to pass around those parameters.
Also when making an abstract or parent class, different child classes might need different arguments in their constructors and other functions. As you can't control how future developers will extend the class, you need to keep some functions generic. This is similar to the wrapper use case, except in this instance you're wrapping functions that might not exist yet.
Using kwargs with argparse for passing command line args to the program entry point is one of my favorite Python patterns. Nothing more satisfying than writing main(**vars(args)) instead of passing everything to main manually.
Mainly a yawn except for better comprehension speed and better GIL lock optimization which really isn't surfaced. Type annotation stuff leaves me quite cold because if I wanted a typed language I would use something else in the first place.
0:10 In the past Python had their last version be a mathematical constant. 1.6.1 aka φ (Golden ratio) 2.7.18 aka e (Euler's number) 3.14.1? aka π Coincidence? I think not Does this mean Python 4 is coming soon? Probably not
I have not used kwargs too much myself, but I have seen some really good use cases. One of them is collecting a bunch of optional (kw) arguments at top level, and then reducing the kwargs dict as you move down the tree of functions or methods, as each of them have explicit named arguments set by some of the kwargs provided by their "parent" function (the caller) and then collecting the remainder as a smaller kwargs dict passed to their children.
🎯 Key Takeaways for quick navigation: 00:56 🐍 Python 3.12 introduces improved error messages, including suggestions for missing imports and common coding errors, enhancing the coding experience. 02:24 🚀 Python 3.12 brings performance improvements, particularly in comprehension inlining, resulting in up to 2x speedup in some cases and an overall 11% performance boost. 03:51 🧊 Python 3.12 introduces "immortal objects," objects with a fixed reference count, reducing memory usage and simplifying code optimization. 04:49 🌐 Python 3.12 lays the foundation for per-interpreter Global Interpreter Lock (GIL), enhancing multi-core utilization in future versions. 05:48 📜 F-strings in Python 3.12 become less restrictive, allowing nested double quotes for improved string formatting. 06:44 🎯 Python 3.12 simplifies type annotations, allowing for easier definition of keyword argument types and introduces the "override" keyword for explicit method overriding. 08:40 🧬 Python 3.12 introduces a new syntax for type parameters and generic classes/functions, simplifying the handling of generics. 10:32 📂 Pathlib now includes a "walk" method, making it easier to traverse directory trees, and CPython 3.12 supports instrumentation for monitoring calls, returns, lines, and exceptions, improving debugging and coverage tools. 11:28 ❌ Python 3.12 removes deprecated modules like asyncore and asynchat, encourages the use of async.io, and deprecates old method names in the unit test package. Made with HARPA AI
Kwargs are a really great feature when you are writing larger repositories. When passing arguments to other repeatedly called functions, this makes the code much cleaner. One example if with spark dataframes. I have one function that does all of the filtering with arguments per column. Most other functions call this function at the beginning with kwargs being passed directly to it.
I'm sorry, but this overriding will make the language bad; it will be close to java when java programmers do not respect the open-close principle. Sorry Python, you didn't do well.
Yes i use kwargs when I have a wrapper function over a core function and I still want to provide all the functionality of the core function without having to update the params in two places.
I would love to see more content in the form of series on 1. threading vs multiprocessing 2. distributed computing in python using ray framework or its equivalent
I usually use *args and **kwargs when creating custom decorators. I like to create decorators for code reusability and custom tools for my projects. Also a custom paters is the composition and some time you can create some custom wrappers utilities that receive an object instance with some arbitrary parameters and you perform some kind of logic.
Hey @ArjanCodes, if you want function annotations, then create a Protocol class and define the __call__ method and then add the type anotations for the parameters in that __call__ method. When you will use the the Protocol to type a function it will describe it with the type of the __call__ method.
Thanks for again for your excellent content. I would love to see a comprehensive tutorial for typing. All of existing ones go through the basics, but someone needs to explain how I can get VSCode and Black to pass on real code with a "strict" setting.
That depends on how outdated your dependencies are. We just finished upgrading a big system from 3.6 to 3.11. It was extremely painful! From 3.1x to 3.12 it should be a piece of cake.
There really won't be any price to pay for upgrading from a recent version of Python. It should be seamless except for certain packages which will need to release wheels for that build. You should be fine.
I use kwargs mostly in the inner functions of decorators; here I want a very generic function interface to allow any function to be decorated. But other than that I agree, kwargs are kind of fuzzy. I saw a really bad use case for kwargs in a multiple inheritance example once, where kwargs where used to 'bubble up' arguments through an inheritance chain lol.
Hi Arjan, I tried to sign up for your 7-step guide but your website would not accept my email address. It has a "+" in it and this tends to stymie many websites. Maybe you can fix this? Edit: It seems that, despite throwing an error, it sent me your guide link, anyway. Thank you!
it's already that time again? I remember last time there was actually a live stream of the publishing, which was quite interesting, because the different core developers for various projects talked about what they did.
I'd love to have a sane code import (why do I have to care about circular imports in 2023?!), namespacing mechanism and packaging I cant wait to remove the `if TYPE_CHECKING` and value: 'str' stuff.
importerror:DLL load failed while importing _cext:The specified module could not be found, what is this error please give me solution, this occur when I import matplotlib, in python 12.00,please😭😭😭
Come to think of it, I rarely find myself using **kwargs in plain function parameters. I'll often unpack a dictionary to provide the specified arguments though.
I use **kwargs when I want to define an __init__() method that can accept a variety of signatures and then construct the instance according to the signature provided. I don't like it and am looking for a nicer way to do this.
8:59 so default type vars specified with the new syntax are now covariant instead of invariant? EDIT: Answer: No apparently type checkers can infer it now.
I usually need keyword arguments when writing a function A that wraps another function B and I need to simply forward the arguments from A to B. But that is a very specific use case.
i almost never use *args and **kwargs. too opaque and error prone. the only time i find myself using them is when writing decorators or something of the like.
I am pretty sure that he's just making stuff up. Immortal objects aren't necessarily immutable. They arguably aren't even "const ref", but more like "intentionally leaked" or "static lifetime" objects.
As a data scientist, I use kwargs a lot because a lot of the code I work with needs to be run in many configurations during experimentation.For example, model training loops can be way easier to control with a function that uses kwargs.
most languages don't rely on variadic arguments outside of string formatting/collection creation, and nobody complains. python's variadic arguments are a prefect example of induced demand. most languages would define structs/data classes like LineStyle or ModelConfig, but python does kwargs.
meh. 3.12 is disappointing for me to be honest. the big thing we are all waiting for is the GIL changes. other things you mentioned are cool additions, sure, but they are not gonna cut it alone.
6:30 I think is important that new feature, I recently build an API for NLP, and the user can input strings, and if the string had " character, the pydantic validator returned 422 status. I think that now could be fixed, right?
kwargs are good when using class inheritance. For instance, a constructor for a subclass is only required to declare input variables that differ from the super class. further instantiating the base class is as simple as super().__init__(**kwargs). in this way, you don't need to declare all input variables in the subclass AND the base class. Most IDEs are aware of this pattern making systems like intellisense recommend input variables for the subclass, even though they are only in the base class.
By the way, the new error messages with suggestions are so useful. I tried to run python -m ttkbootstrap and had an error. Fallowed the suggestion I changed Image.CUBIC to Image.BICUBIC somewhere in the library and that fixed it.
Keyword arguments make sense when you are writing code where you don't know your inputs. For example, I had written a Python PowerShell wrapper function which would take a unknown number of arguments but the logic to execute the code was mainly the same. Very special use case but I agree that I can't see a reason to use it much.
I find my engineers have tended more toward overuse of keyword arguments, to the point where they are everywhere e.g. something as basic as get_foo(foo_name=foo_name) Personally I don't like using them unless it's an optional arg or the function being called is too complicated and has too many args
I'd rather have proper algebraic enums instead of arrow syntax. having better generics is nice, but i am not sure why one would need them in python. I think that about a lot of new trends in python lately. But then I meet coworkers who do not understand certain stuff before you typehint it. When the syntax addiction is that strong, I ask myself sometimes, why not just switch to rust or sth.
Hi Arjan, I usually love your show, however your comment about you not using kwargs to be specific left me somehow speechless :). I believe kwargs are the by far superior way to be specific in your functions. So, I assume that you only made that statement to spark some outrage in your comment section. Here is an example of how I would use them: import argparse ... parser.add_argument('-ks', '--kwargToBeSpecificAbout', ...) parser.add_argument(...) ... def main(*args, kwargToBeSpecificAbout, **kwargs): do_something with kwargToBeSpecificAbout if __name__ == "__main__": main(*args, **parser.parse_args().__dict__)
I used keywords arguments for web handlers so that I can convert responses to an object very quickly and don't have to worry about excess properties coming from the frontend.
Yeah when people make change to code like that and it just goes crazy faster… yeah… I can barely do a simple Django backend… no clue how people make the stuff do that… really just makes me feel stupid.
7:23 - yeah, all the time. i come from languages where this is necessary so it's more of a habit. but i enjoy reading and refactoring code that has type annotations, it speeds up my work tremendously
I usually try to avoid kwargs as well, but it is useful when making a wrapper around something that either has *a lot* of parameters or itself has a kwargs that you need to supply.
![[UNCUT] “บอสณวัฒน์” ลากไส้!! ใครหนุนหลัง "แม่ตั๊ก ป๋าเบียร์" I คนดังนั่งเคลียร์ I 30 ก.ย. 67](http://i.ytimg.com/vi/QlD7mU2KKRk/mqdefault.jpg)
💡 Get my FREE 7-step guide to help you consistently design great software: arjancodes.com/designguide.
We make use of kwargs in our library for passing user arguments to functions from other libraries (i.e in our wrapper functions)
If I remember correctly, packages with graphing capability like pandas and seabourn use this to enable pass-through args to the underlying matplotlib graph object.
One thing I'd love to see is improvements to the documentation of kwargs, it can get very frustrating, even though it'd very powerful.
kwargs are very powerful, especially when used with args, but the price you pay for the flexibility is obfuscation, if we could have all the benefits without the obfuscation, then that would be amazing
@@PixelThornyou might like typing.ParamSpec, helps a lot for this kind of thing
Such practice requieres you to know implementation details of the function, I dislike that in general.
@@sebastianrodriguezcolina634Like most things in software engineering, there is a trade off between power/expressiveness and clarity/safety. Python already leans toward power/expressiveness in most aspects (dynamic typing, etc.), so using kwargs is at least pretty consistent with other conventions available in Python.
Nested quotes in f-strings is a useful feature when refactoring, and I think a good choice to allow (there was significant debate on this one). However, it also looks bad and is harder to quickly parse visually, thus I hope code formatters will reformat it when possible. This would make for a nice compromise, because if I refactor my code to place a string inside of an f-strings, I could get the ease of readability of alternating quote types with a simple call to my formatter.
I have two use cases for kwargs:
1. when creating a wrapper function for another function.
2. when passing around parameters for ML and data science projects. Typically I store these as json files, so it’s nice to use dictionaries to pass around those parameters.
Do you have an example I could learn from?
@@kelkka7no
@@kelkka7 Check how to write decorators for functions with arguments.
This. I do this as well. Nice and clean.
Also when making an abstract or parent class, different child classes might need different arguments in their constructors and other functions. As you can't control how future developers will extend the class, you need to keep some functions generic. This is similar to the wrapper use case, except in this instance you're wrapping functions that might not exist yet.
Using kwargs with argparse for passing command line args to the program entry point is one of my favorite Python patterns. Nothing more satisfying than writing main(**vars(args)) instead of passing everything to main manually.
The enablement of having nested quotes in f-string is great when you need to access some dictionary field inside the f-string.
The new generic style and the new type alias function is what I'm more excited about.
Same, plus Unpack and TypedDict for type annotating kwargs is quite useful
@@sohangchopra6478 yea I can't wait to get to use them.
Mainly a yawn except for better comprehension speed and better GIL lock optimization which really isn't surfaced. Type annotation stuff leaves me quite cold because if I wanted a typed language I would use something else in the first place.
It’s be pretty funny to see a Python 3.14 version nicknamed Pi-thon with a bunch of circle based updates
0:10 In the past Python had their last version be a mathematical constant.
1.6.1 aka φ (Golden ratio)
2.7.18 aka e (Euler's number)
3.14.1? aka π
Coincidence? I think not
Does this mean Python 4 is coming soon? Probably not
I have not used kwargs too much myself, but I have seen some really good use cases. One of them is collecting a bunch of optional (kw) arguments at top level, and then reducing the kwargs dict as you move down the tree of functions or methods, as each of them have explicit named arguments set by some of the kwargs provided by their "parent" function (the caller) and then collecting the remainder as a smaller kwargs dict passed to their children.
Super terrible idea! Do this and after a month you won't have any idea what inputs your method require. When you feel the need for kwargs use a class.
🎯 Key Takeaways for quick navigation:
00:56 🐍 Python 3.12 introduces improved error messages, including suggestions for missing imports and common coding errors, enhancing the coding experience.
02:24 🚀 Python 3.12 brings performance improvements, particularly in comprehension inlining, resulting in up to 2x speedup in some cases and an overall 11% performance boost.
03:51 🧊 Python 3.12 introduces "immortal objects," objects with a fixed reference count, reducing memory usage and simplifying code optimization.
04:49 🌐 Python 3.12 lays the foundation for per-interpreter Global Interpreter Lock (GIL), enhancing multi-core utilization in future versions.
05:48 📜 F-strings in Python 3.12 become less restrictive, allowing nested double quotes for improved string formatting.
06:44 🎯 Python 3.12 simplifies type annotations, allowing for easier definition of keyword argument types and introduces the "override" keyword for explicit method overriding.
08:40 🧬 Python 3.12 introduces a new syntax for type parameters and generic classes/functions, simplifying the handling of generics.
10:32 📂 Pathlib now includes a "walk" method, making it easier to traverse directory trees, and CPython 3.12 supports instrumentation for monitoring calls, returns, lines, and exceptions, improving debugging and coverage tools.
11:28 ❌ Python 3.12 removes deprecated modules like asyncore and asynchat, encourages the use of async.io, and deprecates old method names in the unit test package.
Made with HARPA AI
Kwargs are a really great feature when you are writing larger repositories. When passing arguments to other repeatedly called functions, this makes the code much cleaner. One example if with spark dataframes. I have one function that does all of the filtering with arguments per column. Most other functions call this function at the beginning with kwargs being passed directly to it.
Wonderful! We get amazing new interpreters. But to access them, the API is the same as exec and eval's.
I'm sorry, but this overriding will make the language bad; it will be close to java when java programmers do not respect the open-close principle. Sorry Python, you didn't do well.
10:06 I agree with you, but sadly the PEP for it is rejected. See PEP 677.
Yes i use kwargs when I have a wrapper function over a core function and I still want to provide all the functionality of the core function without having to update the params in two places.
I would love to see more content in the form of series on
1. threading vs multiprocessing
2. distributed computing in python using ray framework or its equivalent
Amazing! Almost all of these changes are things that have personally annoyed me many times. Python has been killing it recently with these updates.
I usually use *args and **kwargs when creating custom decorators. I like to create decorators for code reusability and custom tools for my projects. Also a custom paters is the composition and some time you can create some custom wrappers utilities that receive an object instance with some arbitrary parameters and you perform some kind of logic.
The override decorator is my favorite new feature.
Hey @ArjanCodes, if you want function annotations, then create a Protocol class and define the __call__ method and then add the type anotations for the parameters in that __call__ method. When you will use the the Protocol to type a function it will describe it with the type of the __call__ method.
the TypedDict kwargs feature will be useful for cases where we have function params that are being passed around or through as a group
Nice video! Sorry to tell you but there is some kind of issue with the sound, like an echo from the wall.
Thanks for again for your excellent content. I would love to see a comprehensive tutorial for typing. All of existing ones go through the basics, but someone needs to explain how I can get VSCode and Black to pass on real code with a "strict" setting.
version 3.12 (pi) thon that was top class joke 😂😂
I'd love to see a beginner guide on how to upgrade from 3.1x to 3.12.. Including getting all the globally installed modules carried over and working.
That depends on how outdated your dependencies are. We just finished upgrading a big system from 3.6 to 3.11. It was extremely painful! From 3.1x to 3.12 it should be a piece of cake.
There really won't be any price to pay for upgrading from a recent version of Python. It should be seamless except for certain packages which will need to release wheels for that build. You should be fine.
finally there is unpack and better generics
override decorator is a nice addition. Before every method was virtual. Now you have a bit more control over it.
I use kwargs mostly in the inner functions of decorators; here I want a very generic function interface to allow any function to be decorated. But other than that I agree, kwargs are kind of fuzzy. I saw a really bad use case for kwargs in a multiple inheritance example once, where kwargs where used to 'bubble up' arguments through an inheritance chain lol.
That intro is really funny lmao
Gives me 2014 vibes
I love python only thing it needs is ilntegration into webpages eaily
Hi Arjan, I tried to sign up for your 7-step guide but your website would not accept my email address. It has a "+" in it and this tends to stymie many websites. Maybe you can fix this?
Edit: It seems that, despite throwing an error, it sent me your guide link, anyway. Thank you!
how many versions of python do you guys keep on your machines?
😂👌 exactly!
it's already that time again?
I remember last time there was actually a live stream of the publishing, which was quite interesting, because the different core developers for various projects talked about what they did.
immortal or immutable?
This is going in the direction of Python#
The place that i use kwargs is when passing arguments to celery tasks in flask applications
for the beginner these new error messages are amazing and so more useful!
Nice Scal-thon.
I love they they are just making things better instead of adding candy
Thanks for review! Which theme do you use for VS Code?
I'd love to have a sane code import (why do I have to care about circular imports in 2023?!), namespacing mechanism and packaging
I cant wait to remove the `if TYPE_CHECKING` and value: 'str' stuff.
Hi! I have error from the designguide email when open: PR_END_OF_FILE_ERROR
importerror:DLL load failed while importing _cext:The specified module could not be found, what is this error please give me solution, this occur when I import matplotlib, in python 12.00,please😭😭😭
Come to think of it, I rarely find myself using **kwargs in plain function parameters. I'll often unpack a dictionary to provide the specified arguments though.
Don't use key arguments, don't use difficult to read comprehensions, don't use ugly (syntax) f"strings".
I use **kwargs when I want to define an __init__() method that can accept a variety of signatures and then construct the instance according to the signature provided. I don't like it and am looking for a nicer way to do this.
8:59 so default type vars specified with the new syntax are now covariant instead of invariant?
EDIT: Answer: No apparently type checkers can infer it now.
I usually need keyword arguments when writing a function A that wraps another function B and I need to simply forward the arguments from A to B. But that is a very specific use case.
PyTorch isn't even available yet on python 3.11 There's absolutely no reason to update to 3.12
Is there genuinely something special expected to happen with Python 3.14, or was it just a joke?
kwargs unpacking will be useful for a big and complicated things like libraries and frameworks
Nested double quotes!
Imo this deserves the nobel prize for programming!
i almost never use *args and **kwargs. too opaque and error prone. the only time i find myself using them is when writing decorators or something of the like.
The company I work for still stuck with 3.6. No point even looking.
So basically Python realised Java is good, let's copy some features
Are immortal object immutable as implied or are the effectively a const ref. Different use-cases?
I am pretty sure that he's just making stuff up. Immortal objects aren't necessarily immutable. They arguably aren't even "const ref", but more like "intentionally leaked" or "static lifetime" objects.
Did they fix the comprehensions leaking like a sieve?
Hell yah I use **kwargs
There is still no satisfying method of converting a Python-program to an EXE-File to me
It is not three point *twelve* but three point one two. Not saying this to sound pedantic but hopefully some people will learn this common mistake.
9:19 - I am not a fan of this change...
Square brackets do not belong after class or method definitions imo!
As a data scientist, I use kwargs a lot because a lot of the code I work with needs to be run in many configurations during experimentation.For example, model training loops can be way easier to control with a function that uses kwargs.
most languages don't rely on variadic arguments outside of string formatting/collection creation, and nobody complains.
python's variadic arguments are a prefect example of induced demand. most languages would define structs/data classes like LineStyle or ModelConfig, but python does kwargs.
When 3.14 comes out, I hope they call it Pithon
A video about Python 3.12 that has a duration of 12.03. Nice!
immortal doesn't mean "isn't going to change" it means "isn't going to die" it won't get cleaned up. It can still change
thx, i was wondering about that, now it seems useful.
meh. 3.12 is disappointing for me to be honest. the big thing we are all waiting for is the GIL changes. other things you mentioned are cool additions, sure, but they are not gonna cut it alone.
Demand your money back.
I never use kwargs, I use a dict if I need flexible parameter.
Has anyone created a class to pass arguments around ? Would you consider it ? Why and why not ?
Nice, the typevar hustle was one of the reasons I switched to Julia
6:30 I think is important that new feature, I recently build an API for NLP, and the user can input strings, and if the string had " character, the pydantic validator returned 422 status. I think that now could be fixed, right?
so the new python version is basically a whole bunch of stuff that is going to come in the next one?
The only place I can think of where kwargs are appropriate is when writing function decorators (or any other kind of delegates)
Wow the π-thon and python joke works in Greek too. Wait, a minute...
Is this a non-beta release? I was kidding around wirh the alpha release weeks ago
Python 3.14 will have a dependent type system
I like typings in general, but a lot of people hate being specific.
I´m waiting for the Pie-thon too (3.60) 😂😮
I thought there should be only one obvious way to do something.
Most noisy keyboard I have ever heard. Is this a feature or is it broken?
Allowing nested strings seems like it comes with its own problems.
What's that keyboard, and what switches? Thanks
kwargs are good when using class inheritance. For instance, a constructor for a subclass is only required to declare input variables that differ from the super class. further instantiating the base class is as simple as super().__init__(**kwargs). in this way, you don't need to declare all input variables in the subclass AND the base class. Most IDEs are aware of this pattern making systems like intellisense recommend input variables for the subclass, even though they are only in the base class.
By the way, the new error messages with suggestions are so useful.
I tried to run python -m ttkbootstrap and had an error.
Fallowed the suggestion I changed Image.CUBIC to Image.BICUBIC somewhere in the library and that fixed it.
Keyword arguments make sense when you are writing code where you don't know your inputs. For example, I had written a Python PowerShell wrapper function which would take a unknown number of arguments but the logic to execute the code was mainly the same. Very special use case but I agree that I can't see a reason to use it much.
I find my engineers have tended more toward overuse of keyword arguments, to the point where they are everywhere e.g. something as basic as get_foo(foo_name=foo_name)
Personally I don't like using them unless it's an optional arg or the function being called is too complicated and has too many args
I'd rather have proper algebraic enums instead of arrow syntax. having better generics is nice, but i am not sure why one would need them in python.
I think that about a lot of new trends in python lately.
But then I meet coworkers who do not understand certain stuff before you typehint it.
When the syntax addiction is that strong, I ask myself sometimes, why not just switch to rust or sth.
Hi Arjan, I usually love your show, however your comment about you not using kwargs to be specific left me somehow speechless :). I believe kwargs are the by far superior way to be specific in your functions. So, I assume that you only made that statement to spark some outrage in your comment section.
Here is an example of how I would use them:
import argparse
...
parser.add_argument('-ks', '--kwargToBeSpecificAbout', ...)
parser.add_argument(...)
...
def main(*args, kwargToBeSpecificAbout, **kwargs):
do_something with kwargToBeSpecificAbout
if __name__ == "__main__":
main(*args, **parser.parse_args().__dict__)
I used keywords arguments for web handlers so that I can convert responses to an object very quickly and don't have to worry about excess properties coming from the frontend.
Yeah when people make change to code like that and it just goes crazy faster… yeah… I can barely do a simple Django backend… no clue how people make the stuff do that… really just makes me feel stupid.
Thanks!
Also: it’s A-liases, not a-LI-ases.
I'm not using **kwargs in my functions because it seems as a lack of control. You never know what it contains. Explicity is the way :)
7:23 - yeah, all the time. i come from languages where this is necessary so it's more of a habit. but i enjoy reading and refactoring code that has type annotations, it speeds up my work tremendously
Anyone knows the PR for f-stringa, i have mixed reactions. This is going to invoke some chaos compared to f-strings.
Hi, please could you create a Video about Mojo Programming Language with Python
I don't use keywords arguments, generally, trying to pass a single pydantic models between functions
Now that Python 3.12 is coming, maybe it's finally safe to upgrade to 3.11
I usually try to avoid kwargs as well, but it is useful when making a wrapper around something that either has *a lot* of parameters or itself has a kwargs that you need to supply.
Thank you for your video. I've never used Generic function or class. Wouldn't it be interesting if you do a video on it?
Tried to subscribe to your newsletter but did not get a confirmation email. Is your service down?