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 1 of 2  [1] 2  Next page →

#101430 — When I need classes?

Hello Friends, I am quite new to OOP(object oriented Programming), I did some projects with python which includes Data-Analysis, Flask Web Development and some simple scripts. 

I have only one question which is bothering me most of the time, When I will get the need to use Classes in Python? Or in other way is there any real-life example where you can tell me this problem/solution is kind of impossible in Python without Classes?

[toc] | [next] | [standalone]

#101434

On 01/10/2016 12:29 AM, Arshpreet Singh wrote:
> Hello Friends, I am quite new to OOP(object oriented Programming), I
> did some projects with python which includes Data-Analysis, Flask Web
> Development and some simple scripts.
> 
> I have only one question which is bothering me most of the time, When
> I will get the need to use Classes in Python? Or in other way is
> there any real-life example where you can tell me this
> problem/solution is kind of impossible in Python without Classes?

I can't speak to Flask or any other web development.  But for simple
scripts, I'll start out with no classes.  Just functions as needed, and
some main logic.  I always use the idiom:

if __name__ == '__main__':
    # do main logic here

This way I can import functions defined in this script into another
script later if I want.

If I find I need to share state between functions, and if I find that I
might need to have multiple situations of shared state possibly at the
same time, then I will refactor the script into a class.  Despite the
apparent shame of using global variables, if I need to share state
between functions, but I cannot ever foresee a time when I'll need to
have multiple instances of that state, then I'll just use a module-level
global variable and continue to use normal functions, rather than define
a class.  In the parlance of OOP, this use case would be referred to as
a "singleton" and a python module (a script) is a form of singleton
already, even without using classes.

In the end my code often is a mix of classes and non-class -based code.

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

#101464

On Sunday, 10 January 2016 20:33:20 UTC+5:30, Michael Torrie  wrote:

> This way I can import functions defined in this script into another
> script later if I want.
> 
> If I find I need to share state between functions, and if I find that I
> might need to have multiple situations of shared state possibly at the
> same time, then I will refactor the script into a class.  Despite the
> apparent shame of using global variables, if I need to share state
> between functions, but I cannot ever foresee a time when I'll need to
> have multiple instances of that state, 

I have a case in Flask-Oauth2 where one function returns Username, Email ID and Authorised Token.

So I can make that function Global and access EMail,username and Authorised token from any other Script.

Or 
I can make it class?
  
>then I'll just use a module-level
> global variable and continue to use normal functions, rather than define
> a class.  In the parlance of OOP, this use case would be referred to as
> a "singleton" and a python module (a script) is a form of singleton
> already, even without using classes.

Is it also true that Classes(OOP) help to optimise code(uses less memory) rather than just doing things with functions.

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

#101465

On 10Jan2016 22:45, Arshpreet Singh <arsh840@gmail.com> wrote:
>On Sunday, 10 January 2016 20:33:20 UTC+5:30, Michael Torrie  wrote:
>> This way I can import functions defined in this script into another
>> script later if I want.
>>
>> If I find I need to share state between functions, and if I find that I
>> might need to have multiple situations of shared state possibly at the
>> same time, then I will refactor the script into a class.  Despite the
>> apparent shame of using global variables, if I need to share state
>> between functions, but I cannot ever foresee a time when I'll need to
>> have multiple instances of that state,
>
>I have a case in Flask-Oauth2 where one function returns Username, Email ID and Authorised Token.
>
>So I can make that function Global and access EMail,username and Authorised token from any other Script.

Note: you can access the _function_ from another script or module. When your 
programs do something like:

  from os.path import basename

they are doing exactly this.

>Or
>I can make it class?

On its own it doesn't mean much. Michael Torrie's criterion said "share state 
between functions"; that state is normally an instance of the class. So you 
have some value and a bunch of standard things you would do with that kind of 
value. That is the situation where a class is a natural thing to use: you make 
a class to represent the value, and each of the standard things you would do 
with one of those values is a class method.

In your situation above I would be inclined to make a class to represent the 
3-tuple you outline above: Username, Email ID and Authorised Token. So:

  from collections import namedtuple
  Authorisation = namedtuple('Authorisation', 'username email authorised_token')

now, where you would have obtained these as a tuple:

  # call your "in Flask-Oauth2 where one function returns Username..."
  authorisation = get_auth_info(...)

and then access authorisation[0] for the username and so forth, you can go:

  # fetch the 3 values and make an "Authorisation" from them
  authorisation = Authorisation(get_auth_info(...))

and the access authorisation.username, authorisation.email etc. This avoids 
knowing special index numbers (0, 1 and 2) which makes your code more readable 
and also makes it easy to pass around the authorisation for use.

