As a data analyst I rarely have a need for writing OOP code. But I'm very much interested in learning as much as possible about it as it's very useful technique!
That's a really interesting question. In a simple example, it won't make much difference. In a real-world context, it depends on what you might do with that value. Using an empty string means any string method that's called on name will work; if you used None and called a string method, such as name.title(), you'd get an error.
Using None would allow you to determine if a value was passed. You could check `if name is None`, and then deal with a situation where a name was not passed. Even in that case, a test of `if not name` is probably going to be sufficient.
Hi. If you look at this on anything other than a phone in vertical orientation, the indentation is correct. On a vertical phone, Substack's wrapping makes it look like that last line is unindented.
Substack's code blocks aren't nearly as well-featured as most code blocks we see online, because they're designed to work well in all kinds of email clients. They don't have syntax highlighting, and they don't show horizontal scrollbars for long lines. I've written previously about how Substack could improve their code blocks: https://mostlypython.substack.com/p/improving-code-blocks-in-substack
I made a note to see if there's any way to address this issue as well. Thank you for pointing this out!
I recognize there are some other paradigms that avoid some of the pitfalls of OOP. But I think it took off because it's useful. I remember first learning OOP, and my spaghetti code got a lot less spaghetti-like.
Any paradigm that sees widespread use is going to have some great examples, a bunch of competent examples, and a wide range of poor implementations. I don't think that's particular to OOP.
I think it takes experience to understand how to architect larger projects well. You need to write your own larger projects and see what original ideas help the project, and which ideas make it hard to maintain. You need to see other projects that are done poorly, and others that are done well. And learning about other paradigms, such as functional programming, helps as well.
Enjoyed this Robot example + the concept of "storing info + actions in the same place".
I start babbling about inheritance when I explain OOP to first timers.
I very much agree with you.
As a data analyst I rarely have a need for writing OOP code. But I'm very much interested in learning as much as possible about it as it's very useful technique!
Why use the double quote def __init__(self, name=""): instead of None def __init__(self, name=None): ?
That's a really interesting question. In a simple example, it won't make much difference. In a real-world context, it depends on what you might do with that value. Using an empty string means any string method that's called on name will work; if you used None and called a string method, such as name.title(), you'd get an error.
Using None would allow you to determine if a value was passed. You could check `if name is None`, and then deal with a situation where a name was not passed. Even in that case, a test of `if not name` is probably going to be sufficient.
The code in the footnote needs indentation in last line to append a new robot on each pass through the loop.
Hi. If you look at this on anything other than a phone in vertical orientation, the indentation is correct. On a vertical phone, Substack's wrapping makes it look like that last line is unindented.
Substack's code blocks aren't nearly as well-featured as most code blocks we see online, because they're designed to work well in all kinds of email clients. They don't have syntax highlighting, and they don't show horizontal scrollbars for long lines. I've written previously about how Substack could improve their code blocks: https://mostlypython.substack.com/p/improving-code-blocks-in-substack
I made a note to see if there's any way to address this issue as well. Thank you for pointing this out!
I recognize there are some other paradigms that avoid some of the pitfalls of OOP. But I think it took off because it's useful. I remember first learning OOP, and my spaghetti code got a lot less spaghetti-like.
Any paradigm that sees widespread use is going to have some great examples, a bunch of competent examples, and a wide range of poor implementations. I don't think that's particular to OOP.
I think it takes experience to understand how to architect larger projects well. You need to write your own larger projects and see what original ideas help the project, and which ideas make it hard to maintain. You need to see other projects that are done poorly, and others that are done well. And learning about other paradigms, such as functional programming, helps as well.