Note that implementing __eq__ will remove the hashability of your class instances by default, which is PROBABLY fine.
If you're making immutable objects that need to be valid dictionary keys or set items, you probably don't need to care about hashability.
pym.dev/what-are-has...
After __init__ and __repr__, the next dunder method to consider implementing is __eq__.
The __eq__ method controls what it means for your object to be "equal" to another object (with ==).
pym.dev/overloading-...
Python Tip #66 (of 365):
Consider implementing __eq__ on every class you make 🧵
Tips 63 and 64 were about always implementing __init__ and __repr__ methods on your classes.
You don't ALWAYS need a __eq__ method, but you should seriously consider one.
#Python #DailyPythonTip
The people standing behind a booth with lots of swag for PyCon US SoCal Python, and PyBeach.
The Python Community Megabooth is just about ready at #scale23x. We're here with 🐍 @pycon.us and🏄 Socal Python at booth 235, come by and say hi!
But most objects don't implement __str__.
It MIGHT make sense for your class instances to have 2 different string representations, but most classes don't.
It's okay to leave __str__ unimplemented.
But ALWAYS implement __repr__ (see tip #64).
Python's pathlib.Path class implements 2 different string representations:
>>> import pathlib
>>> p = pathlib.Path()
>>> repr(p)
"PosixPath('.')"
>>> str(p)
'.'
So does datetime.date:
>>> from datetime import date
>>> d = date(1999, 12, 31)
>>> repr(d)
'date(1999, 12, 31)'
>>> str(d)
'1999-12-31'
Classes that don't implement __str__ will end up with the str representation falling back to repr.
Lists, tuples, and most Python objects only implement __repr__, so their 2 string representations are equivalent:
>>> p = (1, 2)
>>> repr(p)
'(1, 2)'
>>> str(p)
'(1, 2)'
Python Tip #65 (of 365):
Rarely define a __str__ method 🧵
A __str__ method controls the human-readable string representation of your class instances.
You may think you need __str__, but most classes really don't need this method and your class probably doesn't either.
#Python #DailyPythonTip
There is one exception to this rule: if you're making an object that has no sensible state to display, you could leave __repr__ undefined.
Python tends to take this approach with its many iterator objects:
>>> enumerate([])
<enumerate object at 0x76dd66978fe0>
For every class you make, either:
1. create a __repr__ method
2. use a tool (like the dataclass decorator) to create a __repr__ method
3. inherit from a class that has a useful __repr__ method method.
Python Tip #64 (of 365):
Ensure your classes all have a sensible __repr__ method 🧵
A __repr__ method controls the default string representation of your class instances.
Pretty much every object should have a nice string representation.
#Python #DailyPythonTip
If your class doesn't have an initializer method and it doesn't inherit from another class, seriously consider whether you need a class.
Classes maintain state and state needs initialization. Also see the related tip #62 on avoiding conditionally present attributes.
pym.dev/what-is-init/
For every class you make, either:
1. create a __init__ method
2. use a tool (like the dataclass decorator) to create a __init__ method
3. inherit from a class that has a useful __init__ method method.
Python Tip #63 (of 365):
Every class should have an initializer 🧵
If your class doesn't have an initializer method, it could probably be a module instead of a class.
#Python #DailyPythonTip
Generator expressions can be used as an "invent your own comprehension" tool.
They don't *actually* invent a custom comprehension, but they can be used for effectively that purpose.
I just published a new article on this idea:
pym.dev/custom-compr...
I rarely remember my dreams, but sast night I dreamed that I went to a baseball game with Mark Evan Jackson and someone named Glenn (not Jason Siegel).
You may SOMETIMES see conditionally present attributes (like __wrapped__ on functions that have been decorated) but it's unusual.
Avoid creating conditionally present attributes.
If an attribute might not always be needed, give it a default state that sensibly represents emptiness (like None).
If your class creates objects that might have a specific attribute but also might NOT have that attribute, you'll need to use hasattr to check for the presence of the attribute and/or getattr to look up the attribute.
That can make for confusing code.
Deleting an attribute or a variable name is an odd thing to do.
Creating an object that sometimes has a specific attribute and sometimes doesn't is ALSO odd.
Python Tip #62 (of 365):
Avoid conditionally present attributes 🧵
Python's "del" statement is pretty much ONLY used to delete dictionary keys (or list indexes).
You'll probably never see "del" used to delete an attribute. There's a reason for that.
#Python #DailyPythonTip
"So we should be careful when defining our default argument value, that we don't call functions that could return different values depending on when they're called."
Read more 👉 https://trey.io/rbi1o4
#Python
If you find yourself passing the same object or group of objects into many different functions, consider whether it might be time to create a class & methods.
Classes can certainly be overused, especially by folks moving from very class-oriented languages like Java.
But they can ALSO be underused.
I find this more readable:
server = IMAPChecker(host)
server.authenticate(name, password)
messages = [
server.get_message(u)
for u in server.get_message_uids()
]
server.quit()
It's clear that those method calls are meant to operate on the server object. Not so with the function calls.
Python Tip #61 (of 365):
When passing the same object(s) to different functions, consider a class. 🧵
Consider this code:
server = get_connection(host, name, password)
messages = [
get_message(server, u)
for u in get_message_uids(server)
]
close_connection(server)
#Python #DailyPythonTip
New screencast on when it makes sense to use a class in #Python
As far as I can tell, uv doesn't have a command to automatically upgrade a pinned version of a package to the latest version.
What do you do to work around this issue?
#Python #uv
But if you do use an inline "if" expression in a comprehension, at least wrap the inline "if" in parentheses:
sanitized = [
(n if n > 0 else 0)
for n in counts
]
I find that MUCH more readable!
Comprehensions don't have "else", but an inline "if" can make them look like they do.
I find this a bit more readable:
sanitized = [
n if n > 0 else 0
for n in counts
]
But that could still be misunderstood.
I'd recommend avoiding "if" expressions in comprehensions whenever there might be a simpler way to write your code.
Python Tip #60 (of 365):
Be cautious of "if" expressions in comprehensions 🧵
An "if" expression in a "for" loop can look confusing:
sanitized = [n if n > 0 else 0 for n in counts]
That "else" isn't part of the comprehension. It's just inline "if" expression.
#Python #DailyPythonTip
This is one of the most thoughtful videos on AI concerns I've seen.
@hankgreen.bsky.social lays out his concerns in 30 minutes and then interviews @author-calnewport.bsky.social for an hour.
