When I need classes?

[Rustom Mody]

Guess you (Rodrigo) wanted to send this to the list?

On Wed, Jan 13, 2016 at 8:22 PM, Rodrigo Bistolfi  wrote:

>     Start by using just functions. As you move forward, you will find that 
> often you are passing the same data structure as first argument to some 
> functions. At that point, you are already using OOP, and you may want to
> formalize that in a class.

>    HTH




On Wednesday, January 13, 2016 at 12:01:29 PM UTC+5:30, Rustom Mody wrote:
> On Wednesday, January 13, 2016 at 10:57:23 AM UTC+5:30, 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.
> > 
> 
> Yes one can have more or less degrees of freedom. Are infinite degrees possible?
> I believe not.
> 
> eg My example of re is strictly not correct: can use strings instead of re objects
> Can use findall instead of search/match and avoid groping around in opaque match
> objects
> So you may conclude that the re module allows these degrees of freedom
> But you cant bold res all the way into the syntax of the language (eg perl/awk)
> 
> Anyway these are side points
> My main point is that when you sit on top of heavy-duty many-layered libraries
> (worse frameworks... OP seems to be trying Kivy) then you have to align with
> the opinionatedness of all the layers down to python.
> 
> Of course that is modulo the leakiness of the abstractions.
> eg mostly python programmers do not need to know the underlying C...
> 
> Mostly...
> And then someone asks about id/is/performance...