Then, if you have things you routinely do with an "Authorisation" you can make 
methods for them. So that your code can say:

  authorisation.do_this(...)

and so forth.

>>then I'll just use a module-level
>> global variable and continue to use normal functions, rather than define
>> a class.  In the parlance of OOP, this use case would be referred to as
>> a "singleton" and a python module (a script) is a form of singleton
>> already, even without using classes.
>
>Is it also true that Classes(OOP) help to optimise code(uses less memory) rather than just doing things with functions.

Not really? I would not expect using a class to inherently get you less memory 
use, just better and more consistent naming. There are some special situations 
where you can use a class to reduce your memory usage, but they are fairly 
dependent on what you're doing.

Cheers,
Cameron Simpson <cs@zip.com.au>

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

#101437

On Sun, 10 Jan 2016 06:29 pm, Arshpreet Singh wrote:

> Hello Friends, I am quite new to OOP(object oriented Programming), I did
> some projects with python which includes Data-Analysis, Flask Web
> Development and some simple scripts.
> 
> I have only one question which is bothering me most of the time, When I
> will get the need to use Classes in Python? Or in other way is there any
> real-life example where you can tell me this problem/solution is kind of
> impossible in Python without Classes?

There are *no* problems that are impossible to solve without classes, but
sometimes classes will make problems easier to solve. And sometimes classes
make problems harder to solve. It depends on the problem.

This may help you:

http://kentsjohnson.com/stories/00014.html



-- 
Steven

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

#101440

Essentially, classes (as modules) are used mainly for organizational purposes.

Although you can solve any problem you would solve using classes
without classes, solutions to some big problems may be cheaper and
more feasible using classes.

If Python is your everyday scripting tool, you will usually not need
classes, they will add more complexity than you need and passing data
between functions may be done with well-documented tuples and
dictionaries.

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

#101462

On Sunday, 10 January 2016 23:20:02 UTC+5:30, Bernardo Sulzbach  wrote:
> Essentially, classes (as modules) are used mainly for organizational purposes.
> 
> Although you can solve any problem you would solve using classes
> without classes, solutions to some big problems may be cheaper and
> more feasible using classes.

That seems coming to me as. I am going to start Kivy to build Android application and As I see there are lots of Example code with classes and stuff.

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

#101463

On Sunday, 10 January 2016 21:09:52 UTC+5:30, Steven D'Aprano  wrote:

> There are *no* problems that are impossible to solve without classes, but
> sometimes classes will make problems easier to solve. And sometimes classes
> make problems harder to solve. It depends on the problem.

Is there any particular situation in your experience or in your past like you felt this could be more suitable with classes?

Actually a real life story from someone'e past experience could do much greater help.

> This may help you:
> 
> http://kentsjohnson.com/stories/00014.html

Thanks That is good read to remember and practice.

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

#101498

> On Jan 10, 2016, at 9:48 AM, Bernardo Sulzbach <mafagafogigante@gmail.com> wrote:
> 
> Essentially, classes (as modules) are used mainly for organizational purposes.
> 
> Although you can solve any problem you would solve using classes
> without classes, solutions to some big problems may be cheaper and
> more feasible using classes.

As a long term OO purist practitioner, I would add to this. Obviously, you can organize your code any way you want, with or without classes. You could put all your functions with an odd number of letters in one class, and all of the even numbered ones in another class. 

Having listened to the guy (Alan Kay) who coined the term (Object Oriented Programming) quite a bit over the years, I believe that the focus of OO (of which classes are a particular implementation approach) is to bind behavior to data. In “traditional” programming approaches, one focused on the algorithm (behavior) first, and then figured out what data needed to flow where to get the job done. Classes provided a mechanism to turn that equation, generally speaking, around. One thinks about the data first, and then figures out what behavior binds best to that data. And how that data will interact (inter-object behavior, often called messages) to get your job done. For some (many) problems, this can be a real win. And for some, not so much.

I think, this is often why, for a simple script, OO just kind of gets in the way. You have a straightforward procedure that you just want to do. The state (data) is not rich enough to make making it the focal point of your program.

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

#101668

