HN Explorer

Ask HN: What do you think about using classes in Python?

13 points by rodrigoreis22 ↗ HN
The team I'm working with use python for backend scripts and now they want to change all the python code to use Classes. I don't think this is necessary because we'll end having a lot of unwanted boilerplate code. I think classes are suited if you want many instances of the same thing, each with its own isolated state.. otherwise it's useless. You can have a clean and concise Python code without classes. How would you handle that? What would be your arguments?

19 comments

[ 4.4 ms ] story [ 62.8 ms ] thread
a3n
> they want to change all the python code

Why, doesn't it work?

Always potentially a bad idea, regardless of what you're changing to.

CyberFonic
Although I prefer class oriented programming in Python, I have worked on projects where functions were a better fit to the domain concepts.
rodrigoreis22
It does work. The argument it's OOP enforces more organized code base.. I don't personally agree. You can have a very clean non-OOP python code and you can also have a very ugly and bad OOP-based code.. it just seems stupid.
jdubya
I have rebuilt a lot of code from scratch.

You learn a lot and hate programming...

Unless the codebase is awesome.

Ha!

gjvc
if they mean "turn the currently fat, repetitive scripts into slim wrappers which call into a well-structured collection of well-composed classes of objects, which closely match the problem domain, thus promoting code reuse, and fix once, benefit everywhere behavior", then good.

difficult to comment properly without more context.

CyberFonic
Context is the key to getting a better answer to your question. For any sufficiently large code base you would need to adopt some structure, e.g. modules and/or well designed functions, to ensure that the system is maintainable. Classes are just one to encapsulate state and behaviour so it doesn't leak all over the place.
rodrigoreis22
It's not currently fat and repetitive.. it has decent layered-organized structure.. My argument is that you can have many of the benefits of OOP in Python just using modules. When you need many instances, each with its own isolated state, or you need inheritance.. then go for classes.
striking
(I don't think this is a strictly Python-based argument, so I'll expand to all of OOP.) I agree with the sentiment that Object-Oriented Programming is only useful in certain cases. Personally, as long as there's enough encapsulation that components can be composed and utilized well, classes are not useful.

Pros: enforced encapsulation, things mix and match easily, inheritance (sometimes useful)

Cons: over-organization/God objects/anti-patterns (especially of the inheritance variety), bad garbage collection patterns, classes that are "only behavior and not state" [1])

(Also, if it ain't broke, don't rewrite it. Not unless their programming concerns have been conveniently redacted from your post.)

[1]: http://eev.ee/blog/2013/03/03/the-controller-pattern-is-awfu...

dragonwriter
> I don't think this is a strictly Python-based argument, so I'll expand to all of OOP

Expanding loses important context.

> Pros: enforced encapsulation, things mix and match easily, inheritance (sometimes useful)

As an example of the point above about context, Python -- and this is common among dynamic OO languages as opposed to C++/Java-style static class-based OO languages -- has encapsulation by convention rather than enforcement.

> Cons: over-organization/God objects/anti-patterns (especially of the inheritance variety), bad garbage collection patterns, classes that are "only behavior and not state" [1])

I don't think any of these are cons of OOP. All but the last are doing OOP badly -- but any paradigm can be done badly.

The last is not OOP, though its something that can be done in most OO languages. OTOH, there's no real reason to oppose it other than OO fundamentalism -- an object or class that contains only behavior and not state may not be really an example of OOP, but its not a "Con" of OOP, its just a manner in which modules as found in many procedural/functional languages can be implemented in some languages where OOP is the paradigm from which the primary syntactic structures are drawn.

raquo
* Python offers more encapsulation without classes than say PHP if you use importing properly, so a codebase without classes is not a big deal (I prefer OOD though).

* If your python code is organized in such a way that your classes will end up having no instance vars or methods, pragmatic advantages to using classes are limited. In other words, if you're switching to OOP, make use of that paradigm or it will indeed feel like mere boilerplate.

CyberFonic
Boilerplate code for classes in Python? WTF?

