super
Missive #02441: super() If you're going to use object composition, creating a super (no pun intended) class, you are forming an explicit object hierarchy (unlike mix-in style). In this case, if the method exists in the parent class, you shouldn't give the user (or subclass) the choice of calling super because it will break the concept of PARENT. The other VERY GOOD reason is that there's no question about initialization order. A subclass can sometimes call other methods. If those methods also are in the super class you have condition where you can't quite tell what is happening where. When the hierarchy of calls is well-defined because you can rely on super call order, then there's *no problem*. Please direct questions to my hand. Mark -- https://mail.python.org/mailman/listinfo/python-list
Re: Language design
On Wednesday, September 11, 2013 at 6:40:22 PM UTC-5, Steven D'Aprano wrote: > On Wed, 11 Sep 2013 14:30:54 -0700, Mark Janssen wrote: > > > 1) It tried to make Object the parent of every class. > > Tried, and succeeded. Oh? How about: class superdict(dict): """I'm going to extend the dict type to include extra methods.""" class mixin(): """Here we go.""" What is the parent of mixin? > > No one's close enough to God to make that work. > > Non-sequitor. One doesn't need to be close to a deity to have a single > root of the object hierarchy. Loud voice: Boom! > > 4?) It allowed > > [reference] variables to be used as dict keys. This creates a parsing > > difficulty for me, mentally. Keys should be direct, hashable values, > > not hidden in a variable name. > > I don't even understand what you are talking about here. "[reference] > variables"? What does that mean? Nevermind. I was wrong on this one. My mental lexer threw an error on this one whenever ppl used a variable as a key. Cheer! Mark -- https://mail.python.org/mailman/listinfo/python-list
Re: Language design
On Friday, September 13, 2013 at 12:08:04 AM UTC-5, Steven D'Aprano wrote: > On Thu, 12 Sep 2013 20:23:21 -0700, Mark Janssen wrote: > which would be silly. Only somebody who doesn't understand how > inheritance works in Python would do that. There's simply no need for it, > and in fact it would be actively harmful for larger hierarchies. > > >>> But wait is it the "base" (at the bottom of the hierarchy) or is it > >>> the "parent" at the top? You see, you, like everyone else has been > >>> using these terms loosely, confusing yourself. > >> > >> Depends on whether I'm standing on my head or not. > >> > >> Or more importantly, it depends on whether I visualise my hierarchy > >> going top->down or bottom->up. Both are relevant, and both end up with > >> the *exact same hierarchy* with only the direction reversed. > > > > Ha, "only the direction reversed". That little directionality that > > you're passing by so blithely is the difference between whether you're > > talking about galaxies or atoms. > > It makes no difference whether I write: > > atoms -> stars -> galaxies > > or > > galaxies <- stars <- atoms > > nor does it make any difference if I write the chain starting at the top > and pointing down, or at the bottom and pointing up. Yes it does. Ford IS-A Car, but Car IS-A Ford? No. Try reordering that one. I see we've missed each other with our limitations to ASCII text, in ways that would have never happened had these conversations occurred in person. Re-reading my texts, I see that I can easily confuse myself. > "not someone wanting to understand the limitations of python..." -- are > you aware that I started this thread? Yes, but did you? LOL. Mark -- https://mail.python.org/mailman/listinfo/python-list
Re: Everything is an object in python - object class and type class
On Monday, June 1, 2015 at 7:03:49 AM UTC-5, Eddilbert Macharia wrote: > I think i kind of understand now. > > Instead of python having data types like int, string, e.t.c it has two > primitive types which are class type and class object which are created by > python interpreter during its setup .using this two classes python is able to > create some more data types Eddibert, don't let this crowd (Terry, Stephen, et al.) confuse you. They are as confused about it as you are. The truth is, that they've told a lie to themselves (everything is an object) to hide some details FROM THEMSELVES in their model. They climb a ladder of ambiguity anytime there's a new problem in their model and call it a "type", or they pull out the "metaclass" term (because no one really knows that that is, so they feel *pretty* safe). A type is not an object in the same way an instantiated type is an object -- anymore than a blueprint for a building is the building itself. The reason this confusion appears is for the exact reason I said on an earlier thread: Python does not define classes in it's grammar -- so it can't account for the difference between an [instantiated] object and it's definition/type. Mark -- https://mail.python.org/mailman/listinfo/python-list
Re: Everything is an object in python - object class and type class
On Monday, June 1, 2015 at 7:33:11 PM UTC-5, Chris Angelico wrote: > On Tue, Jun 2, 2015 at 10:24 AM, TheDoctor wrote: > > A type is not an object in the same way an instantiated type is an object > > -- anymore than a blueprint for a building is the building itself. > > And don't let dreamingforward confuse you, because he is flat-out > wrong. An integer is an object, because you can manipulate it as one. An integer in Python *acts* like an object, in some narrow sense can indeed be said to BE one. But no one uses them like that in practice (purity was trying to beat practicality in the case of ints) -- they use them like ints, with the extra super-nice shortcuts of having them arbitrarily-sized. And that was available before the type-class unification. > A function is an object. A dictionary is an object. Yep. > And a type is an > object too. OOPs. Mark -- https://mail.python.org/mailman/listinfo/python-list
Re: Everything is an object in python - object class and type class
On Monday, June 1, 2015 at 7:33:11 PM UTC-5, Chris Angelico wrote: > And a type is an > object too. There is no significant difference here. Let me make this clearer to you, Chris, because I don't want you to have to suck it too, like the rest of this community. A type is not an object. You see it as one, because you are MENTALLY lexing your own code on the screen. But python does not define a type. It defines certain primitives, like strings and integers. But it doesn't define what an OBJECT is. So you and everyone else are beating around the bush trying to define something that the LANGUAGE ITSELF doesn't define. So, don't make a claim about it. In Python 2.7 type(type) is type (not object), but isinstance(type, object) is true -- so it is ambiguous, even contradictory, in the language. Boom. Suck it. Mark -- https://mail.python.org/mailman/listinfo/python-list
Re: Message passing syntax for objects | OOPv2
On Thursday, May 9, 2013 at 12:39:37 AM UTC-5, Steven D'Aprano wrote: > On Wed, 08 May 2013 19:35:58 -0700, Mark Janssen wrote: > > > Long story short: the lambda > > calculus folks have to split from the Turing machine folks. > > These models of computation should not use the same language. Their > > computation models are too radically different. > > Their computation models are exactly equivalent. No. Church's thesis was a thesis. So, yes in theory they can be made to be equivalent. In practice, it's not. Practicality beats purity, remember? > This is like saying that Cartesian coordinates and polar coordinates are > so radically different that they cannot possibly both describe the same > space. Good analogy, they in theory have the same descriptive potential. In practice, you never do it. Mark Ho Hum...getting back to some old threads. -- https://mail.python.org/mailman/listinfo/python-list
Re: Everything is an object in python - object class and type class
> > A type is not an object in the same way an instantiated type is an object > > -- anymore than a blueprint for a building is the building itself. > > Point 1 > > Yes. You may be onto something here Mark [I assume that's your name]. > Some very intelligent people have suggested that the sloppy use of 'is' > causes more misunderstanding than any useful communication. > See http://en.wikipedia.org/wiki/E-Prime. Ah, yes. Very good. Probably relevant. > And in "Gödel, the Mind and the Laws of Physics" Roger Penrose draws a > picture > of Three worlds and the mysteries that connect them > http://sustainedreaction.yuku.com/topic/4931/Three-Worlds-Three-Mysteries#.VW0b9rzGI8o Amazing you reference that site. I used to interact with Ghost Dog who's referenced at the bottom of that post. Are you familiar with sustainedaction.org? > 1. The mathematical world > 2. The mental world > 3. The physical world > > which means that the 'is' in each is different. Yes. That's good. > As enumerated here http://blog.languager.org/2015/03/cs-history-0.html > the history and very existence of CS has arisen from grapping with these > questions. Interesting, will read up more. > Point 2: [unrelated to the content of the OP] > You may wish to consider whether your style and the names you keep assuming > and changing are helping you. Best I can see many people have begun to > killfile you. Yes, I know. The names change based on mood. The canonical address remains the same. People are dumb, but perhaps I am dumb for treating them as equals. Perhaps that's not a fair assumption. I thought it was polite. It's quite clear, that there's a bit of religion here and when I come in and point it out, they pull out their Bible and cast me out. I get too weary to explain more. You know how it is arguing to evangelical Christians. Perhaps another time. Mark, one of my real names. -- https://mail.python.org/mailman/listinfo/python-list
Re: Everything is an object in python - object class and type class
On Monday, June 1, 2015 at 11:09:09 PM UTC-5, [email protected] wrote: > On Mon, Jun 1, 2015, at 20:24, TheDoctor wrote: > > A type is not an object in the same way an instantiated type is an object > > -- anymore than a blueprint for a building is the building itself. > > What is an object? > > It's something you can call str or repr on. It's something you can > lookup attributes from its internal dictionary and call methods on. It's > something you can compare whether it's == to something else. It's > something you can pass as a parameter to a function That's good material for relating to the issue. I wish I could justify my position better, but it gets into non-computational arguments. > In many languages, you can't do any of these things (or their > equivalents for those languages) to a type. In others, you have to get a > special "class object" that isn't _really_ the same thing as the type > itself, via some special syntax like typeof(Foo) or Foo.class, and can > only work with it through magic methods in a certain module. > > In python, you can. Why is this bad or confusing? It breaks a conceptual barrier. It's like the difference between seeing an ASCII character symbol and knowing the 8-bit binary digits. One is a name, the other is the data. That's an important distinction and they shouldn't be confused in the machine (which can't happen because the machine already creates that boundary). In the case of the reader though, they can get confused -- they're not interchangeable. They get "lexed" in the head very differently. Mark -- https://mail.python.org/mailman/listinfo/python-list