On 1/11/2016 3:45 PM, Travis Griggs wrote:
>
>> On Jan 10, 2016, at 9:48 AM, Bernardo Sulzbach <mafagafogigante@gmail.com> wrote:
>>
>> Essentially, classes (as modules) are used mainly for organizational purposes.
>>
>> Although you can solve any problem you would solve using classes
>> without classes, solutions to some big problems may be cheaper and
>> more feasible using classes.
>
> As a long term OO purist practitioner, I would add to this. Obviously, you can organize your code any way you want, with or without classes. You could put all your functions with an odd number of letters in one class, and all of the even numbered ones in another class.
>
> Having listened to the guy (Alan Kay) who coined the term (Object Oriented Programming) quite a bit over the years, I believe that the focus of OO (of which classes are a particular implementation approach) is to bind behavior to data. In “traditional” programming approaches, one focused on the algorithm (behavior) first, and then figured out what data needed to flow where to get the job done. Classes provided a mechanism to turn that equation, generally speaking, around. One thinks about the data first, and then figures out what behavior binds best to that data. And how that data will interact (inter-object behavior, often called messages) to get your job done. For some (many) problems, this can be a real win. And for some, not so much.
>
> I think, this is often why, for a simple script, OO just kind of gets in the way. You have a straightforward procedure that you just want to do. The state (data) is not rich enough to make making it the focal point of your program.

Well said, thanks!

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

#101500

On 01/11/2016 04:45 PM, Travis Griggs wrote:
> As a long term OO purist practitioner, I would add to this.
> Obviously, you can organize your code any way you want, with or
> without classes. You could put all your functions with an odd number
> of letters in one class, and all of the even numbered ones in another
> class.

And of course in Java you have to use classes for namespaces and
organization.  In python, the equivalent is simply a module.  It's
essentially a singleton object without having to do any boiler plate.  A
module can even keep state, so long as you only need to keep track of
one instance or set of states at a time.

> Having listened to the guy (Alan Kay) who coined the term (Object
> Oriented Programming) quite a bit over the years, I believe that the
> focus of OO (of which classes are a particular implementation
> approach) is to bind behavior to data. In “traditional” programming
> approaches, one focused on the algorithm (behavior) first, and then
> figured out what data needed to flow where to get the job done.
> Classes provided a mechanism to turn that equation, generally
> speaking, around. One thinks about the data first, and then figures
> out what behavior binds best to that data. And how that data will
> interact (inter-object behavior, often called messages) to get your
> job done. For some (many) problems, this can be a real win. And for
> some, not so much.
> 
> I think, this is often why, for a simple script, OO just kind of gets
> in the way. You have a straightforward procedure that you just want
> to do. The state (data) is not rich enough to make making it the
> focal point of your program.

The beauty of Python is that you can program procedurally, and still
work with objects as needed.  Every data type in Python is some kind of
object and you can call appropriate methods on those objects.  Even if
you do no OOP programming yourself.  For example,

some_string = "foo:bar"
(a,b) = some_string.split(':')

The ease with which Python can be used in many programming paradigms is
one reason I like Python so much.

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

#101505

On Mon, Jan 11, 2016 at 9:45 PM, Travis Griggs <travisgriggs@gmail.com> wrote:
>
>> On Jan 10, 2016, at 9:48 AM, Bernardo Sulzbach <mafagafogigante@gmail.com> wrote:
>>
>> Essentially, classes (as modules) are used mainly for organizational purposes.
>>
>> Although you can solve any problem you would solve using classes
>> without classes, solutions to some big problems may be cheaper and
>> more feasible using classes.
>
> I think, this is often why, for a simple script, OO just kind of gets in the way. You have a straightforward procedure that you just want to do. The state (data) is not rich enough to make making it the focal point of your program.

Your answer is quite good. I am not a purist myself (when it comes to
Java and C++, I am never going to instantiate a Math class to get a
logarithm function), but I understand the value of OO from experience.
As I mentioned those "tuples and dictionaries" to pass data around, I
would like to add that when a single script has two kinds of tuples or
dictionaries, you may be better of using two different classes, as
having "dedicated" types simplifies project organization and
enhances readability.

I have never gone "seriously OO" with Python though. I never wrote
from scratch an application with more than 10 classes as far as I can
remember. However, I would suppose that the interpreter can handle
thousands of user-defined classes simultaneously.

-- 
Bernardo Sulzbach

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

#101510

On Tue, Jan 12, 2016 at 11:53 AM, Bernardo Sulzbach
<mafagafogigante@gmail.com> wrote:
> On Mon, Jan 11, 2016 at 9:45 PM, Travis Griggs <travisgriggs@gmail.com> wrote:
>>
>>> On Jan 10, 2016, at 9:48 AM, Bernardo Sulzbach <mafagafogigante@gmail.com> wrote:
>>>
>>> Essentially, classes (as modules) are used mainly for organizational purposes.
>>>
>>> Although you can solve any problem you would solve using classes
>>> without classes, solutions to some big problems may be cheaper and
>>> more feasible using classes.
>>
>> I think, this is often why, for a simple script, OO just kind of gets in the way. You have a straightforward procedure that you just want to do. The state (data) is not rich enough to make making it the focal point of your program.
>
> Your answer is quite good. I am not a purist myself (when it comes to
> Java and C++, I am never going to instantiate a Math class to get a
> logarithm function), but I understand the value of OO from experience.
> As I mentioned those "tuples and dictionaries" to pass data around, I
> would like to add that when a single script has two kinds of tuples or
> dictionaries, you may be better of using two different classes, as
> having "dedicated" types simplifies project organization and
> enhances readability.
>

