Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #101430 > unrolled thread

When I need classes?

Back to article view | Back to comp.lang.python

Contents

  When I need classes? Arshpreet Singh <arsh840@gmail.com> - 2016-01-09 23:29 -0800
    Re: When I need classes? Michael Torrie <torriem@gmail.com> - 2016-01-10 08:02 -0700
      Re: When I need classes? Arshpreet Singh <arsh840@gmail.com> - 2016-01-10 22:45 -0800
        Re: When I need classes? Cameron Simpson <cs@zip.com.au> - 2016-01-11 18:27 +1100
    Re: When I need classes? Steven D'Aprano <steve@pearwood.info> - 2016-01-11 02:39 +1100
      Re: When I need classes? Bernardo Sulzbach <mafagafogigante@gmail.com> - 2016-01-10 15:48 -0200
        Re: When I need classes? Arshpreet Singh <arsh840@gmail.com> - 2016-01-10 22:24 -0800
      Re: When I need classes? Arshpreet Singh <arsh840@gmail.com> - 2016-01-10 22:28 -0800
      Re: When I need classes? Travis Griggs <travisgriggs@gmail.com> - 2016-01-11 15:45 -0800
        Re: When I need classes? Mike S <mscir@yahoo.com> - 2016-01-13 22:27 -0800
      Re: When I need classes? Michael Torrie <torriem@gmail.com> - 2016-01-11 16:59 -0700
      Re: When I need classes? Bernardo Sulzbach <mafagafogigante@gmail.com> - 2016-01-11 22:53 -0200
      Re: When I need classes? Chris Angelico <rosuav@gmail.com> - 2016-01-12 12:28 +1100
        Re: When I need classes? Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-01-13 10:01 +1300
          Re: When I need classes? Bernardo Sulzbach <mafagafogigante@gmail.com> - 2016-01-12 19:08 -0200
      Re: When I need classes? Ian Kelly <ian.g.kelly@gmail.com> - 2016-01-12 17:18 -0700
        Re: When I need classes? Steven D'Aprano <steve@pearwood.info> - 2016-01-13 12:33 +1100
    Re: When I need classes? Rustom Mody <rustompmody@gmail.com> - 2016-01-12 19:36 -0800
      Re: When I need classes? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-01-13 16:27 +1100
        Re: When I need classes? Rustom Mody <rustompmody@gmail.com> - 2016-01-12 22:31 -0800
          Re: When I need classes? Rustom Mody <rustompmody@gmail.com> - 2016-01-13 08:33 -0800
        Re: When I need classes? Rick Johnson <rantingrickjohnson@gmail.com> - 2016-01-14 10:00 -0800

Page 2 of 2 — ← Prev page 1 [2]

#101629

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

[toc] | [prev] | [next] | [standalone]

#101706

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"!

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.python

csiph-web