Are you sure you are not adopting Java or C++ conventions?

Python supports both OO and functional paradigms. For any project you would use the combination that is optimal for the project. Forcing the use of one or the other without considering the overall impact is unwise.

brogrammer90
It's easier to write bad OOP than bad procedural code.

Let me guess what's happening here. Some kid recently read the gang of four design patterns book and now thinks he can turn your battle tested scripts into reusable extensible modules?

rodrigoreis22
lol.. probably! The very old brainwash people suffer at college and then go out thinking OOP is a silver-bullet that will solve all of your problems :)
dragonwriter
If you have a particular reason to use classes when writing new code or updating existing code, go for it. But rewriting just to use classes without a clear purpose is pointless -- its at least a waste of time, and quite possibly ends up introducing new bugs and maintenance problems.
rodrigoreis22
I loved this essay Paul Graham wrote: http://paulgraham.com/noop.html

Quoting: "My own feeling is that object-oriented programming is a useful technique in some cases, but it isn't something that has to pervade every program you write. You should be able to define new types, but you shouldn't have to express every program as the definition of new types."

dragonwriter
That essay is generally good, and I agree with the general point (quoting: "object-oriented programming is a useful technique in some cases, but it isn't something that has to pervade every program you write"), but the specific quote you pull out is quite bizarre, given that "defining new types" has nothing at all do with OOP. It has more to do with statically-typed programming -- idiomatic code does a lot more of it (even equating "class" with "type", which is a dubious equivalence outside of statically-typed OO languages) in a statically-typed functional programming language like Haskell than in a dynamically-typed OO language like Ruby.
Vaskivo
Stop writing classes - Jack Diederich - https://www.youtube.com/watch?v=o9pEzgHorH0

Show them this.

I'm still grateful for the moment I grew dissatisfied with OOP, or at least OOP in the Java/C# way. I was almost getting to an intermediate level in python (by myself) and had been thinking about a video game architecture problem I just couldn't solve.

I was still "indoctrinated" in the gang-of-four patterns and inheritance. When I discovered the solution, Entity Component Architectures[1], I also discovered the "composition over inheritance" philosophy. My mind was blown! Coupled with some Python's characteristics (duck-typing, everything is public, first-class functions) I was having a blast. Then I saw the video above, and all fell into place. Class based OOP have specific uses, but It's a shame how heavily enforced the paradigm is.

    “Sometimes, the elegant implementation is just a function. Not a method. Not a class. Not a framework. Just a function.” – John Carmack
Now, for scripts or not-to-big programs in Python, I mainly use NamedTuples for passing data around and (mostly) pure functions.

P.S. Another funny thing: At my job I use J2EE aka "lots of hinheritance and classes and boilerplate". Sometimes I just have to go home and write some code in python or lua to "cleanse my palate". It helps me get motivated for my personal projects.

[1] https://en.wikipedia.org/wiki/Entity_component_system

rodrigoreis22
I saw this video and showed them.. lol. I partially agree with the game example shown in the video.. I found the final code quite hard to understand. But I think that's due to my lack of knowledge in all the native stuff Python can do. I like when he says that you don't have to plan too much ahead for the future.. I think this generate phantom requirements that doesn't contribute for the solution. Just change the code when you need it. Wow, this ECA is heaven! :)
Vaskivo
> I think this generate phantom requirements that doesn't contribute for the solution. Just change the code when you need it.

YAGNI -> You Aren't Gonna Need It [1]

If you want to know more about about Python I recommend Raymond Hettinger's videos [2]

About ECA (which I presume is Entity Component Architecture) I have to say two things: 1) I've seen this pattern/concept be called many different things: Entity-Component, Game-Object Game-Component, Entity-Systems, etc. And at least two major ways of implementing it. 2) Like most design patterns, they exist to help you design program using languages that use heavy class-based OOP and static typing. In Python everything is dynamic and it uses duck typing, so can "draw some inspiration" from the pattern instead of implementing it by the book.

[1] https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it [2] http://pyvideo.org/speaker/138/raymond-hettinger