Re: [newbie] Looking for a good introduction to object oriented programming with Python
On 07/08/12 15:14, Steven D'Aprano wrote: On Tue, 07 Aug 2012 10:19:31 +0100, lipska the kat wrote: On 07/08/12 06:19, Steven D'Aprano wrote: [...] But what *really* gets me is not the existence of poor terminology. I couldn't care less what terminology Java programmers use among themselves. I'd be most grateful if you could park the whole 'This person is a 'Java developer so must be a moron thing' it's getting a bit wearing. Lipska, it's not always about you. Never thought so for a moment, good to know you can be reasonable as well as misguided ;-) lipska -- Lipska the Kat: Troll hunter, sandbox destroyer and farscape dreamer of Aeryn Sun -- http://mail.python.org/mailman/listinfo/python-list
Re: [newbie] Looking for a good introduction to object oriented programming with Python
On Tue, 07 Aug 2012 10:19:31 +0100, lipska the kat wrote: > On 07/08/12 06:19, Steven D'Aprano wrote: [...] >> But what *really* gets me is not the existence of poor terminology. I >> couldn't care less what terminology Java programmers use among >> themselves. > > I'd be most grateful if you could park the whole 'This person is a 'Java > developer so must be a moron thing' it's getting a bit wearing. Lipska, it's not always about you. I've been hanging around this forum for, oh, at least six years now. Trust me, you're not the first Java developer brave enough to poke their head up :) Java coders who come here tend to talk about "instance variables". C++ coders tend to talk about "members". Haskell people don't tend to talk much about objects at all. And PHP coders tend to talk about how they saw Spot run. (I kid. Sorry PHP coders, I couldn't resist.) It's not about being a moron. Anyone new to a language is going to carry across preconceptions from their previous language, and use the terminology they're used to. I've seen more than one Lisper assume that Python lists are linked lists and wonder how to call car and cdr, and nobody is accusing Lispers of being dumb. And I'm not going to even try to describe the misconceptions I had learning Python, coming from a background of Pascal, RPN and Hypertalk -- the first two languages weren't OOP, and Hypertalk's OOP model was *very* different from Python's. Don't think that every time I mention Java it's a dig at you. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: [newbie] Looking for a good introduction to object oriented programming with Python
On 07/08/12 14:12, Ben Finney wrote: lipska the kat writes: The ONLY concept that you should never try to encapsulate is/are human beings or their aliases. You stated this in absolute, dogmatic terms. I thought at first you were being hyperbolic for effect, but the situation that you present to support this dogma is one where I can't see anyone rationally concluding the dogma applies. Ah, you mean you don't agree. Well now this is a personal thing born of bitter experience. [snip] Also, inevitably a Person 'is a' Customer, a Person 'is a' Contact, a Person 'is a' security risk, well you get the idea. This accurately reflects the reality that “person” is a real-world entity very frequently involved in just about anything a typical system needs to model. No, you are wrong. Having a Person class is profoundly and fundamentally wrong. If we follow this argument then every system ever modelled would have a Person at it's heart. I think you are missing the point here. You say. > This accurately reflects the reality that “person” is a real-world > entity very frequently involved in just about anything a typical stem > needs to model. that a "person" is a real-world entity very >frequently Have asserted that you are profoundly wrong I now have to say that I couldn't agree more BUT with the crucial modifier that a person is an "actor" I don't care if you like or dislike the terminology, you get the general idea. An actor exists outside the system. Having a Person in the Class model tends to blur the boundaries between system and users. I know it does, I've seen it happen so many times. It's all about how we think about a system in the early stages of design The moment we introduce a Person (or alias for a Person) we confuse our thinking, are we thinking about Person as actor or are we thinking about Person as entity in our system. This is not some nebulous flight of fancy, this is born of real world, stand at the whiteboard and thrash out a design experience. I have been ridiculed before, strangely enough, once the Person has been expunged from the system mind things go a whole lot more smoothly. Of course this is a problem with the actual design process itself What problem? If the real-world entity really exists and the “has-a” and “is-a” relationships really exist, then it's *good* design to model whatever ones of those are significant to the operation of the program. Indeed, it would be *bad* design to avoid modelling the real world merely because of dogma against modelling persons and their relationships to other entities. Dogma is an emotive word that you are using to belittle the idea. That's fine, you asked me to explain myself and I have done so. [snip] And when the real domain to be modelled almost certainly has people as a central entity in complex interactions, removing Person from the design entirely is poor work grounded in irrationality. Well I say it's sound judgment grounded in experience and most if not all my employers seem to agree. I have thousands of lines of code 'in the wild' operating without fault day after week after year and not one single line refers to, implies or otherwise represents a "Person" in any way whatsoever. Just one tiny point, I NEVER have to 'remove' a Person from my designs as they never get through the door in the first place. The only time I have ever had to agree that a "Person" belongs in a computer is when I saw Tron. lipska -- Lipska the Kat: Troll hunter, sandbox destroyer and farscape dreamer of Aeryn Sun -- http://mail.python.org/mailman/listinfo/python-list
Re: [newbie] Looking for a good introduction to object oriented programming with Python
lipska the kat writes: > The ONLY concept that you should never try to encapsulate is/are > human beings or their aliases. You stated this in absolute, dogmatic terms. I thought at first you were being hyperbolic for effect, but the situation that you present to support this dogma is one where I can't see anyone rationally concluding the dogma applies. > Well now this is a personal thing born of bitter experience. In my > experience, when you have an entity called 'Person' or some such in > your Class model it soon becomes what we 'in the trade' call a 'God > Object' The name should be self explanatory but hold tight, here comes > some more jargon. God objects are a code smell (another term of art, meaning a symptom in the code that tends to indicate poor design or some other fundamental flaw). But what you're describing below doesn't fit. > Objects can have a 'has a' relationship with other Objects or an 'is a' > relationship with other objects > > The 'has a' relationship means that an Object 'owns' another object, > the is a' relationship means that an Object 'is of a particular type' > Of course in an 'Object Oriented' language such as Java an Object > reference can have a different type at runtime than it does at compile > time. In Python too. > > Anyway, this Person thing soon ends up with a 'has a' relationship > with everything in sight. a Person 'has a[n]' Address, a Person 'has > a[n]' account, a Person 'has a' Doughnut etc etc etc > > Also, inevitably a Person 'is a' Customer, a Person 'is a' Contact, a > Person 'is a' security risk, well you get the idea. This accurately reflects the reality that “person” is a real-world entity very frequently involved in just about anything a typical system needs to model. > Of course this is a problem with the actual design process itself What problem? If the real-world entity really exists and the “has-a” and “is-a” relationships really exist, then it's *good* design to model whatever ones of those are significant to the operation of the program. Indeed, it would be *bad* design to avoid modelling the real world merely because of dogma against modelling persons and their relationships to other entities. If there were entities or relationships that were needlessly cumbersome – if indeed the object was trying to encapsulate the majority of the whole world in itself – then those should be removed from the object, and perhaps even from the design. But that's not what you describe. A Person entity in inheritance or composition relationships with other classes and objects is not a god object, since it is sensibly delegating specific jobs to places other than itself. That's very good, modular design. And when the real domain to be modelled almost certainly has people as a central entity in complex interactions, removing Person from the design entirely is poor work grounded in irrationality. -- \ “I am amazed, O Wall, that you have not collapsed and fallen, | `\since you must bear the tedious stupidities of so many | _o__) scrawlers.” —anonymous graffiti, Pompeii, 79 CE | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: [newbie] Looking for a good introduction to object oriented programming with Python
On 07/08/12 06:19, Steven D'Aprano wrote: On Mon, 06 Aug 2012 09:55:24 +0100, lipska the kat wrote: On 06/08/12 01:22, Steven D'Aprano wrote: On Sun, 05 Aug 2012 20:46:23 +0100, lipska the kat wrote: [snip] The clue is in the name 'Object Oriented' ... anything else is (or should be) implementation detail. So your argument is that any programming which is "oriented" (meaning what?) towards "objects" (which are...?) is OOP, and everything else is "implementation detail". Well now I'm enlightened. That certainly clears that up for me. Glad I could help :-) [snip] As you go on to explain: A class variable is static and can be accessed without instantiation an instance variable is accessed via an instance which are semantic differences, differences in meaning and function. Yes but when we TALK about these things a String variable is a String variable is a String variable. The words 'Class variable' and 'instance variable' are 'abstractions'. It saves us saying, 'this is a variable that can only be accessed from an instance and may hold values of the type Integer or String or Weak Reference ... (and so on ad nauseum) ... but only of one type unless you count runtime polymorphism in which case the runtime type may be different from the compile time type ... etc etc' or 'this is a variable that can be accessed without instantiating a class (see above)' If you don't like the term abstraction then perhaps we can agree on something else. Since a "string variable" is a variable holding a string, and a "float variable" is a variable holding a float, an instance variable should be a variable holding an instance, and a class variable should be a variable holding a class. See above Class variable and instance variable are higher level abstractions. Of what? Of variables? Exactly, now you're getting the hang of it [snip] Simply put, the choice of terminology is crap -- possibly but it's the best we've got. But what *really* gets me is not the existence of poor terminology. I couldn't care less what terminology Java programmers use among themselves. I'd be most grateful if you could park the whole 'This person is a 'Java developer so must be a moron thing' it's getting a bit wearing. As I said in a previous post, Java has indeed been good to me but my brain IS capable of dealing with more than one language. What gets me is that the ubiquity of them means that substandard terminology spreads into other languages, like dryrot. Yea well welcome to the world of spin, if you can't fight it then learn to roll with it. The ONLY concept that you should never try to encapsulate is/are human beings or their aliases. snip Is this some sort of mystical "humans aren't objects, they're SPECIAL!!!" rubbish? Because it sure sounds like it. [snip] Well now this is a personal thing born of bitter experience. In my experience, when you have an entity called 'Person' or some such in your Class model it soon becomes what we 'in the trade' call a 'God Object' The name should be self explanatory but hold tight, here comes some more jargon. Objects can have a 'has a' relationship with other Objects or an 'is a' relationship with other objects The 'has a' relationship means that an Object 'owns' another object, the 'is a' relationship means that an Object 'is of a particular type' Of course in an 'Object Oriented' language such as Java an Object reference can have a different type at runtime than it does at compile time. In Python too. Anyway, this Person thing soon ends up with a 'has a' relationship with everything in sight. a Person 'has a[n]' Address, a Person 'has a[n]' account, a Person 'has a' Doughnut etc etc etc Also, inevitably a Person 'is a' Customer, a Person 'is a' Contact, a Person 'is a' security risk, well you get the idea. Of course this is a problem with the actual design process itself and yes, the identification of the 'nouns in the language of the domain' is an important part of the process. Sorry, but it just works when it's done properly, I know it works as I used this technique to turn around this 'Person as God' design from a failing money pit into a working system that delivered (almost) on time. The very first thing I did was to exorcise Person from the design. I've already managed to write meaningful code but I haven't invented a single class yet. And why do you think this is a problem? A problem? I wasn't ware that I'd stated it was a problem it just You said "BUT [emphasis added] I haven't invented a single class yet", which implies that this is a bad thing [snip] No it implies that I noticed it was possible to do meaningful work in Python without writing a class. Well this HAS been fun, I look forward to your reply but at the moment I have to go and pick some runner beans as it's been a fantastic year for beans and the freezer awaits. lipska -- Lipska the Kat: Troll hunter, sandbox destroyer
Re: [newbie] Looking for a good introduction to object oriented programming with Python
On 07/08/12 06:35, Steven D'Aprano wrote: On Mon, 06 Aug 2012 10:24:10 +0100, lipska the kat wrote: er, the point I was trying to make is that when you say 'interface' it could mean so many things. If you say 'facade' everyone knows exactly what you are talking about. And that is EXACTLY the point. The whole point of design patterns is to avoid getting stuck in incidental implementation details of a particular library or class and look for higher-level design patterns. The same applies to facade -- it's just a special case of the interface pattern. So you AGREE with me, fantastic, what are we arguing about then (it's great fun though isn't it) facade is a SPECIAL case of interface. You seem to be missing this point. I may not be as smart or experienced as you but in my fairly wide experience of software projects of all sizes the biggest problem is one of communication. Design patterns, in my experience help with communication. I have designed and implemented many facades, I have also designed many interfaces. I do not think Java is the be all and end all of programming languages but it has paid off my mortgage and provided me with a good living. Python interests me because it is different. As far as I can see if I'm talking with a Pythonista or a Java developer or a hardware engineer (possibly) or a C++ guru or a university lecturer or an Eiffel developer and I say 'interface' they will all visualise something slightly different, if I say 'facade' they will all (hopefully) know EXACTLY what I am talking about. lipska -- Lipska the Kat: Troll hunter, sandbox destroyer and farscape dreamer of Aeryn Sun -- http://mail.python.org/mailman/listinfo/python-list
Re: [newbie] Looking for a good introduction to object oriented programming with Python
On Mon, 06 Aug 2012 10:24:10 +0100, lipska the kat wrote: > er, the point I was trying to make is that when you say 'interface' it > could mean so many things. If you say 'facade' everyone knows exactly > what you are talking about. And that is EXACTLY the point. The whole point of design patterns is to avoid getting stuck in incidental implementation details of a particular library or class and look for higher-level design patterns. The same applies to facade -- it's just a special case of the interface pattern. Why get stuck in incidental implementation details of the particular *kind* of interface layer you need? Obviously the person writing the interface/facade/adaptor/whatever needs to understand the implementation details. But the people using the interface don't. Why waste brain CPUs trying to decide whether a particular interface is a facade, an adaptor, a bridge, a proxy, ... ? Especially since in real- life code, any such interface is going to include elements of all of the above. Take this example from Wikipedia's article on Facade pattern: = PatternIntent = AdapterConverts one interface to another so that it matches what the client is expecting Decorator Adds responsibility to the interface without altering it Facade Provides a simplified interface = It's rare that the intent is as pure as that. Normally it will be: "Simplify the interface, oh and also change the API of these three methods to match this other library, and add a couple of helper methods, and while you're at it, this method has a bug that upstream refuses to patch, do something about that." So is that a facade or an adaptor, or something else? -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: [newbie] Looking for a good introduction to object oriented programming with Python
On Mon, 06 Aug 2012 09:55:24 +0100, lipska the kat wrote:
> On 06/08/12 01:22, Steven D'Aprano wrote:
>> On Sun, 05 Aug 2012 20:46:23 +0100, lipska the kat wrote:
>>
>>>
>>> Object Oriented programming is a mindset, a way of looking at that
>>> particular part of our world that you are trying to encapsulate in
>>> computer language. The language you use is (should be) irrelevant.
>>
>> That depends on how you define OOP, and in particular, which aspects of
>> OOP your language supports.
>
> The clue is in the name 'Object Oriented' ... anything else is (or
> should be) implementation detail.
So your argument is that any programming which is "oriented" (meaning
what?) towards "objects" (which are...?) is OOP, and everything else is
"implementation detail".
Well now I'm enlightened. That certainly clears that up for me.
> [large snip]
>
>
>> In particularly, terminology varies -- I personally despise with the
>> heat of a thousand suns the terms "instance variable" and "class
>> variable" for attributes or members.
>
> This is an implementation detail and describes the difference between
> certain types of attributes.
Not everything is an "implementation detail". The difference between a so-
called "class variable" (what Python calls a class attribute) and a
"instance variable" (instance attribute) is not an implementation detail,
it is a difference in semantics and function.
As you go on to explain:
> A class variable is static and can be
> accessed without instantiation an instance variable is accessed via an
> instance
which are semantic differences, differences in meaning and function.
>> Since a "string variable" is a variable holding a string, and a "float
>> variable" is a variable holding a float, an instance variable should be
>> a variable holding an instance, and a class variable should be a
>> variable holding a class.
>
> Class variable and instance variable are higher level abstractions.
Of what? Of variables? "Class variables are an abstraction of
variables"... even if true, that's a crappy way to speak. Why should you
use the same word for higher level abstractions that is already used for
lower level abstractions?
I understand that in Java, classes are not first-class (no pun intended)
objects. You can't say:
x = MyClass
and hence talk about x being a variable that holds a class, hence "class
variable". But that's no excuse to overload the term "variable" for
something where there are at least three good names:
attribute
member
property
none of which clash with the normal use of the word "variable".
(Smalltalk gets a pass here -- it was very early days in OOP, and the
terminology wasn't available. But by the time that Java came along, there
was no longer any good justification for overloading a perfectly good
word like variable to mean something different.)
Simply put, the choice of terminology is crap -- attributes of a class/
instance have subtle but real semantic differences from local/global
variables. Attributes belong to an entity (an instance, or a class);
variables do not.
If they were just implementation differences ("local variables live on
the stack, attributes live in the instance struct") it wouldn't matter.
But the semantics are different, and the "instance variable" terminology
is misleading.
But what *really* gets me is not the existence of poor terminology. I
couldn't care less what terminology Java programmers use among
themselves. What gets me is that the ubiquity of them means that
substandard terminology spreads into other languages, like dryrot.
>>> The ONLY concept that you should never try to encapsulate is/are human
>>> beings or their aliases.
>
> snip
>
>> Is this some sort of mystical "humans aren't objects, they're
>> SPECIAL!!!" rubbish? Because it sure sounds like it.
>>
>> Can you give some non-religious reasons why you should not implement
>> human beings or aliases as objects?
>
> You have answered your own question
I'm afraid I have no idea what you mean here. Do you mean that you
*don't* have any non-religious reasons for avoiding Person and User
objects?
How do you feel about Person and User structs, records or fields?
> I would be glad to debate my
> assertion at length with you however the 'moderators' are listening.
There are no moderators on this list. People are free to try using peer
pressure to discourage off-topic discussion, but they can't enforce it.
>>> I've already managed to write meaningful code but I haven't invented a
>>> single class yet.
>>
>> And why do you think this is a problem?
>
> A problem? I wasn't aware that I'd stated it was a problem it just
You said "BUT [emphasis added] I haven't invented a single class yet",
which implies that this is a bad thing in contrast to the good thing that
you became productive in Python very quickly.
> underlines my belief that Python, however useful it is, is not the ideal
> language to learn about Object Oriented softwa
Re: [newbie] Looking for a good introduction to object oriented programming with Python
On 06/08/12 09:55, lipska the kat wrote: On 06/08/12 01:22, Steven D'Aprano wrote: On Sun, 05 Aug 2012 20:46:23 +0100, lipska the kat wrote: snip Well as you seem to be so concerned with terminology I'd have to disagree with you here. An interface (in computing) has any number of meanings, hardware interfaces, software interfaces the HCI etc etc. In some languages an interface is a non functional unit of compilation that describes the methods an implementing class must provide. A facade on the other hand aggregates a number of fine grained operations that often implement the business logic of an application into coarser grained methods that can be called further up the implementation stack. More importantly, what goes on behind a facade can be completely changed without affecting anything that uses the facade thereby enhancing maintainability. (I'm trying really hard not to use buzzwords here). er, the point I was trying to make is that when you say 'interface' it could mean so many things. If you say 'facade' everyone knows exactly what you are talking about. And that is EXACTLY the point. lipska -- Lipska the Kat: Troll hunter, sandbox destroyer and farscape dreamer of Aeryn Sun -- http://mail.python.org/mailman/listinfo/python-list
Re: [newbie] Looking for a good introduction to object oriented programming with Python
On 06/08/12 01:22, Steven D'Aprano wrote:
On Sun, 05 Aug 2012 20:46:23 +0100, lipska the kat wrote:
Object Oriented programming is a mindset, a way of looking at that
particular part of our world that you are trying to encapsulate in
computer language. The language you use is (should be) irrelevant.
That depends on how you define OOP, and in particular, which aspects of
OOP your language supports.
The clue is in the name 'Object Oriented' ... anything else is (or
should be) implementation detail.
[large snip]
In particularly, terminology varies -- I personally despise with the heat
of a thousand suns the terms "instance variable" and "class variable" for
attributes or members.
This is an implementation detail and describes the difference between
certain types of attributes. A class variable is static and can be
accessed without instantiation an instance variable is accessed via an
instance ... again the clue is in the name.
Since a "string variable" is a variable holding a
string, and a "float variable" is a variable holding a float, an instance
variable should be a variable holding an instance, and a class variable
should be a variable holding a class.
Class variable and instance variable are higher level abstractions.
The ONLY concept that you should never try to encapsulate is/are human
beings or their aliases.
snip
Is this some sort of mystical "humans aren't objects, they're SPECIAL!!!"
rubbish? Because it sure sounds like it.
Can you give some non-religious reasons why you should not implement
human beings or aliases as objects?
You have answered your own question I would be glad to debate my
assertion at length with you however the 'moderators' are listening.
If not, let me just say that I reject your prohibition and leave it at
that.
Actually it should really be called Class Oriented programming as
classes are the units of encapsulation.
Incorrect. You don't even need classes to have objects. You can have
class-based OOP, and prototype-based OOP, as in Javascript, Actionscript,
Io, and the language which invented the term, Self.
>
http://en.wikipedia.org/wiki/Prototype-based_programming
Interesting article, I withdraw my 'classed based' assertion however the
concept of a unit of encapsulation still exists. Where unit of
encapsulation is different from a unit of function or method.
I really don't think python is a
good language to learn OO programming, the problem is that Python
doesn't enforce OO so you are never going to learn what is 'OO' and what
isn't.
I think that's exactly why Python *is* a good language to learn OOP,
because you can be productive even while learning. You can start off by
just adding a little bit of OOP syntax to your programs:
Well I'm afraid I can't agree with this. OO is a state if mind (again)
you can't successfully be a 'little bit OO' IMHO
response = raw_input("What do you want to do? ")
response = response.lower() # Look ma, I'm using OOP!
Infantile but funny
snip
I've already managed to write meaningful code but I haven't
invented a single class yet.
And why do you think this is a problem?
A problem? I wasn't aware that I'd stated it was a problem it just
underlines my belief that Python, however useful it is, is not the ideal
language to learn about Object Oriented software development.
Classes are one possible solution to problems that actually matter. What
matters is the solution, not the mechanism of the solution. "Writing
classes" is just a means to an end (the solution), not the end itself.
I couldn't agree more, the point is that they are a good solution. I
learned very early on that there is more than one way to skin a cat. I
have never said that Python is a bad language, I LIKE Python. I
certainly prefer it to Java for on the fly development and it sure is
more fun at times.
There is a book you could try, it's a bit dry and I read it when I can't
sleep, about 30 mins usually does it :-) It's called Design Patterns
snippety snip
In my not-so-humble opinion, the popularity of Design Patterns has a lot
to do with the fact that they are so abstract and jargon-ridden that they
have become a badge of membership into an elite.
Hmm, I feel a rant coming on about elitism ...
snip
and a Facade is just an interface layer.
Well as you seem to be so concerned with terminology I'd have to
disagree with you here. An interface (in computing) has any number of
meanings, hardware interfaces, software interfaces the HCI etc etc. In
some languages an interface is a non functional unit of compilation that
describes the methods an implementing class must provide. A facade on
the other hand aggregates a number of fine grained operations that often
implement the business logic of an application into coarser grained
methods that can be called further up the implementation stack.
More importantly, what goes on behind a facade can be completely changed
without affecting anything th
Re: [newbie] Looking for a good introduction to object oriented programming with Python
Steven D'Aprano writes: >> I suspect), but can't say that I've ever used a "factory function"... > If you've ever used an ordinary function decorator, you almost certainly > have. > If you've every created a closure, you definitely have. Or anything with a __iter__ method... -- http://mail.python.org/mailman/listinfo/python-list
Re: [newbie] Looking for a good introduction to object oriented programming with Python
On Sun, 05 Aug 2012 21:14:04 -0400, Dennis Lee Bieber wrote: > While I've probably used singletons (usually as sentinels in queues, I don't know your code, but if I were to take a wild guess, I would say that apart from None, and True/False, you probably haven't. NotImplemented and Ellipsis are two other singletons in Python. It is possible to program a Singleton class in pure Python, but most people don't bother, because 1) singleton is probably the most over-used Design Pattern of them all and 2) it's quite trivial to bypass the singleton-ness of classes written in Python and create a second instance. Or they use a module, which is not really a singleton but behaves like one. Or if they want to show off their Pythonicity, they use the Borg pattern. The common sentinel idiom in Python is to do this: SENTINEL = object() # and later... if value is SENTINEL: pass but of course that's not a singleton because it's only one instance out of a vast number, and anyone can create another instance. Also it misses the point of the Singleton pattern, that the (lone) instance should hold state. The sentinel does not usually hold state. > I suspect), but can't say that I've ever used a "factory function"... If you've ever used an ordinary function decorator, you almost certainly have. If you've every created a closure, you definitely have. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: [newbie] Looking for a good introduction to object oriented programming with Python
On 06/08/2012 01:22, Steven D'Aprano wrote: [snipped to death] In my not-so-humble opinion, the popularity of Design Patterns has a lot to do with the fact that they are so abstract and jargon-ridden that they have become a badge of membership into an elite. Shorn of their excessive abstractness, they're not very special. People were writing helper functions to assemble complex data long before the Builder pattern was named, and a Facade is just an interface layer. Design patterns being abstract and jargon ridden puts them alongside many other aspects of ICT, CS, call it what you like. Especially beloved by consultants as it means they can talk crap for hours and charge a fortune for it. -- Cheers. Mark Lawrence. -- http://mail.python.org/mailman/listinfo/python-list
Re: [newbie] Looking for a good introduction to object oriented programming with Python
On Sun, 05 Aug 2012 20:46:23 +0100, lipska the kat wrote:
>
> Object Oriented programming is a mindset, a way of looking at that
> particular part of our world that you are trying to encapsulate in
> computer language. The language you use is (should be) irrelevant.
That depends on how you define OOP, and in particular, which aspects of
OOP your language supports.
There are lots of differences between styles and implementations of OOP
languages, and no two languages have exactly the same feature set, but in
general most OOP languages involve most of the following features:
- Dynamic dispatch when making method calls
- Encapsulation, or multi-methods
- Subtype polymorphism
- Object inheritance, or delegation
See here for more detail:
http://en.wikipedia.org/wiki/Object-oriented_programming#Fundamental_features_and_concepts
But beyond those fundamentals, the details of OOP can differ greatly from
language to language. Some languages treat classes as static, some as
dynamic. Some languages treat classes as objects themselves, others treat
them as non-objects. Syntax varies (although the dot operator has become
almost completely ubiquitous, there are still some exceptions).
In particularly, terminology varies -- I personally despise with the heat
of a thousand suns the terms "instance variable" and "class variable" for
attributes or members. Since a "string variable" is a variable holding a
string, and a "float variable" is a variable holding a float, an instance
variable should be a variable holding an instance, and a class variable
should be a variable holding a class.
> The ONLY concept that you should never try to encapsulate is/are human
> beings or their aliases. So Person, User, Human etc should not exist in
> any way shape or form in your design. There is an argument that User is
> ok but I don't subscribe to that.
>
> If you want to represent human interaction in your software design use
> Account or Session or some other non human noun.
Is this some sort of mystical "humans aren't objects, they're SPECIAL!!!"
rubbish? Because it sure sounds like it.
Can you give some non-religious reasons why you should not implement
human beings or aliases as objects?
If not, let me just say that I reject your prohibition and leave it at
that.
> Actually it should really be called Class Oriented programming as
> classes are the units of encapsulation.
Incorrect. You don't even need classes to have objects. You can have
class-based OOP, and prototype-based OOP, as in Javascript, Actionscript,
Io, and the language which invented the term, Self.
http://en.wikipedia.org/wiki/Prototype-based_programming
> I really don't think python is a
> good language to learn OO programming, the problem is that Python
> doesn't enforce OO so you are never going to learn what is 'OO' and what
> isn't.
I think that's exactly why Python *is* a good language to learn OOP,
because you can be productive even while learning. You can start off by
just adding a little bit of OOP syntax to your programs:
response = raw_input("What do you want to do? ")
response = response.lower() # Look ma, I'm using OOP!
while still being primarily procedural. Then you can gradually learn the
terminology ("what's an instance?"), graduate to writing your own
classes, and then finally move on to OOP techniques which some languages
don't even allow, like metaclasses.
> Before I get told off/flamed/shouted at I've just started learning
> Python and I think it is a great language with a fantastic standard
> library. I've already managed to write meaningful code but I haven't
> invented a single class yet.
And why do you think this is a problem?
Classes are one possible solution to problems that actually matter. What
matters is the solution, not the mechanism of the solution. "Writing
classes" is just a means to an end (the solution), not the end itself.
> There is a book you could try, it's a bit dry and I read it when I can't
> sleep, about 30 mins usually does it :-) It's called Design Patterns by
> Gamma, Helm, Johnson and Vlissides ISBN 0-201-63361-2.
> They do use C++ code in examples but as they say, this is just a
> convenience and shouldn't colour your view of the subject I still read
> the introduction and get something out of it after several years. You
> should be able to implement the patterns in Python although I must admit
> I haven't tried that yet
Two problems with "Design Patterns" is that many of them are excessively
abstract, and that often they only exist to work around limitations in
the source language (usually C++ or Java).
The first problem means that any half-decent programmer has probably been
using "Design Patterns" for years without realising it, or knowing the
name. I remember writing an "Object Pool" in procedural Pascal in the
1980s to recycle resources, long before the concept was given a name. Not
that I claim to have invented the concept -- I merely copied it from
some
Re: [newbie] Looking for a good introduction to object oriented programming with Python
On 05/08/2012 20:46, lipska the kat wrote: > Design Patterns by Gamma, Helm, Johnson and Vlissides In article , Mark Lawrence wrote: > Please no, that's the worst possible book for someone trying to learn > OOD in Python. +1 what Mark said. It's certainly the classic patterns book, but most of it is about clever ways to work around the C++/Java style of type bondage. Trying to learn OO from that book is like learning to paint by reading a textbook on the chemical properties of oil pigments. -- http://mail.python.org/mailman/listinfo/python-list
Re: [newbie] Looking for a good introduction to object oriented programming with Python
On 05/08/2012 20:46, lipska the kat wrote: [snip] There is a book you could try, it's a bit dry and I read it when I can't sleep, about 30 mins usually does it :-) It's called Design Patterns by Gamma, Helm, Johnson and Vlissides ISBN 0-201-63361-2. They do use C++ code in examples but as they say, this is just a convenience and shouldn't colour your view of the subject I still read the introduction and get something out of it after several years. You should be able to implement the patterns in Python although I must admit I haven't tried that yet Please no, that's the worst possible book for someone trying to learn OOD in Python. It's mostly if not completely irrelevant, jumping through hoops that you don't need in Python because of its dynamic nature. Start with the factory pattern and I hope you'll understand why I say this. Search for "design patterns alex martelli" and you'll get all you need and more. lipska -- Cheers. Mark Lawrence. -- http://mail.python.org/mailman/listinfo/python-list
Re: [newbie] Looking for a good introduction to object oriented programming with Python
On 04/08/12 16:49, Jean Dubois wrote: I'm looking for a good introduction to object oriented programming with Python. Object Oriented programming is a mindset, a way of looking at that particular part of our world that you are trying to encapsulate in computer language. The language you use is (should be) irrelevant. The ONLY concept that you should never try to encapsulate is/are human beings or their aliases. So Person, User, Human etc should not exist in any way shape or form in your design. There is an argument that User is ok but I don't subscribe to that. If you want to represent human interaction in your software design use Account or Session or some other non human noun. Actually it should really be called Class Oriented programming as classes are the units of encapsulation. I really don't think python is a good language to learn OO programming, the problem is that Python doesn't enforce OO so you are never going to learn what is 'OO' and what isn't. Before I get told off/flamed/shouted at I've just started learning Python and I think it is a great language with a fantastic standard library. I've already managed to write meaningful code but I haven't invented a single class yet. Apologies if this sound negative, it's not meant to be it's meant to be constructive. There is a book you could try, it's a bit dry and I read it when I can't sleep, about 30 mins usually does it :-) It's called Design Patterns by Gamma, Helm, Johnson and Vlissides ISBN 0-201-63361-2. They do use C++ code in examples but as they say, this is just a convenience and shouldn't colour your view of the subject I still read the introduction and get something out of it after several years. You should be able to implement the patterns in Python although I must admit I haven't tried that yet Learn Python by all means, the interactive mode is particularly fun,just try and get a good idea of what OO is all about before you start. Just my opinion lipska -- Lipska the Kat: Troll hunter, sandbox destroyer and farscape dreamer of Aeryn Sun -- http://mail.python.org/mailman/listinfo/python-list
Re: [newbie] Looking for a good introduction to object oriented programming with Python
I found Mark Lutz's book Learning Python had two or three chapters on object oriented programming from starting principles to more involved Python object programming. It helped me immensely. -- http://mail.python.org/mailman/listinfo/python-list
Re: [newbie] Looking for a good introduction to object oriented programming with Python
One reason you may be having difficulty is that unlike some languages (C++/Java) object-orientation is not a be all and end all in Python, in fact you could work with Python for a long time without really 'doing it' at all (well other than calling methods/properties on existing API's). Having said that here's what I would suggest ... Could do worse than this : http://www.diveintopython.net/object_oriented_framework/index.html and this http://docs.python.org/tutorial/classes.html read together. Judging by your question this is a probably a little advanced for now but you could bookmark it for the future: http://www.catonmat.net/blog/learning-python-design-patterns-through-video-lectures/ Here's the corresponding PDF to go with the video: http://assets.en.oreilly.com/1/event/45/Practical%20Python%20Patterns%20Presentation.pdf -- http://mail.python.org/mailman/listinfo/python-list
