Re: an oop question
On 2/11/22 9:54 am, Julieta Shem wrote: But we've left behind a more basic requirement --- the Stack class wishes for all the methods already written in some class called Pair, Is that *really* what you want, though? To my way of thinking, a Stack and a Pair are quite different data structures, each having their own characteristic operations. Things I want to be able to do with a Stack: - Create an empty stack - Push an item onto the top of the stack - Pop an item off the top of the stack Things I want to be able to do with a Pair: - Create a pair containing two given objects - Get the first item - Get the second item I don't see any overlap between these at the conceptual level. Possibly I might want to use Pairs as part of the *implementation* of a stack, but that doesn't mean that any Pair methods should appear as Stack methods. Here's how I might do this in a functional style using Python: class Pair: def __init__(self, first, second): self._first = first self._second = second def first(self): return self._first def second(self): return self._second class Stack: def __init__(self): self._data = None def push(self, item): result = Stack() result._data = Pair(item, self._data) return result def pop(self): rest = Stack() rest._data = self._data.second() return self._data.first(), rest Note that neither Stack nor Pair inherits from the other. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: an oop question
On 01/11/2022 17:58, Julieta Shem wrote: > nowhere in trying to detect in high-precision what is OOP and what is > not. Stefan has given a good answer but essentially OOP is a program that is structured around objects communicating by sending messages to one another. Objects are, in most (but not all) languages implemented using classes. A class is just a record or structure that can contain data and functions. In most (but not all) implementations of OOP messages are implemented as calls to the functions within an objects class. > The same for classes. I always liked to think of C structures as > some class. Provided that we allow pointers to functions within the struct then yes. Indeed the difference between structs and classes in C++ is very thin. And with the recent introduction of data classes in Python the boundaries are blurred here too. In pure OOP a class with only data would be pointless(since the data should ideally be hidden or "private"!) > structure Whatever si the class itself. Is this use of C outside of > OOP? I say it is not because my notion of OOP is that --- a way to make > objects and have methods operate on them, changing them or not. It's how many early attempts at OOP in C worked, including C++. Others, such as Objective C and cFlavours took a different approach. But conceptually methods do not "operate on objects" methods are how objects respond to messages. Eah object has its own method of handling a particular message. (This is polymorphism) In most (but not all) practical implementations methods are usually implemented as functions and so it seems like a message is just a synonym for acalling a method, but is more than that, it implies some kind of dynamic lookup. (for example when the method is implemented in a paremt class rather than the directly referenced one. But the functions that represent methods do indeed operate on their own object - ie self. > To me what distinguishes functional from imperative is, Not that imperative programming is not the same as OOP. Or at least it encompasses much more than OOP. Most OOP programs are written in imperative languages but it is possible to have functional OOP programs too. (If we consider the state data to be a single compound value that can only be changed by the object internally, or a new object with different state values returned.) >> IS-A relationship, so Stack inheriting Pair would mean that a Stack >> was a Pair. That is not really true. > > That's another interesting observation. I do not have much > understanding of how to really think of these things Read up on the Liskoff substitution principle as one approach to determining what an IS-A relationship means. Its not the only approach but it is less vague than some others! >> to complications. If in doubt use delegation instead. > > What is delegation? A fancy OOP term to mean containment. Specifically a method delegates the work top some internal object. eg. You can build a stack by containg a list within it. The stack delegates much of the work to the list object. In fact, in Python a stack can be a very thin wrapper over a list! > Any book recomendations on getting this thing mathematics-clear? The best book is IMHO Bertrand Meyer's book "Object Oriented Software Construction". It uses his own language,. Eiffel, but gives an excellent description of applied OOP and all of its features (Eiffel is perhaps the most feature complete OOPL of all - but, being proprietary (and somewhat buggy!) it has never quite caught on) But for a mathematical basis you need to look outside programming at systems engineering and the work done on cellular automata. In a pure OOP program each object should act as an independant cell communicating by asynchronous messages. Exactly as in cellular automata theory. .. Unfortunately, there is a huge gap between pure OOP theory and practical OOP languages! And just as big a gap between OOP language potential and real-world OOP usage. Very few purely OOP programs exist (maybe excepting in Smalltalk - see Stefan's posts again). :-( -- Alan G Author of the Learn to Program web site http://www.alan-g.me.uk/ http://www.amazon.com/author/alan_gauld Follow my photo-blog on Flickr at: http://www.flickr.com/photos/alangauldphotos -- https://mail.python.org/mailman/listinfo/python-list
Re: Operator: inappropriate wording?
Le lundi 31 octobre 2022 à 22:18:57 UTC+1, Chris Angelico a ecrit : > Wording is hard. Just ask the SQL standard whether NULL is a value. > Indeed, but I think our problem here is simpler ;) One could for example omit the incorrect term "operator" while remaining unambiguous. This would give: If the object is a class instance and the attribute reference occurs on both sides of the assignment, the right-hand side expression,... Now, as for the other formulation from the reference document: The second half of the list, the augmented assignment operators, serve lexically as delimiters, but also perform an operation. (link: https://docs.python.org/3/reference/lexical_analysis.html#delimiters) it is incorrect (as explained by the FAQ I quoted in my last post) and the explanations it gives are even more incorrect suggesting that anything that performs an operation is the result of the action of an operator. Under these conditions, we could say that del is an operator and even that return is an operator! I opened an issue on the CPython GitHub repository, here: https://github.com/python/cpython/issues/98814 -- https://mail.python.org/mailman/listinfo/python-list
Re: [correction]an oop question
On 02/11/2022 20:21, Dennis Lee Bieber wrote: >> shows that in Python we do *not* need subclassing/inheritance >> for polymorphism! >> > To me, that is not really an example of polymorphism, but more an > example of Python's "duck typing". But duck typing is a perfectly good implementation of polymorphism. The term just means that different objects respond to the same message in different ways. Nothing more, nothing less. Inheritance just happens to be the most common way of building that, especially in statically typed languages. > > I'd implement the example hierarchy as > class Language: > ... def f(self): > ... print(self.greeting) And that would be perfectly valid too. -- Alan G Author of the Learn to Program web site http://www.alan-g.me.uk/ http://www.amazon.com/author/alan_gauld Follow my photo-blog on Flickr at: http://www.flickr.com/photos/alangauldphotos -- https://mail.python.org/mailman/listinfo/python-list
Re: an oop question
Greg Ewing writes: > On 2/11/22 9:54 am, Julieta Shem wrote: >> But we've left behind a more basic requirement --- the Stack >> class wishes for all the methods already written in some class called >> Pair, > > Is that *really* what you want, though? > > To my way of thinking, a Stack and a Pair are quite different > data structures, each having their own characteristic operations. > > Things I want to be able to do with a Stack: > - Create an empty stack > - Push an item onto the top of the stack > - Pop an item off the top of the stack > > Things I want to be able to do with a Pair: > - Create a pair containing two given objects > - Get the first item > - Get the second item > > I don't see any overlap between these at the conceptual level. > Possibly I might want to use Pairs as part of the *implementation* > of a stack, but that doesn't mean that any Pair methods should > appear as Stack methods. The code for computing the length of a Pair (which is really a linked list) happens to be the same for computing the length of a Stack. My class Pair has methods map, filter, reduce, ... Stacks could use them too. > Here's how I might do this in a functional style using Python: > > class Pair: > def __init__(self, first, second): > self._first = first > self._second = second > def first(self): > return self._first > def second(self): > return self._second > > class Stack: > def __init__(self): > self._data = None > def push(self, item): > result = Stack() > result._data = Pair(item, self._data) > return result > def pop(self): > rest = Stack() > rest._data = self._data.second() > return self._data.first(), rest > > Note that neither Stack nor Pair inherits from the other. That works too. -- https://mail.python.org/mailman/listinfo/python-list
Re: an oop question
r...@zedat.fu-berlin.de (Stefan Ram) writes:
> Julieta Shem writes:
>>Any book recomendations on getting this thing mathematics-clear?
>
> OOP cannot be mathematics-clear because it is an /attempt/ to
> abstract from several different programming languages.
>
> When you ask Alan Kay (and I did!), the man who coined the term
> "object-oriented", he will tell you (in my words):
> "Object-oriented programming is possible in Smalltalk only.".
That's very interesting. Would you share the complete thread of e-mail?
I would love to read it word for word.
> So, to get OOP crystal clear from the one who coined the
> term, go ahead an learn Smalltalk!
After your message, I looked up
THE EARLY HISTORY OF SMALLTALK
https://dl.acm.org/doi/pdf/10.1145/234286.1057828
and gave it a read. Very nice read.
> But while Kay coined the term, many ideas of OOP are based
> on Simula. So, you might think about learning Simula to get
> the Dahl-flavor of OOP.
>
> This is comp.lang.python. Here we do Python programming.
The impression I got from Smalltalk in the paper above was that Python
is so much based on it.
> 10 or 20 years ago there were still famous people, such as
> Robert C. Martin, hanging around in "comp.object", and I would
> have told you to go there, but today that newsgroup is deserted.
So sad.
> Here's an excerpt from an older post by me, written in May this year:
>
> In 2003, I became aware of the fact that Alan Kay, the man
> who coined the term "object-oriented programming" in 1967
> (or in the temporal proximity of this year), never has given
> a definition for it. I asked him via e-mail, and he kindly
> responded. In that e-mail he also wrote something to the effect
> that for him only Smalltalk allows object-oriented programming.
> (On another occasion, he also said, "I invented the term Object-
> Oriented and I can tell you I did not have C++ in mind.".) So,
> I think that this point of view by Alan Kay is similar to what
> Liam wrote about Smalltalk!
>
> So, what did Alan Kay write to me in 2003? Here's the crucial excerpt:
>
> |OOP to me means only messaging, local retention and protection and
> |hiding of state-process, and extreme late-binding of all things. It
> |can be done in Smalltalk and in LISP. There are possibly other
> |systems in which this is possible, but I'm not aware of them.
> Alan Kay, 2003
I'm wondering how Python fails to satisfy his definition.
> . I should add that the deepest insight I gained into what is the
> actual point of OOP (as I wrote in my previous post in this thread)
> I got from the writings of Robert C. Martin who clarified that
> OOP makes it easy to add new types but hard to add new operations,
> while procedural programming makes it easy to add new operations,
> but hard to add new types.
>
> |Procedural code (code using data structures) makes it easy to
> |add new functions without changing the existing data
> |structures. OO code, on the other hand, makes it easy to add
> |new classes without changing existing functions.
> Robert Cecil Martin
>
> |Procedural code makes it hard to add new data structures
> |because all the functions must change. OO code makes it hard
> |to add new functions because all the classes must change.
> Robert Cecil Martin
>
> When one first reads this, it might not be obvious why this
> is so spot on, but one can find this quotation in the book
> "Clean Code" by Robert C. Martin and read more explanations
> about it there.
Thank you for the reference. His comments make sense to me, although
it's not crystal-clear. I'll eventually read his book.
> Objects with data abstraction can already be found in CLU by
> Barbara Liskov. But this is not yet OOP. The crucial feature
> OOP adds to this is polymorphism ("late binding").
That's helpful. I saw Alan Kay talking about late binding in the paper
I mentioned above. Thank you so much.
--
https://mail.python.org/mailman/listinfo/python-list
Re: [correction]an oop question
Dennis Lee Bieber writes: > On 2 Nov 2022 09:56:28 GMT, r...@zedat.fu-berlin.de (Stefan Ram) declaimed > the following: > > >> Now, in the next program, I have removed the subclassings, >> there is no inheritance from the base class "Language" >> anymore. Yet the polymorphism in "f" still works. And this >> shows that in Python we do *not* need subclassing/inheritance >> for polymorphism! >> > To me, that is not really an example of polymorphism, but more an > example of Python's "duck typing". > > I'd implement the example hierarchy as > class Language: > ... def f(self): > ... print(self.greeting) > ... class English(Language): > ... def __init__(self): > ... self.greeting = "Good Morning" > ... class French(Language): > ... def __init__(self): > ... self.greeting = "Bonjour" > ... English().f() > Good Morning French().f() > Bonjour > > ... with no explicit /function/ for greeting -- it's just an attribute > set in each subtype, inheriting the "f" function for printing. A popular encyclopedia would enumerate various specifications of the word polymorphism. Ad hoc polymorphism, parametric polymorphim, subtype polymorphim et cetera. ``One of the most difficult matters in all controversy is to distinguish disputes about words from disputes about facts: it ought not to be difficult, but in practice it is.'' -- ABC of Relativity, Bertrand Russell, chapter 12, 1925. ``What's in a name?'' -- Romeo and Juliet, Shakespeare, 1597. -- https://mail.python.org/mailman/listinfo/python-list
Re: an oop question
Alan Gauld writes: > On 01/11/2022 17:58, Julieta Shem wrote: [...] >>> IS-A relationship, so Stack inheriting Pair would mean that a Stack >>> was a Pair. That is not really true. >> >> That's another interesting observation. I do not have much >> understanding of how to really think of these things > > Read up on the Liskoff substitution principle as one approach to > determining what an IS-A relationship means. Its not the only > approach but it is less vague than some others! Thanks so much for the references. I'll definitely look up the Liskov substitution principle and try to understand it. More on this soon. Thanks also for the Meyer's reference too, the explanation of ``delegation'' and all your comments. I appreciate it. -- https://mail.python.org/mailman/listinfo/python-list
Re: an oop question
On 3/11/22 1:37 pm, Julieta Shem wrote: The code for computing the length of a Pair (which is really a linked list) happens to be the same for computing the length of a Stack. I would question whether that should be a method of Pair at all, since it's not the length of the pair itself, but the length of a structure built out of pairs. But in any case, the way to do this in a conceptually clean way is for the length method of Stack to call whatever it is that computes the length of a linked list of Pairs. This is what the term "delegation" refers to. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: an oop question
r...@zedat.fu-berlin.de (Stefan Ram) writes: > Greg Ewing writes: >>I don't see any overlap between these at the conceptual level. > > It might come from early LISP dialects. In early LISPs, the > only basic means to combine data into a larger assembly of > data was the dotted pair and NULL (as an end marker). So, > whenever you wanted to create a data structure, you would > wonder how to build it from dotted pairs and NULLs. > > You also had lists, of course, but these were themselves build > from dotted pairs and NULLs, as I explained in a recent post. > > (I wrote "early LISP", because I don't know much about modern > "Lisp" dialects.) > > And when people learn a new (programming) language, until they > become more confident in it, they start to emulate their > previous language(s) in it. Writing FORTRAN in Pascal, and > so on. So when you know Clojure and then come to Python, you > might wonder how to do Clojure things in Python. (Clojure > is a kind of Lisp.) And that's very interesting. It's a nice evidence of that conjecture that the languages we use affect the way we see things. Noam Chomsky has been saying that the primary function of language is to be a tool of thought rather than communication; communication is definitely important and real, but not the primary reason why language was developed. -- https://mail.python.org/mailman/listinfo/python-list
typing: property/setter and lists?
Hi! And a typing problem again!!! ___ class C: def __init__(self): self.__foos=5*[0] @property def foos(self) -> list[int]: return self.__foos @foos.setter def foos(self,v: int): self.__foos=[v for __i in self.__foos] c=C() c.foos=5 print(c.foos) ___ mypy gives the following error: error: Incompatible types in assignment (expression has type "int", variable has type "List[int]") How do I turn around this? Thanks. Paulo -- https://mail.python.org/mailman/listinfo/python-list
