βQuacking is quacking, and when it comes to iterables, looping is looping.β
Read more π https://pym.dev/all-iteration-is-the-same/
#Python & #Django educator & team trainer
I help folks sharpen their Python skills with https://PythonMorsels.comππͺ
Also: ostrovegan, sentientist, YIMBY, and I think economics is highly underrated. I don't post about any of those topics very often.
he/him
| π My Weekly Newsletter | https://pym.dev/newsletter |
| π Python Exercises | https://www.pythonmorsels.com |
| πΊ YouTube | https://www.youtube.com/@PythonMorsels |
| πΈ Personal Blog | https://treyhunner.com |
βQuacking is quacking, and when it comes to iterables, looping is looping.β
Read more π https://pym.dev/all-iteration-is-the-same/
So a list-of-lists is really a list of references to lists.
The shorthand of thinking of one object as "contained" in another is often helpful, but there is no real "containment" of one object within another in Python.
Most Python gotchas are related to EITHER the pointer nature of variables OR the pointer nature of objects.
So thinking in terms of pointers, for both VARIABLES and OBJECTS will help you avoid most gotchas before the getcha.
π§΅ (2/2)
Python Tip #86 (of 365):
Acknowledge that containment is (sort of) a lie.
Data structures in Python don't contain data...
Well, at least data structures don't contain objects.
Variables don't contain objects: they just point to them.
Likewise, data structures, and all other objects ALSO don't contain objects.
Data structures only POINT to objects.
π§΅ (1/2)
I do believe that people can change, and that there can (and should) be a path back to good standing in a community.
But that path needs to involve taking ownership of the harm they caused β even if, heck especially if, theyβre no longer a person who would do those things. And they need to at least attempt to make amends in some way.
Without these things, Iβm not going to be able to assume good intentions of someone trying to come back.
Python Tip #85 (of 365):
Think of variables as pointers.
When explaining your code in Python, be sure to disambiguate between the 2 types of change (assignments and mutations).
"Changing" a variable just changes which object that variable points to.
"Changing" an object mutates that object. Every reference to that object will "see" the change.
Many Python gotchas derive from the pointer nature of Python's variables.
βIt's also printing out the programmer-readable representation instead of the human-readable one, which makes it a little bit clearer that answer is currently a string, but it's supposed to be a number.β
Read more π https://pym.dev/debugging-with-f-strings/
For example, it may not be clear what this condition checks:
if len(text) - len(text.lstrip()) >= 4:
...
But it's pretty clear what this one checks:
indent_level = len(text) - len(text.lstrip())
if indent_level >= 4:
...
Even if a variable is strictly unnecessary, if it improves readability you should keep it!
π§΅ (2/2)
Python Tip #84 (of 365):
Use variables to improve code clarity.
Today's tip is the inverse of yesterday's tip.
Well-named variables CAN make your code more readable and they don't really make your code less efficient (after all, variables are just pointers).
π§΅ (1/2)
βAny function or class that accepts an iterable can accept a generator expression.β
Read more π https://pym.dev/custom-comprehensions/