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.
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.
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.
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.
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.
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.
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 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.
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.
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
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.
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.
🎯 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
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.
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
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.
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.
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
Using kwargs in Django view helpers. Have a few pdf reports that require generation and using pdfkit underneath. So kwargs is being used to pass context for pdf report generation and then also for configuring pdfkit
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.
We're using kwargs mostly in forward method for pytorch models. It allows for versatile forward implementation like diffusion models that take not only input but also timestamp, as well as other tailor made models that require more than just input. This way we don't have to break our model interface or split it
One thing I was playing around with was using a combination of inspect and vars() to loop through each function, extract the arguments it needs and select the appropriate variable(s) from vars() to pass in. This is nice when variable names match the function argument names so it's not perfect but useful in some cases. I don't have to worry about figuring out exactly what a function needs. I'm sure there are negatives to this as well but it's one way I like.
I have a query builder that passes user arguments (optional and required) along to a DB client as a formatted query string. Good for when I have to maintain a lot of different etl and dbt pipelines and want to use the same basic development pattern for them. In general kwarg unpacking is really invaluable or any kind of client wrapper function or class.
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 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.
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.
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.
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.
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 initially learned python about 20 years ago. A great feature of python 2, compared to C/C++ for instance, is that it didn't care much about types. It cared about interface instead, i.e it doesn't matter the type of the object, as long as it has the method foo() that the code is expecting. That made python inherently polymorphic. Trying to updating myself to python 3, I see that types are back big time nowadays. Not sure where the need for this came from.
there are multiple studies (eg. monitoring projects on github) that show evidences that typing reduce runtime errors, so python but also javascript (with typescript) and php tried to introduce without enforcing this concept. So personally speaking i never had issues with lack of typing in python 2, but i guess it's very different when you have to work over large code bases that you don't really own.
I created a SQL connector for my team and it uses kwargs to execute any SP with a simple function called sp_exec You pass the SP name and in the kwargs you pass the sp parameters It works for any SP with any amount of arguments User just needs to use 1 function
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?
I use lot of keywords arguments and type notations,❤ I create lots of functions and sometimes i forget which type of argument it needs to pass, so i have to go back to function and read or read doc its pretty complicated so i prefer to use keywords args, notation lots, and it give a impression look 👀 code, my manager always gwt impressed with my code 😂❤
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.
I tried using kwargs in that pattern that you keep passing it down and each layer gets its parameters, but I think it gets really messy after some time. But I do use it in the signature in some situations where I , for example, load a config and want to initialize an object with it. I'd call it like **config. The object gets what it wants from the config, but I don't pass kwargs further down. I find it especially useful when the code is changing quickly.
The @override decorator makes Python a little bit closer to C++. That's a great sign, because the more sophisticated C++ OOP we adopt, the more programmers we need to operate Python
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.
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.
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 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'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.
What I mean is that I’d like to see more readable function type annotations in Python. Instead of ‘Callable[[int], bool]’ I’d like to write something like ‘(int) => bool’.
💡 Get my FREE 7-step guide to help you consistently design great software: arjancodes.com/designguide.
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.
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.
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.
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.
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.
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.
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 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.
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.
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
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.
10:06 I agree with you, but sadly the PEP for it is rejected. See PEP 677.
the TypedDict kwargs feature will be useful for cases where we have function params that are being passed around or through as a group
The enablement of having nested quotes in f-string is great when you need to access some dictionary field inside the f-string.
The override decorator is my favorite new feature.
override decorator is a nice addition. Before every method was virtual. Now you have a bit more control over it.
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.
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.
🎯 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
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.
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
It’s be pretty funny to see a Python 3.14 version nicknamed Pi-thon with a bunch of circle based updates
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.
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.
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
Amazing! Almost all of these changes are things that have personally annoyed me many times. Python has been killing it recently with these updates.
The place that i use kwargs is when passing arguments to celery tasks in flask applications
A video about Python 3.12 that has a duration of 12.03. Nice!
Using kwargs in Django view helpers. Have a few pdf reports that require generation and using pdfkit underneath. So kwargs is being used to pass context for pdf report generation and then also for configuring pdfkit
Double quotes in f-strings is life-changing. How did I ever life without this?
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.
5:48 (f-strings), very much needed and appreciated!
Nice, the typevar hustle was one of the reasons I switched to Julia
We're using kwargs mostly in forward method for pytorch models. It allows for versatile forward implementation like diffusion models that take not only input but also timestamp, as well as other tailor made models that require more than just input. This way we don't have to break our model interface or split it
At the cost of not telling your fellow developers what could go into kwargs…
One thing I was playing around with was using a combination of inspect and vars() to loop through each function, extract the arguments it needs and select the appropriate variable(s) from vars() to pass in. This is nice when variable names match the function argument names so it's not perfect but useful in some cases. I don't have to worry about figuring out exactly what a function needs. I'm sure there are negatives to this as well but it's one way I like.
I have a query builder that passes user arguments (optional and required) along to a DB client as a formatted query string. Good for when I have to maintain a lot of different etl and dbt pipelines and want to use the same basic development pattern for them. In general kwarg unpacking is really invaluable or any kind of client wrapper function or class.
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 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.
One of the common cases for kwargs is when you need to pass-through args to os.execv. For example for cli tools that wrap something.
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.
Wonderful! We get amazing new interpreters. But to access them, the API is the same as exec and eval's.
kwargs are suitable for metaprogramming, especially when making libraries. I use them for making general functions for tests.
Keyword args are fairly important when writing data pipelines in Apache Airflow
Nested double quotes!
Imo this deserves the nobel prize for programming!
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.
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 only use kwargs for input cases, and even then it's rarely used as there aren't too many cases where you can't write an explicit alternative
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?
for the beginner these new error messages are amazing and so more useful!
@Arjan,You are the best python programmer. Waiting for your architecture course!
Thanks for review! Which theme do you use for VS Code?
Don't use key arguments, don't use difficult to read comprehensions, don't use ugly (syntax) f"strings".
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.
kwargs unpacking will be useful for a big and complicated things like libraries and frameworks
I love python, fingers crossed that nogil implementation goes smoothly
I initially learned python about 20 years ago. A great feature of python 2, compared to C/C++ for instance, is that it didn't care much about types. It cared about interface instead, i.e it doesn't matter the type of the object, as long as it has the method foo() that the code is expecting. That made python inherently polymorphic. Trying to updating myself to python 3, I see that types are back big time nowadays. Not sure where the need for this came from.
there are multiple studies (eg. monitoring projects on github) that show evidences that typing reduce runtime errors, so python but also javascript (with typescript) and php tried to introduce without enforcing this concept. So personally speaking i never had issues with lack of typing in python 2, but i guess it's very different when you have to work over large code bases that you don't really own.
@@giacomo83m thank you
The only place I can think of where kwargs are appropriate is when writing function decorators (or any other kind of delegates)
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 ?
I also have some hopes for a fully functional cython at some point. A python syntax language but compiled and making use of some more C features.
i like cython more than mojo actually. Cython is the best choice for me. Unfortunally, does not implement 100% python, which is sad.
Your sense of humor is on point today!
I created a SQL connector for my team and it uses kwargs to execute any SP with a simple function called sp_exec
You pass the SP name and in the kwargs you pass the sp parameters
It works for any SP with any amount of arguments
User just needs to use 1 function
That’s quite a reasonable use. Do you introspect the procedure prototype to do typechecking against the arguments before actually invoking it?
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?
I have used kwargs only for decorator functions.
I use lot of keywords arguments and type notations,❤
I create lots of functions and sometimes i forget which type of argument it needs to pass, so i have to go back to function and read or read doc its pretty complicated so i prefer to use keywords args, notation lots, and it give a impression look 👀 code, my manager always gwt impressed with my code 😂❤
how many versions of python do you guys keep on your machines?
😂👌 exactly!
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.
I tried using kwargs in that pattern that you keep passing it down and each layer gets its parameters, but I think it gets really messy after some time. But I do use it in the signature in some situations where I , for example, load a config and want to initialize an object with it. I'd call it like **config. The object gets what it wants from the config, but I don't pass kwargs further down. I find it especially useful when the code is changing quickly.
I like typings in general, but a lot of people hate being specific.
Thanks for the update.
Nice video! Sorry to tell you but there is some kind of issue with the sound, like an echo from the wall.
The @override decorator makes Python a little bit closer to C++. That's a great sign, because the more sophisticated C++ OOP we adopt, the more programmers we need to operate Python
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.
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.
Hi, please could you create a Video about Mojo Programming Language with Python
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 don't use keywords arguments, generally, trying to pass a single pydantic models between functions
finally there is unpack and better generics
I always like the feature the most where it breaks all your dependencies 🥰
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.
What's that keyboard, and what switches? Thanks
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 :)
I love they they are just making things better instead of adding candy
after using typescript for years I just hoping there will be a better typing then this was python has actually. :D
Would you cover how to dockerize a Python app?
I use kwargs in mixins.
Tried to subscribe to your newsletter but did not get a confirmation email. Is your service down?
I use kwargs as an argument for my GraphQL resolvers!
I love python only thing it needs is ilntegration into webpages eaily
This is going in the direction of Python#
We use **kwargs in decorators
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.
Thank you for the video
You're welcome! :)
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.
Nice Scal-thon.
Did you test Mojo too?
Hi! I have error from the designguide email when open: PR_END_OF_FILE_ERROR
Anyone knows the PR for f-stringa, i have mixed reactions. This is going to invoke some chaos compared to f-strings.
@10:00 I don't understand, why do you want an infix arrow notation for lambdas? What's wrong with `lambda`?
What I mean is that I’d like to see more readable function type annotations in Python. Instead of ‘Callable[[int], bool]’ I’d like to write something like ‘(int) => bool’.
@@ArjanCodes That could be done if you could define your own custom operators, like “=>”.