Or better yet, casefold to deal with some non-ascii characters. Possibly unicode normalization as well for stuff like combining characters. Text is hard.
@@DrDeuteron f-strings (or "formatted string literals") were added in *Python 3.6* , released end of 2016. The type converter !r to call repr() was there from the start, as proposed in PEP498 - along with !a for ascii(), and the rarely useful !s for str(). I have never thought about its pronounciation before, but I'm definitely going to use "banger" from now on. :D
Wow I have been sitting on a use-case for union, intersection and subtraction methods for the past year but never knew the syntax could be so nice with these dunder methods (__or__ and friends). Thank you!
one common pythonic thing is, repr(instance) should return a string so that: >>>instance == eval(repr(instance)) is True, so something _like_: return f"{type(self).___name__}(}" + ", ".join(f'{k}={v}' for k, v in self.___dict___.items()) + ")" Also: note that these dunder methods are _strongly typed_ and MUST return a str. You can also use the "dunder module" static class attribute to assist.
Good video, but Pyright suggest you to use `self.__class__` when instating the same class instead of using `ClassName(...)`. So in the `__or__` method you should instead return `self.__class__(...)`, and basically in every method that returns a new instance of Self. Hope it helps!
Personally, I would require that the name representation was always lowercase anyway, even on initialization. As for fun with operators, I like to overload / on strings in languages that don't already do so to act as the split operation. Say you've got a string that's s = "foo,bar,baz,luhrmann"; then a = s / ','; would yield an array of strings containing ["foo", "bar", "baz", "luhrmann"].
From my Java days, one rule I’ve always followed is: “Always define toString!” In Python, it’s: “Always define dunder str and repr!” It should be one of the first things you do when you write a class. (FWIW, I typically use dunder repr to return a JSON-like string, but that’s just me.)
One rule of thumb I try to follow: eval(repr(my_object)) == my_object So repr() should give the code to construct the same (or at least an equivalent) object. This is what e.g. dataclass or namedtuple do by default. Use dunder attributes for the class name, to avoid mistakes when renaming classes or copying code: def __repr__(self): return f"{__class__.__qualname__}(x={self.x!r}, ...)" If this one-liner gets too cluttered, put the class name in a helper variable cls and use ', '.join() or linebreak-separated strings within parentheses for the constructor args/attributes. Now that I think of it, this _could_ probably be automated into a class wrapper using introspection to get the constructor signature... I guess you could use name instead of qualname, b/c AFAIU it only makes a difference with nested classes, which IMHO should make anyone pause and question their choices, anyway. :^)
@@nibblrrr7124 Yeah, that's nice! The JSON string I usually emit is something like: {classname:{attributes and values}} Which does allow reconstruction of the object from the JSON and is fairly readable when debugging.
I'm just thankful I finally know what these methods are called. Every few months or so, I come up with an idea with classes, and I need to scour the internet 15min for the python documentation on all these methods.
Like this and I agree with @xinaesthetic about the input should be also be converted. But you should use 'casefold()' instead of 'lower()', in these examples it might not matter but it should always be used when a comparison is made. Keep up with the videos.
(@3:30) This raises several questions: 1) wouldn’t this implementation of the __eq__ dunder method make it compare the addresses of the two dictionaries? 2) can you change the value of the instance’s values through the dictionary, with the __dict__ dunder method? That is, if you change the value associated with the key, ‘grams’, will it change the instance’s ‘grams’ property to that new value, or only the dictionary?
1) No, because == on the default collections (dict, list, set, ...) compares their contents by value. Use the *is* operator for checking for identity, i.e. whether they're literally referring to the same object in memory. 2) Yes, at least for normal user-defined classes (AFAIU classes can use slots instead of a class dict; also @property attributes might be an issue). Please don't, as it's hella confusing. But as Raymond Hettinger puts it: "Python is a language for consenting adults." (See also: Why are there no private methods?)
Great video, thanks One extra thing which I learned was that you can do filter with list comprehension. Until now I did filter + lambda (which basically was shooting myself in the leg because of whacky annotations).Thanks again
Thanks alot for the quality content you provide! One question: what is the extension that shows you classes and methods usages throughout code? When coding rust that thing is auto enabled (thanks to the compiler features I guess)… thanks in advance :)
I'm not a fan of most dunder methods (specifically for operators) most of the time since they drastically reduce understanding of the code. For example at 7:33, to try to guess in advance what will be displayed, we must: - know that the syntax "|" is related to the dunder method "__or__" - read the documentation/source code A function/method/classmethod anything else actually with an explicit name (like "combine") and a good docstring would be so much more readable
Also it's weird to have "__or__" method that's not commutative. I would not expect `a | b == b | a` to return False and here it will. Edit: Fixed based on @mudi2000a comment.
certain functionality is fine for dunder methods, basically where they are self explainatory, __str__ is a simple expectation, __eq__ aswell an example where __add__ and other mathmatical operators is fine to overload is for example a Point class which just represents multiple numbers basically use dunder methods where its extremely clear what it does under the hood by just knowing what the class represents without looking at the actual implementation
I disagree with your first point (that it's not obvious that the "|" operator calls "__or__"), as that is just being familiar with Python. That ship has sailed with "__init__", hasn't it? (The fact that we have come to accept how messed-up and confusing constructor syntax in C++/Java is another topic...) However, I do agree that unless the meaning is obvious - like the interfaces from collections.abc, or behaving similarly to builtin datatypes ("+" for concatenation, like with str or list) - or well-documented and signposted, you're probably better off using regular methods and make the users write more explicit calls.
Hi, To combine dictionaries, sets, classes, etc... should not be an and operator? Something like this: d1 & d2 Instead of d1 | d2 And the magic method would be __and__ Thanks.
Type hinting is just for your code editor to flag you when you try to use a string method on the results of a function you hinted should be an integer. If you don't fix it, the interpreter will still try to run it. Sometimes it will fail immediately, like my example, or be buggy in subtle ways where the operations overlap.
Nice tutorial, except for the part where you did basket: Basket = (fruit = fruit), that was the equivalent of calling a string just "string" and it really confused me
I just imagine an Easter egg in all of their code where if you add 'banana' to the end of an input, it will show an ASCII art banana for 5 seconds before moving on to the actual functionality of the code.
I think Self in the __eq__ is not correct. In general, we can compare with any object, just need to return False if the other object is not the instance of the class
begone javascript sympathizer. although python does not enforce it, you should not be using the == operator on objects of different types. if you want to compare objects and but are not sure the type, your problems are much deeper
(1) It gives me an error when I annotate 'other' with 'Fruit' or 'Self' at or and repr Dunder Methods (e.g. def __or__(self, other: Fruit) -> Fruit:)... it says „NameError: name 'Fruit' is not defined”. It works only with 'object' (def __or__(self, other: object) -> object:). And if I write 'object', PyCharm warns me at 'combined: Fruit = apple | orange | banana' -> expected object type Fruit :)) Any thoughts? Thanks! and (2) If you want to use __format__ and __str__ / __repr__ at the same time, it won't work. It raises the error from __fomat__ match _: ValueError: Unknown format specifier... You will have to specify the desc match to work - print(f'str: {fruit:desc}') P.S. I found your videos recently and it's a pleasure watching them. Keep it up! ❤
It's a type annotation. I was just playing around with the interpreter and it doesn't prevent me from assigning other types to a variable, so I'm not really sure what the point is other than to provide documentation for anyone reading the source code, but if you just call a constructor like that it's redundant for seemingly no reason. Maybe someone more knowledgeable about Python can correct us both, but for what it's worth, I wouldn't bother unless the declaration is separate from your first initialization of a variable.
It doesn't prevent you of assigning anything else but it will show you a warning for it. Also it enables your IDE to include the appropriate methods that are associated with that type in the auto-complete list.
@@cookie_space I don't use an IDE. It's either vim or the python3 interpreter from the command line whenever I use it. The only time I've discovered that it actually errs is when used for parameter typing for functions, but I guess warnings will have to suffice for other uses. It would be nice if Python would use it to prevent assignment of unequal types, but in a language that treats variables as *really* variable, that's probably asking too much.
The syntactically correct way to create a variable : f1 = Fruit(...) So the "f1: Fruit = Fruit(...)." is incorrect therefore I do not understand how the "f1: " part works here as "alias".
😅With regard to *__eq__* "double underscore" method (hence the name "dunder") you really should mention that it compares two OBJECTS here, not CLASSES... For obvious reasons objects are instances of classes, not "aliases" like you have said in the first part 😉 That said, this material is still worthwhile. But my university ears just hurt when such mistakes are done. Best regards and thanks!
Oof, da! I would _never_ redefine get _item_ to return a list. For that, add another method with a better name. And you need to .lower() the item, too!
Do you mean the annotations? Like: Twopi : float = three: int + 0.1 : float + 41: int / pow(10: int, 3: int) ? Yes. And telling ppl dunder init returns None, I just can’t. Of dunder str returns str. Same for int, float, complex, etc….
@@MarianoBustos-i1f oh. Yes, I turn those off all the time, esp when I'm writing a line that depends the prior line... ...it opens up and hides what I want to build off of and tells me a bunch of stuff I don't need to know.
One minor point: to make the search case-insensitive, you should really lower the input as well.
Fair point!
@@Indently great post, though, thanks.
@@Indently Thanks for every thing❤
@@Indently please tutorial full all method
Or better yet, casefold to deal with some non-ascii characters. Possibly unicode normalization as well for stuff like combining characters. Text is hard.
F-strings can also show the repr of an object using the !r specifier: f"{item!r}"
G-strings can show a lot too.
@@davidmurphy563 wtheckk😂
Since which version? And is it pronounced bang r? Does anyone remember back quotes being assign to repr?
@@DrDeuteron f-strings (or "formatted string literals") were added in *Python 3.6* , released end of 2016.
The type converter !r to call repr() was there from the start, as proposed in PEP498 - along with !a for ascii(), and the rarely useful !s for str().
I have never thought about its pronounciation before, but I'm definitely going to use "banger" from now on. :D
@@nibblrrr7124 don't forget unicode() from 2x, but those backward quotes `foo` -> repr(foo) were weird. Though emacs knew about them,
Man! I had no idea Python could do all of this. So glad the algo picked this. Thanks for the info!
Your content is one of the best, I would never have imagined that __str__ was different than __repr__
1500g! What a big banana you have 😂
Wow I have been sitting on a use-case for union, intersection and subtraction methods for the past year but never knew the syntax could be so nice with these dunder methods (__or__ and friends). Thank you!
one common pythonic thing is, repr(instance) should return a string so that:
>>>instance == eval(repr(instance))
is True, so something _like_:
return f"{type(self).___name__}(}" + ", ".join(f'{k}={v}' for k, v in self.___dict___.items()) + ")"
Also: note that these dunder methods are _strongly typed_ and MUST return a str.
You can also use the "dunder module" static class attribute to assist.
Good video, but Pyright suggest you to use `self.__class__` when instating the same class instead of using `ClassName(...)`.
So in the `__or__` method you should instead return `self.__class__(...)`, and basically in every method that returns a new instance of Self. Hope it helps!
Doesn’t type(self) work too?
Personally, I would require that the name representation was always lowercase anyway, even on initialization. As for fun with operators, I like to overload / on strings in languages that don't already do so to act as the split operation. Say you've got a string that's s = "foo,bar,baz,luhrmann"; then a = s / ','; would yield an array of strings containing ["foo", "bar", "baz", "luhrmann"].
Nice complement of multiplying strings! I might borrow that idea.
Thank you, very intuitive and precise presentation!
Two and a half kilo Apple! I did dream about such a thing when I was a kid, familiar with scrumping.
From my Java days, one rule I’ve always followed is: “Always define toString!” In Python, it’s: “Always define dunder str and repr!” It should be one of the first things you do when you write a class. (FWIW, I typically use dunder repr to return a JSON-like string, but that’s just me.)
One rule of thumb I try to follow: eval(repr(my_object)) == my_object
So repr() should give the code to construct the same (or at least an equivalent) object. This is what e.g. dataclass or namedtuple do by default.
Use dunder attributes for the class name, to avoid mistakes when renaming classes or copying code:
def __repr__(self):
return f"{__class__.__qualname__}(x={self.x!r}, ...)"
If this one-liner gets too cluttered, put the class name in a helper variable cls and use ', '.join() or linebreak-separated strings within parentheses for the constructor args/attributes. Now that I think of it, this _could_ probably be automated into a class wrapper using introspection to get the constructor signature...
I guess you could use name instead of qualname, b/c AFAIU it only makes a difference with nested classes, which IMHO should make anyone pause and question their choices, anyway. :^)
@@nibblrrr7124 Yeah, that's nice! The JSON string I usually emit is something like:
{classname:{attributes and values}}
Which does allow reconstruction of the object from the JSON and is fairly readable when debugging.
If you use it for debugging only, __repr__ is enough, it will be automatically called also instead of __str__ if __str__ does not exist.
I feel like I learned more than expected, which is always good.
Awesome video! Your explanation is really good! Thanks a lot!
Man this is crazy helpful, this is some advanced stuff
I'm just thankful I finally know what these methods are called. Every few months or so, I come up with an idea with classes, and I need to scour the internet 15min for the python documentation on all these methods.
If you thought that was tough, imagine trying to do the same thing 15 to 20 years ago....
you do it so useful for all of us. I know what you are one of the best python developer.
Like this and I agree with @xinaesthetic about the input should be also be converted. But you should use 'casefold()' instead of 'lower()', in these examples it might not matter but it should always be used when a comparison is made. Keep up with the videos.
(@3:30) This raises several questions:
1) wouldn’t this implementation of the __eq__ dunder method make it compare the addresses of the two dictionaries?
2) can you change the value of the instance’s values through the dictionary, with the __dict__ dunder method? That is, if you change the value associated with the key, ‘grams’, will it change the instance’s ‘grams’ property to that new value, or only the dictionary?
What’s great about python is that you can test it in an interpreter about as fast as you can answer the question.
1) No, because == on the default collections (dict, list, set, ...) compares their contents by value. Use the *is* operator for checking for identity, i.e. whether they're literally referring to the same object in memory.
2) Yes, at least for normal user-defined classes (AFAIU classes can use slots instead of a class dict; also @property attributes might be an issue). Please don't, as it's hella confusing. But as Raymond Hettinger puts it: "Python is a language for consenting adults." (See also: Why are there no private methods?)
Great video, thanks
One extra thing which I learned was that you can do filter with list comprehension. Until now I did filter + lambda (which basically was shooting myself in the leg because of whacky annotations).Thanks again
Another cool video, thanks! Hope to see more ___dunders__ :)
Great video!
Heya, just wanted to ask what theme you're using. Still fairly new to Python and loving the content so far
another great video thumbs up!!
Thanks alot for the quality content you provide! One question: what is the extension that shows you classes and methods usages throughout code? When coding rust that thing is auto enabled (thanks to the compiler features I guess)… thanks in advance :)
really knowledgeful
This is really an excellent channel on Python like "techie talkee"
I love the Bananas, but i have to learn so much other thing about Apples🤣
Great Tutorials, thanks!
Nice. Keep it up. 💯
You could also define the dunder method __iter__ for class Basket to make it iterable as well
Great thanks
thanks a lot
I'm not a fan of most dunder methods (specifically for operators) most of the time since they drastically reduce understanding of the code. For example at 7:33, to try to guess in advance what will be displayed, we must:
- know that the syntax "|" is related to the dunder method "__or__"
- read the documentation/source code
A function/method/classmethod anything else actually with an explicit name (like "combine") and a good docstring would be so much more readable
For me, I love overloading operators, until I want to see where something happens in the code.
Also it's weird to have "__or__" method that's not commutative. I would not expect `a | b == b | a` to return False and here it will.
Edit: Fixed based on @mudi2000a comment.
certain functionality is fine for dunder methods, basically where they are self explainatory, __str__ is a simple expectation, __eq__ aswell
an example where __add__ and other mathmatical operators is fine to overload is for example a Point class which just represents multiple numbers
basically use dunder methods where its extremely clear what it does under the hood by just knowing what the class represents without looking at the actual implementation
I disagree with your first point (that it's not obvious that the "|" operator calls "__or__"), as that is just being familiar with Python. That ship has sailed with "__init__", hasn't it? (The fact that we have come to accept how messed-up and confusing constructor syntax in C++/Java is another topic...)
However, I do agree that unless the meaning is obvious - like the interfaces from collections.abc, or behaving similarly to builtin datatypes ("+" for concatenation, like with str or list) - or well-documented and signposted, you're probably better off using regular methods and make the users write more explicit calls.
@@Raugturi You mean commutative.
that was awesome.
Very nice … can you please do videos on testing
If I do order with subscriptions, this channel stays. Great kind of practical tutorial 🔥
The __repr line 11, you can just do return f ‘{value =}’ instead of f ‘value = {value }’ . Also, for the __get_item lines 28 29
9:11 my grandmother is a developer. She can read both.
The first one takes me back to Intro to JAVA in College...having to create an equals method for every class.
Hi,
To combine dictionaries, sets, classes, etc... should not be an and operator?
Something like this: d1 & d2
Instead of d1 | d2
And the magic method would be __and__
Thanks.
Great video :D btw you have some big bananas in there!
Shouldn't you use Fruit instead of Self, in order to view correctly the required type during comparison in method 1?
I'm new to python, is there any version requirements or restrictions to use these Dunder methods?
Don't think so (post python2 i presume?)
@@landsgevaer yes, I use 3.10 however I need compatibility to 3.7 and 3.8
Didn't know we can specify the return type in Python, thanks
And you can return a different type regardless of the specification... 😄
@@sarimbinwaseem hmmm interesting
Every thing is a first class object in python
Type hinting is just for your code editor to flag you when you try to use a string method on the results of a function you hinted should be an integer. If you don't fix it, the interpreter will still try to run it. Sometimes it will fail immediately, like my example, or be buggy in subtle ways where the operations overlap.
What's your microphone brand/model? It sounds amazing!
It's the Røde NT USB
@@Indently merci
Nice tutorial, except for the part where you did
basket: Basket = (fruit = fruit), that was the equivalent of calling a string just "string" and it really confused me
It's important to prioritize your fruits 🙂
I just imagine an Easter egg in all of their code where if you add 'banana' to the end of an input, it will show an ASCII art banana for 5 seconds before moving on to the actual functionality of the code.
Where can i Find a comprehensive list of all python dunder methods?
Python document webpage
Google "list of all dunder methods in python" disappointed you?
I think Self in the __eq__ is not correct. In general, we can compare with any object, just need to return False if the other object is not the instance of the class
Luckily type hints don’t matter
begone javascript sympathizer. although python does not enforce it, you should not be using the == operator on objects of different types. if you want to compare objects and but are not sure the type, your problems are much deeper
I'm learning English. I'd like to know where are you or where come from your accent. Please.
Thanks a lot.
Sounds German(ic).
Thank you.
(1) It gives me an error when I annotate 'other' with 'Fruit' or 'Self' at or and repr Dunder Methods (e.g. def __or__(self, other: Fruit) -> Fruit:)... it says „NameError: name 'Fruit' is not defined”. It works only with 'object' (def __or__(self, other: object) -> object:).
And if I write 'object', PyCharm warns me at 'combined: Fruit = apple | orange | banana' -> expected object type Fruit :))
Any thoughts? Thanks!
and (2) If you want to use __format__ and __str__ / __repr__ at the same time, it won't work. It raises the error from __fomat__ match _: ValueError: Unknown format specifier... You will have to specify the desc match to work - print(f'str: {fruit:desc}')
P.S. I found your videos recently and it's a pleasure watching them. Keep it up! ❤
Without checking:
from __future__ import annotations
and/or
from typing import Self
What is the name of that assigment style with colon?
apple: Fruit = Fruit(name="", grams=)
What's different vs.
apple = Fruit(....)?
It's a type annotation. I was just playing around with the interpreter and it doesn't prevent me from assigning other types to a variable, so I'm not really sure what the point is other than to provide documentation for anyone reading the source code, but if you just call a constructor like that it's redundant for seemingly no reason. Maybe someone more knowledgeable about Python can correct us both, but for what it's worth, I wouldn't bother unless the declaration is separate from your first initialization of a variable.
@@anon_y_mousse oh got it! Yeah makes sense!
It doesn't prevent you of assigning anything else but it will show you a warning for it.
Also it enables your IDE to include the appropriate methods that are associated with that type in the auto-complete list.
@@cookie_space I don't use an IDE. It's either vim or the python3 interpreter from the command line whenever I use it. The only time I've discovered that it actually errs is when used for parameter typing for functions, but I guess warnings will have to suffice for other uses. It would be nice if Python would use it to prevent assignment of unequal types, but in a language that treats variables as *really* variable, that's probably asking too much.
4:30 when were these keywords added?😂
Is there a 'head' method? ;)
No, but there is a mifflin
Pandas dataframes have a head method; not dunder though...
The syntactically correct way to create a variable : f1 = Fruit(...) So the "f1: Fruit = Fruit(...)." is incorrect therefore I do not understand how the "f1: " part works here as "alias".
What if I do apple | apple ?
Fruit(name="apple & apple", grams=2000.0)
the way he implemented it (I don't remember the weight).
operator overloading
I get this error on the first example, "NameError: name 'Self' is not defined".
Did you include the first line: from typing import Self
Because I'm using Python 3.10, I had to include: from typing_extensions import Self
@@johnraz99 totally missed it. Thanks!
That was one big banana. :)
😅With regard to *__eq__* "double underscore" method (hence the name "dunder") you really should mention that it compares two OBJECTS here, not CLASSES...
For obvious reasons objects are instances of classes, not "aliases" like you have said in the first part 😉
That said, this material is still worthwhile. But my university ears just hurt when such mistakes are done. Best regards and thanks!
Oof, da! I would _never_ redefine get _item_ to return a list. For that, add another method with a better name. And you need to .lower() the item, too!
when i reach the __getitem__ section, i only think
"fruit for fruit inside fruit, idk man, can i just eat all of it???"
Did you mean to use ‘fruit.name.lower() == item.lower()’? I’m just checking because it sounded like you meant to do that lol
Yes, as someone else pointed, I only did half the job there xD
I love you infinite percent
its dunder getitem, not get_item.
Thank you, I have updated both the thumbnail and description!
🐟
f ‘{value =}’
__prepare__
Discord gang
your way of writing variables with type hinting really confused me
🍌
third
Second
Man, those tooltips are extremely annoying. They distract me a lot from reading the code as you type it.
Do you mean the annotations? Like:
Twopi : float = three: int + 0.1 : float + 41: int / pow(10: int, 3: int)
?
Yes. And telling ppl dunder init returns None, I just can’t. Of dunder str returns str. Same for int, float, complex, etc….
@@DrDeuteron No. I just meant the IDE tooltips
@@MarianoBustos-i1f oh. Yes, I turn those off all the time, esp when I'm writing a line that depends the prior line... ...it opens up and hides what I want to build off of and tells me a bunch of stuff I don't need to know.
first
too confusing
Sorry your have to be more academic
you*
I do not recomend any python user see this video. Several things of python 1 (still are teached and mixed with Cobol or other grosser language anyway…