When I need classes?

[Rick Johnson]

On Tuesday, January 12, 2016 at 11:27:23 PM UTC-6, Steven D'Aprano wrote:
> On Wednesday 13 January 2016 14:36, Rustom Mody wrote:
> 
> > 1. Python the LANGUAGE, is rather even-handed in paradigm choice:
> > Choose OO, imperative, functional or whatever style pleases/suits
> > you 2. Python LIBRARIES however need to make committing choices.
> > Users of those then need to align with these.
> 
> I don't think that second one is necessarily correct. Look at the
> random module: it is based on an OOP design, with classes
> random.Random and random.SystemRandom doing the real work. But most
> people don't use them directly, they use the procedural interface
> random.random, random.choice, random.seed etc.

Of course, because these "procedural interfaces" are the
most convenient (in this case). Obviously that's what Rustom
was pointing out: "utilize the most convenient aspects of
the interface" to get the job done.

If you juxtapose the "interface of starting an automobile
engine" with the "interface of the random module", you could
say that the convenience of the ignition switch is like the
convenience of the three functions "random.random,
random.choice, and random.seed", and that, the inconvenience
of crawling under the vehicle and utilizing a metal *OBJECT*
(like a screwdriver) to arc the two contacts on the starter,
is much the same as utilizing the random.Random object --
both may achieve the same end goal, but one "interface"
happens to be more convenient than the other.

In this case, the procedural interface, and not the OOP
interface -- but this is not always the case! Some
functionalities cannot be reduced to the "gleeful
convenience" of a single procedure, at least, not without
sacrificing too much control!

Not only will you need to wield the power of OOP to *EXTEND*
a "general functionally" into a more "specific form", but
also when you need a "reusable package" of procedures and
(their shared data) which can *ONLY* be modeled "sanely" by
utilizing the OOP paradigm!

For instance, you can write Tkinter[1] GUI code in a
procedural form, utilizing the classes that are made
available to you, but for anything more than the most
simplistic "toy GUI", i would highly suggest against it!

============================================================
 REFERENCES:
============================================================

[1] Tkinter is used as an example here because it is a
primitive GUI library that does not include many of the
controls that modern GUI interfaces demand. For any
advanced usage, a programmer would be forced to create his
*OWN* controls, and to do so "proceduraly", would result in
an unmanageable nightmare. In order to achieve
maintainability, inevitably, you end up utilizing the
*SAME* modular design techniques of OOP! So the question
begs: Why not use OOP in the first place? I am never without
amazement as to the lengths people will go to excuse their
"nostalgic clinging"!