My favorite f-string trick is dynamic fields. I think it's only the width and precision fields but it's a nice feature. For example: >>> width = 10 >>> pre = 2 >>> val = 3.14159 >>> f"{val:>{width}.{pre}}" ' 3.14'
So much great advice here - thank you Anjan! I'm old, and started coding in the 1970's when memory and processor speed were very limited resources. So pretty much every program became an exercise in being super efficient. e.g., using INT vs FLOAT was a big deal. So I really do appreciate the type annotation habit, and comprehension as well. As I am now working my way into some advance Python techniques, I am learning to both love and hate the extendability of it. Channels like this are like comfy blankets. ☺
There are it's called put the transcript in Gen AI and save lifetime from that lying bastard telling you maximizing watch time would be benifital to you instead of him.
10:10 comprehensions are nearly always a better choice than map and filter - you can do both operations with a cleaner syntax that will be more familiar to non-functional programmers.
From an FP perspective map and filter tend to be chained methods on classes that implement iterable. The process of chaining methods is just not the same in python when it comes to map and filter. As someone who loves FP in other languages, I'd choose comprehensions over the map function in python any day. So I agree. I barely use map or filter in python.
One of my favorite features I learned somewhat recently is the "yield from" syntax. Within a generator function, you can write "yield from my_iterable". This will then yield all values from that iterable. This can be a list, dictionary, or even another generator. It doesn't come up for me that often, but it occasionally does when working with nesting logic.
Me 2) Did nicely with pytest fixtures: had a generator method as a constructor for a dozen of similar fixtures, which "yield from" generator, with parameters and standard actions "before" and "after".
I really like your tips. I am glad that I knew around 90% of the commands and features you showed in this short video. I am still struggling with deciding when to you Classes or not, still your advice is helpful.
Thank you @ArjanCodes for this video, really useful and enjoy seeing it. Another tip (for people with anxiety like me) could be a good idea split the video in sections, maybe a section for each tip, so people can jump in directly with the tip we need to reinforcement.
You put out great content but this video feels more oriented towards beginner/intermediate programmers than what the title makes it seem. I’d love a video covering some more advanced topics!
I first turned to type annotations as a way to document and understand someone else's code base which used variable names like "x" and "y". Having type annotations and docstrings gives you almost-free API documentation.
Coming from embedded, type hints are so helpful to us with a strongly typed brain to comprehend code! I just wish they'd fix Queue subtyping so I don't have to use quotes to define what type the messages are.
Nice! I didn't know about any of those other built-ins thats handy as hell! also secret 11th tip is jupyter notebooks! I hadn't considered how great they would be as a place to collect coding tips and tricks!
f-strings are great but I have struggled with performance in the past where f-strings were slower than plain concat. In the end, and in that instance, I made my error handling more robust and went for the less safe option.
For an imutable DTOs i often use classes derived from NamedTuple instead of dataclasses. It is quite similar but has less memory footprint (if it is imortant) and has built-in as_dict method that is quite handy for serialisation
@@Naej7You still need to manually close it. The context manager only takes care of auto-committing or rolling back the transaction contained in the block... a bit counter-intuitive, but it is what it is.
I’m still trying to wrap my head around when to make something a standalone function. Like, my instinct would have been to make that calculate discount function a part of the shopping cart class.
Your instinct may feel right but is `calculate_discount` specific to an instance of that class or can be applied to any instances of that class? Ask yourself if different accounts have different discounts applied to the shopping cart: * if the answer is Yes, than it makes sense to have `calculate_discount` as a method of that class * if the answer is No, so the same discount is applied to every customer shopping cart, than it makes more sense to be a function than a method That's my 2 penny thought on the subject.
Can you make a video on overloading special methods in Python? Also, __getattr__ vs __getattribute__ would be a good topic to cover. Thx for all you hard work!
I am interested in advice about these techniques from the opposite point of view-when we should NOT use them. I sometimes see overuse of some of these techniques, such as a context manager without context to manage or list comprehension to just iterate an operation without taking returned values.
So i'm trying to get a better understanding of type hints, but your example is one reason why I get annoyed with them. The type hint Iterable indicates the function could accept any iterable, but that's not entirely true. The sum function CAN accept any iterable but the len function needs a sequence (or an object that has __len__ method). So if you pass in a generator to your function, which is definitely an iterable object, it would throw a type error.
You missed lambda functions and passing functions as parameters. Immensely useful in many situations; many of the features you show are built with them.
@ArjanCodes I have a question about the calculate_discount() method you show at 26:50 because I often find myself in a similar situation: How do you decide whether to make that a function, or make it a method of the class that it takes as argument (ShoppingCart in this example)?
Yes, that part is unclear to me as well. calculate_discount expects an object from a specific class, thus is conceptually linked to that class. Why not implementing it as a method?
I'd like to hear Arjan's comment on this as well. In this situation, I would definitely make it a method in the class. Would be great to learn from a pro why function is better.
Ask yourself if different accounts have different discounts applied to the shopping cart: * if the answer is Yes, than it makes sense to have `calculate_discount` as a method of that class * if the answer is No, so the same discount is applied to every customer's shopping cart, than it makes more sense to be a function than a method That's my 2 penny thought on the subject.
@@mac68tm Yes -> instance method, No -> class method. Or static method. I just do not clearly see an upside of a standalone tightly-couple function in such scenario.
@ I'm not sure what you mean by `tightly-couple function`. It's a generic function that calculates a discount (could be for a shopping cart, a subscription, etc.). There is no coupling as such. So if everybody gets the same discount why would I want to clutter a class with another method when it doesn't change the applied discount from instance to instance?
I don’t think encouraging nested loops in one liners is good to recommend. If you need to debug, you will have to unroll it anyways. I think if you are using python it’s not for speed, use explicitly clear code, not one liners that are harder to understand. Source: import this
Cool list! An additional tip for tip #1 (flattening the matrix): in python, it can be done even simpler, like this: flattened = list(itertools.chain.from_iterable(matrix))
👉 Try Brilliant for free for 30 days and get 20% off an annual subscription: brilliant.org/arjancodes/
My favorite f-string trick is dynamic fields. I think it's only the width and precision fields but it's a nice feature. For example:
>>> width = 10
>>> pre = 2
>>> val = 3.14159
>>> f"{val:>{width}.{pre}}"
' 3.14'
Dynamic fields are sweet. Makes stdout much prettier if you aren't using something like rich
So much great advice here - thank you Anjan! I'm old, and started coding in the 1970's when memory and processor speed were very limited resources. So pretty much every program became an exercise in being super efficient. e.g., using INT vs FLOAT was a big deal. So I really do appreciate the type annotation habit, and comprehension as well. As I am now working my way into some advance Python techniques, I am learning to both love and hate the extendability of it. Channels like this are like comfy blankets. ☺
You’re an amazing teacher and I’ve learned so much from you. Please never top producing videos. Much respect en bedankt!
Thank you!
I wish there were chapter/section marks.
There are. Expand the video description
There are it's called put the transcript in Gen AI and save lifetime from that lying bastard telling you maximizing watch time would be benifital to you instead of him.
10:10 comprehensions are nearly always a better choice than map and filter - you can do both operations with a cleaner syntax that will be more familiar to non-functional programmers.
From an FP perspective map and filter tend to be chained methods on classes that implement iterable. The process of chaining methods is just not the same in python when it comes to map and filter. As someone who loves FP in other languages, I'd choose comprehensions over the map function in python any day. So I agree. I barely use map or filter in python.
One of my favorite features I learned somewhat recently is the "yield from" syntax. Within a generator function, you can write "yield from my_iterable". This will then yield all values from that iterable. This can be a list, dictionary, or even another generator. It doesn't come up for me that often, but it occasionally does when working with nesting logic.
Me 2) Did nicely with pytest fixtures: had a generator method as a constructor for a dozen of similar fixtures, which "yield from" generator, with parameters and standard actions "before" and "after".
I really like your tips. I am glad that I knew around 90% of the commands and features you showed in this short video. I am still struggling with deciding when to you Classes or not, still your advice is helpful.
Thanks again Arjan, these tips were helpful. I would love to hear your input on dataclasses vs pydantic models.
Thank you @ArjanCodes for this video, really useful and enjoy seeing it. Another tip (for people with anxiety like me) could be a good idea split the video in sections, maybe a section for each tip, so people can jump in directly with the tip we need to reinforcement.
Hi, usually I add chapters to each video. I've noticed that something went wrong in the last few videos. If should be fixed now. :)
Thank you Arjan, your videos are always so helpful and well-crafted!
9/10 for me ;) ! Still struggling with standalone functions instead of methods. I started recently by watching to your vidéos ! Thanks for your work
From the perspective of someone who learned to program in the 1970's, before OOP, this is a remarkable statement!
You put out great content but this video feels more oriented towards beginner/intermediate programmers than what the title makes it seem. I’d love a video covering some more advanced topics!
Hear hear
I first turned to type annotations as a way to document and understand someone else's code base which used variable names like "x" and "y". Having type annotations and docstrings gives you almost-free API documentation.
Coming from embedded, type hints are so helpful to us with a strongly typed brain to comprehend code!
I just wish they'd fix Queue subtyping so I don't have to use quotes to define what type the messages are.
Nice! I didn't know about any of those other built-ins thats handy as hell! also secret 11th tip is jupyter notebooks! I hadn't considered how great they would be as a place to collect coding tips and tricks!
I like partial functions. They can simplify the code greatly if you have a function with many arguments that are reused often.
f-strings are great but I have struggled with performance in the past where f-strings were slower than plain concat. In the end, and in that instance, I made my error handling more robust and went for the less safe option.
For an imutable DTOs i often use classes derived from NamedTuple instead of dataclasses. It is quite similar but has less memory footprint (if it is imortant) and has built-in as_dict method that is quite handy for serialisation
Jupyter Notebook displays the result of executing last row in a cell, so you can just type
squares
in last row instead of
print(squares)
Good suggestion! I’m not a big notebook user, so that’s good to know 😊.
@@evgeniyevgeniy8352 lol. Just because @arjancodes is a software engineer doesn't mean he can fix the blue screen.
@@ArjanCodes You can also create code cells in python modules that execute independently using #%%.
this video refresh my memory in python
Very interesting as always. Réel réassured to use most of them
These kinds of videos are amazing, just perfect👌. So much useful and practical knowledge in 27 min.
This is a good video.
Some of the things that might be thrown around in a code review, i am able to see them in action.
Ill practice on them
Glad it was helpful!
Great video, thx! Really helped round out my jumbeld self taught understanding of python with a better framework understanding.
Great to hear!
Had no idea about the debugging syntax in f-strings, that's pretty cool!
yeah that one made me say woah!!!
13:46 The sqlite context manager doesn't actually close the database connection!
What does it do then ? When is it closed ?
@@Naej7You still need to manually close it. The context manager only takes care of auto-committing or rolling back the transaction contained in the block... a bit counter-intuitive, but it is what it is.
Nice vid - thanks for sharing
Thanks for watching!
I’m still trying to wrap my head around when to make something a standalone function. Like, my instinct would have been to make that calculate discount function a part of the shopping cart class.
Your instinct may feel right but is `calculate_discount` specific to an instance of that class or can be applied to any instances of that class? Ask yourself if different accounts have different discounts applied to the shopping cart:
* if the answer is Yes, than it makes sense to have `calculate_discount` as a method of that class
* if the answer is No, so the same discount is applied to every customer shopping cart, than it makes more sense to be a function than a method
That's my 2 penny thought on the subject.
Can you make a video on overloading special methods in Python?
Also, __getattr__ vs __getattribute__ would be a good topic to cover.
Thx for all you hard work!
usefull tips. Thx Arjan.
Glad it was helpful!
18:35 Using len(numbers) means you need Sized not Iterable.
Because `sum` requires `Iterable`?
@@chatcharinsangbutsarakum5963 sum requires Iterable, len requires Sized, so the variable should be annotated as Collection.
Ah yes, it requires Sized AND Iterable = Collection
I use f strings with sql. But only for read only queries and to dynamically pass arguments like dates to queries.
Thank you, great video!
You are welcome!
Can you link to those notebooks? Seems like a fantastic quick reference! Awesome video
Hi, the link with the code is in the description :)
@ Thank you!!!
Love the thumbnail, Arjan 😂😂😂
know bulit-in funcions is a good advice for any language
Thanks for the video
Is it just me or did Arjan just pronounced Repository funny?
PS: I love watching your videos.
Well well well. He didn't use click baits. The title should have been learn python in 5 minutes 😂
@4:30 Right there! I knew it! You're a time travelling Pythonista 😂😢
I am interested in advice about these techniques from the opposite point of view-when we should NOT use them.
I sometimes see overuse of some of these techniques, such as a context manager without context to manage or list comprehension to just iterate an operation without taking returned values.
So i'm trying to get a better understanding of type hints, but your example is one reason why I get annoyed with them. The type hint Iterable indicates the function could accept any iterable, but that's not entirely true. The sum function CAN accept any iterable but the len function needs a sequence (or an object that has __len__ method). So if you pass in a generator to your function, which is definitely an iterable object, it would throw a type error.
You summed up my python knowledge in a video. And here i thought i could be a software developer some day😅
Ooo Arjan using Jupyter now finally ❤
You missed lambda functions and passing functions as parameters. Immensely useful in many situations; many of the features you show are built with them.
@ArjanCodes I have a question about the calculate_discount() method you show at 26:50 because I often find myself in a similar situation:
How do you decide whether to make that a function, or make it a method of the class that it takes as argument (ShoppingCart in this example)?
Yes, that part is unclear to me as well. calculate_discount expects an object from a specific class, thus is conceptually linked to that class. Why not implementing it as a method?
I'd like to hear Arjan's comment on this as well. In this situation, I would definitely make it a method in the class. Would be great to learn from a pro why function is better.
Ask yourself if different accounts have different discounts applied to the shopping cart:
* if the answer is Yes, than it makes sense to have `calculate_discount` as a method of that class
* if the answer is No, so the same discount is applied to every customer's shopping cart, than it makes more sense to be a function than a method
That's my 2 penny thought on the subject.
@@mac68tm Yes -> instance method, No -> class method. Or static method. I just do not clearly see an upside of a standalone tightly-couple function in such scenario.
@ I'm not sure what you mean by `tightly-couple function`. It's a generic function that calculates a discount (could be for a shopping cart, a subscription, etc.). There is no coupling as such. So if everybody gets the same discount why would I want to clutter a class with another method when it doesn't change the applied discount from instance to instance?
map and filter should not be used specially in cases you showed, that's what comprehension is for
Just a thought make how to write a more advanced software.
I don’t think encouraging nested loops in one liners is good to recommend. If you need to debug, you will have to unroll it anyways.
I think if you are using python it’s not for speed, use explicitly clear code, not one liners that are harder to understand.
Source: import this
Python creators:
Oh let’s create language without types
Python developers after 20 years:
😂
Exactly!
Let's have a language which isn't C/C++/add your own to the list .... "ooh, look, it's almost the same as ...!"
even though it's dynamically typed, it was always strongly typed
You missed documentation....
Not entirely. Type hints was covered. Docstrings were not. But yeah. I'd have loved to see something on docstrings
Cool list! An additional tip for tip #1 (flattening the matrix): in python, it can be done even simpler, like this: flattened = list(itertools.chain.from_iterable(matrix))
Actually great Python developers stays away from comprehensions, they are killer of the readability.
Actually, banana is as long as cherry 😊
Tip #1: learn Go.
darn no table of contents ;()
The content feels too basic, while quite slow. Lately I have the feeling topics are explained quite shallowly
the best thing experienced python developers can do to become better at coding in python is get comfortable coding in rust and using it's idioms
or a LISP variant like scheme - correctly applying functional idioms will up your python game
Python zipped
IMHO all these are begginer's topic