Looking for a good introduction to object oriented programming with Python

[Chris Angelico]

On Wed, Aug 8, 2012 at 3:00 AM, lipska the kat <lipskathekat at yahoo.co.uk> wrote:
> I'm still undecided over the whole 'User' thing actually, I don't think I
> can see a time when I will have a User Class in one of my systems but as I
> don't want to get 'dogmatic' about this I remain open to any ideas that
> might include such a Class.
>
> Person however is an entirely different matter and will never appear in my
> systems in any way shape or form ...this is not dogma, it's a fact.

This makes little sense to my mind. If you can have a "class User:",
why can you not have a "class Person:" ?

Now, that said, I can't remember the last time I actually had a class
called "Person" in anything other than a demo. But that's merely
because of terminology; I've had classes representing human beings,
but named according to what part these people play in the system
(Customer, Employee (haven't done that one, actually, but there's no
reason not to), User, Etcetera, Etcetera, Etcetera... is an Etceterer
someone who practices Etcetery?), and these classes are as
well-defined as any others.

Perhaps it would help to think about these things not as turning a
person into an entity, but as "retaining the data related to a
Person". The Person class details what data you store about a person,
a Person instance stores that data about one particular person. This
works for other things; a QueueEntry isn't actually standing in queue,
but it holds the data you store about the thing that is.

Or maybe that doesn't help, in which case just ignore it.

ChrisA