Thanks everyone for your responses. They were very useful and I am
glad I asked the question.
I think having a concrete example would help me better, lets say I have this.
Trian A, Arrived at 6:00AM Jun 25, Left at 8:00AM Jun 25
Trian B, Arrived at 2:00AM Jun 26, Left at 12:00AM Jun 26
Trian C, Arrived at 4:00AM Jun 2, Left at 11:00AM Jun 2
Trian D, Arrived at 7:00AM Jun 11, Left at 3:00AM Jun 11
How would I build an OOP model with Python?
class Train:
"""A simple example class"""
def Arrive(self):
return 'Arrived at: '
def Left(self):
return 'Left at: '
Does that look right? Lets say I want to figure out how long each
train waited on the platfor
On Fri, Jun 25, 2010 at 3:00 AM, geremy condra <debat...@gmail.com> wrote:
> On Thu, Jun 24, 2010 at 9:04 AM, Alf P. Steinbach /Usenet
> <alf.p.steinbach+use...@gmail.com> wrote:
>> * Mag Gam, on 24.06.2010 13:58:
>>>
>>> I have been using python for about 1 year now and I really like the
>>> language. Obviously there was a learning curve but I have a programing
>>> background which made it an easy transition. I picked up some good
>>> habits such as automatic code indenting :-), and making my programs
>>> more modular by having functions.
>>>
>>> I know that Python is very OOP friendly, but I could not figure out
>>> why and when to use Classes in it. I mostly use it for simple text
>>> parsing I suppose when a program gets "complicated" I should start
>>> using Classes. Are there any tips or tricks people use to "force" them
>>> into the OOP mentality? I would like to force myself to learn the
>>> Python way but so far I could not figure out WHY I would need a class
>>> for this...
>>
>> Use whatever paradigm that yields code that you easily understand. <g>
>>
>> Having said that, the main use of a class is to model some data with an
>> associated set of operations.
>>
>> For this a class is merely a convenience, but sometimes the convenience can
>> be so great that any other approach would be impractical in comparision.
>>
>> In some cases a non-class approach ends up with a number of routines foo,
>> bar, zlopf etc. that all take some argument of a "general" type and all
>> internally has some "if it's really a BRACHYKLURB, do A, assuming that it
>> has BRACHYKLURB-specific data, but if it's really a KNETCHOFICHUS, then do
>> B, assuming that it has KNETCHOFICHUS-specific data, and as default, if it's
>> none of those, do C".
>
> If making up words is an art form, we are in the presence of a master.
>
> /applause
>
> Geremy Condra
> --
> http://mail.python.org/mailman/listinfo/python-list
>
--
http://mail.python.org/mailman/listinfo/python-list