Yeah. One thing I often recommend, especially to students, is to start
with the very simplest and most naive code they can knock together,
and then look at making it tidier afterwards. Classes, decorators, the
unittest setUp/tearDown methods, and even functions themselves, are
all just ways of improving code that could be written some other way.
They're not rigid structures that you HAVE to comply with or your code
is *just* *not* *good* *enough*. So start simplistic, and then look
into it like this: "Hey, see how you're doing this five times? There
HAS to be a better way!" (With acknowledgement to Raymond Hettinger.)

ChrisA

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

#101575

Chris Angelico wrote:
> So start simplistic, and then look
> into it like this: "Hey, see how you're doing this five times? There
> HAS to be a better way!" (With acknowledgement to Raymond Hettinger.)

That gave me visions of a little animated cartoon of
Raymond popping up in the corner of the screen, offering
to write some code for me. The next big IDLE feature...?

-- 
Greg

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

#101576

On Tue, Jan 12, 2016 at 7:01 PM, Gregory Ewing
<greg.ewing@canterbury.ac.nz> wrote:
> Chris Angelico wrote:
>>
>> So start simplistic, and then look
>> into it like this: "Hey, see how you're doing this five times? There
>> HAS to be a better way!" (With acknowledgement to Raymond Hettinger.)
>
>
> That gave me visions of a little animated cartoon of
> Raymond popping up in the corner of the screen, offering
> to write some code for me. The next big IDLE feature...?
>

The Windows paperclip strikes back!

-- 
Bernardo Sulzbach

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

#101577

On Mon, Jan 11, 2016 at 5:53 PM, Bernardo Sulzbach
<mafagafogigante@gmail.com> wrote:
> I have never gone "seriously OO" with Python though. I never wrote
> from scratch an application with more than 10 classes as far as I can
> remember. However, I would suppose that the interpreter can handle
> thousands of user-defined classes simultaneously.

In Python, a class is just an object, so the only limit on how many
classes the interpreter can handle simultaneously is available memory.

However, if you have deeply nested inheritance graphs then you could
start to see performance issues on method calls, since the entire
inheritance graph potentially has to be traversed in order to find the
method.

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

#101583

On Wed, 13 Jan 2016 11:18 am, Ian Kelly wrote:

> On Mon, Jan 11, 2016 at 5:53 PM, Bernardo Sulzbach
> <mafagafogigante@gmail.com> wrote:
>> I have never gone "seriously OO" with Python though. I never wrote
>> from scratch an application with more than 10 classes as far as I can
>> remember. However, I would suppose that the interpreter can handle
>> thousands of user-defined classes simultaneously.
> 
> In Python, a class is just an object, so the only limit on how many
> classes the interpreter can handle simultaneously is available memory.
> 
> However, if you have deeply nested inheritance graphs then you could
> start to see performance issues on method calls, since the entire
> inheritance graph potentially has to be traversed in order to find the
> method.


I'm sure Ian knows this already, but for the benefit of others...

Python is not Java:

http://dirtsimple.org/2004/12/python-is-not-java.html


And Java is not Python either:

http://dirtsimple.org/2004/12/java-is-not-python-either.html



-- 
Steven

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

#101589

On Sunday, January 10, 2016 at 1:00:13 PM UTC+5:30, Arshpreet Singh wrote:
> Hello Friends, I am quite new to OOP(object oriented Programming), I did some projects with python which includes Data-Analysis, Flask Web Development and some simple scripts. 
> 
> I have only one question which is bothering me most of the time, When I will get the need to use Classes in Python? Or in other way is there any real-life example where you can tell me this problem/solution is kind of impossible in Python without Classes?

I think the answers so far dont cover two complementary sides to this question:

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.

egs 
1. Majority of basic python is functional; eg stuff in os module

2. Some things need object creation and method call
eg for re-s you need to know about and to use re objects, match objects etc

3. Then there are things that are naturally used by inheriting and extending
eg Basehttpserver is typically used via inheritance
To use these you need to know basic OO

4. Then there may be things whose natural usage needs multiple inheritance
[cant think of examples]

So as others have said, in principle you dont need to go beyond 1.
Unfortunately when you are using non-trivial libraries you are a user both of
python and the library and so the library-author's paradigm choices are a given
for you

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

#101590

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.



-- 
Steve

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

#101591

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]

Page 1 of 2  [1] 2  Next page →

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

csiph-web