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.
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. ☺
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.
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!
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".
@@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 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.
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.
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 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.
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!
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
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.
@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.
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.
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.
You missed lambda functions and passing functions as parameters. Immensely useful in many situations; many of the features you show are built with them.
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
👉 Try Brilliant for free for 30 days and get 20% off an annual subscription: brilliant.org/arjancodes/
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.
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. ☺
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.
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!
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".
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.
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.
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.
Thank you Arjan, your videos are always so helpful and well-crafted!
Thanks again Arjan, these tips were helpful. I would love to hear your input on dataclasses vs pydantic models.
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!
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 #%%.
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.
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!
Very interesting as always. Réel réassured to use most of them
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
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!
These kinds of videos are amazing, just perfect👌. So much useful and practical knowledge in 27 min.
Nice vid - thanks for sharing
Thanks for watching!
usefull tips. Thx Arjan.
Glad it was helpful!
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!
Had no idea about the debugging syntax in f-strings, that's pretty cool!
yeah that one made me say woah!!!
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
Great video, thx! Really helped round out my jumbeld self taught understanding of python with a better framework understanding.
Great to hear!
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 :)
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.
I use f strings with sql. But only for read only queries and to dynamically pass arguments like dates to queries.
Thanks for the video
know bulit-in funcions is a good advice for any language
@4:30 Right there! I knew it! You're a time travelling Pythonista 😂😢
Love the thumbnail, Arjan 😂😂😂
Well well well. He didn't use click baits. The title should have been learn python in 5 minutes 😂
@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.
Is it just me or did Arjan just pronounced Repository funny?
PS: I love watching your videos.
Ooo Arjan using Jupyter now finally ❤
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.
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.
You missed lambda functions and passing functions as parameters. Immensely useful in many situations; many of the features you show are built with them.
You summed up my python knowledge in a video. And here i thought i could be a software developer some day😅
You missed documentation....
Not entirely. Type hints was covered. Docstrings were not. But yeah. I'd have loved to see something on docstrings
Just a thought make how to write a more advanced software.
map and filter should not be used specially in cases you showed, that's what comprehension is for
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
Actually, banana is as long as cherry 😊
darn no table of contents ;()
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
Tip #1: learn Go.
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