
Ask HN: What do you think about using classes in Python? - rodrigoreis22
The team I&#x27;m working with use python for backend scripts and now they want to change all the python code to use Classes. I don&#x27;t think this is necessary because we&#x27;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&#x27;s useless. You can have a clean and concise Python code without classes.
How would you handle that? What would be your arguments?
======
rodrigoreis22
I loved this essay Paul Graham wrote:
[http://paulgraham.com/noop.html](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.

------
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 :)

------
Vaskivo
Stop writing classes - Jack Diederich -
[https://www.youtube.com/watch?v=o9pEzgHorH0](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](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](https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it)
[2] [http://pyvideo.org/speaker/138/raymond-
hettinger](http://pyvideo.org/speaker/138/raymond-hettinger)

------
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...](http://eev.ee/blog/2013/03/03/the-controller-pattern-is-awful-and-
other-oo-heresy/)

~~~
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.

------
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.

------
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.

------
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.

------
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.

------
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.

------
jdubya
I have rebuilt a lot of code from scratch.

You learn a lot and hate programming...

Unless the codebase is awesome.

Ha!

