Object oriented programming in Python be like:
-
Even regular Rust code is more "exciting" than Python in this regard, since you have a choice between
self,&self, and&mut self. And occasionallymut self,&'a self, and evenself: Box<Self>. All of which offer different semantics depending on what exactly you're trying to do.I'll add that 100% of the above is understood by the compiler. Unlike Python or JavaScript where you don't know how bad you have it until the program is already running.
-
Write a new method, make sure to reference self first. Write a new method, make sure to reference self first. Call the method, make sure to reference self first.
Yeah, I can see it.
You don't reference self when calling a method, what on earth are you talking about?
You start with the instance when calling the method, like most/all other OOP languages.Also there are benefits with the explicit self/this to access instance properties.
In C++ you need to make sure all class properties/members have a naming scheme that does not conflict with potential parameter names or other names of other variables. -
In what way does OOP feel shoehorned in with Python?
I ask since that is not my own impression of the language.Would you also be willing to share what language(s) you feel do(es) OOP without it being shoehorned in?
Yeah, some weird accusations. Python has had classes since its inception (1.0).
Also the image in the post makes no sense. It shows multiple (Spidey) instances all pointing to each other which is not how self works.
self is just a parameter that may contain different instances depending how it was called. This is also true for any other parameters in any function, each time a function is called it may have a different instance. -
This post did not contain any content.
Break convention
`
class foo:
def init(cunt, bar):
cunt.bar=True`
-
Not like C# is all that much better. So much garbage in the fundamentals just because it was done that way at the start and "they can't change it now". The best example is the IList interface.
Theoretically this interface exposes both index-based access and collection-like modifications and as such would be perfect in a function if you need those two features on a type. In reality you can't use it as a function parameter because half the official types implementing IList aren't modifiable and throw a runtime error. E.g Arrays
Oh god, I didn't knew that. That's funny.
-
it's common practice as a workaround to save
thiswhen changing contexts, sincethismay change under you, in callbacks and suchKotlin:
[email protected] -
That's a footgun sure but at least you can avoid it once you're aware of the problem.
I never write function signatures with mutable interfaces. It's always IEnumerable, IReadOnlyCollection, or IReadOnlyList; otherwise, use a concrete type. The latter is typical for private/protected methods that are called with instance members of a concrete type rather than public interfaces. If you want to mutate an object, you should own it. Public methods are invoked with data not owned by the instance.
For example, a lot of extension methods in LINQ have a signature IEnumerable<T> --> IEnumerable<T>, and internally the first thing they do is call .ToList(). The interface makes minimal assumptions about the input data, then puts it into a concrete type you can manipulate efficiently. You can similarly define a method for IReadOnlyList and explicitly make it mutable via .ToList(), rather than use IList and check .IsReadOnly. Both ensure correctness but the former does it at the type level, at design time, instead of relying on runtime checks.
C# is old and full of oldness. But it's also an excellent language that can be written beautifully if you know how. And there's lots of great code to learn from in the open-source dotnet core runtime repo and related projects.
Functional programming fixes the problem by simply not making it OO anymore, and while I'm personally a big fan of the paradigm there are situations where an OO approach is preferable (or even only to conform to a project's existing way of doing things).
-
Functional programming fixes the problem by simply not making it OO anymore, and while I'm personally a big fan of the paradigm there are situations where an OO approach is preferable (or even only to conform to a project's existing way of doing things).
What I described isn't necessarily functional. This is just a principle for ensuring objects represent clear and well-defined contracts. The idea is that to mutate something, you should own it; that means interfaces / public APIs, which can be called externally, should take immutable arguments. You can still mutate instance members internally because those are owned by the instance. If mutation is really necessary between two objects then it should be coordinated by an object owning them both.
-
I'll add that 100% of the above is understood by the compiler. Unlike Python or JavaScript where you don't know how bad you have it until the program is already running.
At least python has a decent runtime typing system
JS's type system feels like what you'd get by giving a monkey access to unlimited cocaine and a computer
-
Oh, you assigned a method to a variable before calling it? Congratulations,
thisis nowundefined.Yes. There's no telling what
thisis.thiscould be anything. We tried to keep track ofthis, but no one knows whenthiswill change. -
Yes. There's no telling what
thisis.thiscould be anything. We tried to keep track ofthis, but no one knows whenthiswill change.I used to be with
this, but then they changed whatthiswas.Now what I'm with isn't
this, and what'sthisseems weird and scary to me.This'll happen to you!
-
that's because anyone who develops oop in Python is mentally ill.
Python is a scripting language, not to be confused with an actual programming language. Like everything else in development over the last decade, newbs are just shoehorning whatever is hot into the language because nobody is stopping them.
wrote on last edited by [email protected]that’s because anyone who develops oop in Python is mentally ill.
Hard disagree there. I would argue that most "multi-paradigm" languages converge on the same features, given enough time to iterate. It's not necessarily about hot-sauce. I honestly think its about utility and meeting your userbase where their heads are.
-
Not like C# is all that much better. So much garbage in the fundamentals just because it was done that way at the start and "they can't change it now". The best example is the IList interface.
Theoretically this interface exposes both index-based access and collection-like modifications and as such would be perfect in a function if you need those two features on a type. In reality you can't use it as a function parameter because half the official types implementing IList aren't modifiable and throw a runtime error. E.g Arrays
Embrace the holy light of Dart
-
that’s because anyone who develops oop in Python is mentally ill.
Hard disagree there. I would argue that most "multi-paradigm" languages converge on the same features, given enough time to iterate. It's not necessarily about hot-sauce. I honestly think its about utility and meeting your userbase where their heads are.
I honestly think its about utility and meeting your userbase where their heads are.
then the Python userbase must have their heads shoved up their ass.
-
Now my brain wants to relate Java somehow to beancounters.
Well it is owned by Oracle now
-
In what way does OOP feel shoehorned in with Python?
I ask since that is not my own impression of the language.Would you also be willing to share what language(s) you feel do(es) OOP without it being shoehorned in?
I was looking to see if there are equivalents to Java's private and protected members, and it looks like Python's answer to that is just throw one or two underscores in front of things to do that. And it doesn't really do anything, more of just a naming convention. To me that feels like a basic OO structure that is shoehorned into Python.
-
I was looking to see if there are equivalents to Java's private and protected members, and it looks like Python's answer to that is just throw one or two underscores in front of things to do that. And it doesn't really do anything, more of just a naming convention. To me that feels like a basic OO structure that is shoehorned into Python.
A single underscore is just a naming convention, but double underscores triggers automatic name-mangling of the variable in question:
$ cat test.py class foo: def __init__(self, x): self.__x = x f = foo(1) f.__x $ python3 test.py Traceback (most recent call last): File "/mnt/d/test.py", line 6, in <module> f.__x AttributeError: 'foo' object has no attribute '__x'However, much like private/protected variables in java, this is pretty trivial to circumvent if you want.
But I don't believe that you can argue that access modifiers are required for OO not to be shoehorned into a language, not when influential OO languages like Smalltalk didn't have this feature either. Java just happens to be closer to C++, where public/private/protected is much more rigidly enforced than either Java or Python
