Re: interactive help on the base object
On 17/01/2014 01:00, Terry Reedy wrote: On 12/6/2013 8:35 PM, Terry Reedy wrote: On 12/6/2013 12:03 PM, Mark Lawrence wrote: Is it just me, or is this basically useless? help(object) Help on class object in module builtins: class object | The most base type Given that this can be interpreted as 'least desirable', it could definitely be improved. Surely a few more words, How about something like. '''The default top superclass for all Python classes. Its methods are inherited by all classes unless overriden. ''' When you have 1 or more concrete suggestions for the docstring, open a tracker issue. At Mark's invitation, I have done so. http://bugs.python.org/issue20285 Thanks, I've altered my will accordingly :) -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: interactive help on the base object
- Original Message - On 17/01/2014 01:00, Terry Reedy wrote: On 12/6/2013 8:35 PM, Terry Reedy wrote: On 12/6/2013 12:03 PM, Mark Lawrence wrote: Is it just me, or is this basically useless? help(object) Help on class object in module builtins: class object | The most base type Given that this can be interpreted as 'least desirable', it could definitely be improved. Surely a few more words, How about something like. '''The default top superclass for all Python classes. Its methods are inherited by all classes unless overriden. ''' When you have 1 or more concrete suggestions for the docstring, open a tracker issue. At Mark's invitation, I have done so. http://bugs.python.org/issue20285 Thanks, I've altered my will accordingly :) -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence The issue is tagged 2.7. Is object the superclass of all classes in 2.7 ? I'm asking because in 2.5, it is not (old/new style). JM -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- https://mail.python.org/mailman/listinfo/python-list
Re: interactive help on the base object
On 1/17/2014 7:25 AM, Jean-Michel Pichavant wrote: '''The default top superclass for all Python classes. http://bugs.python.org/issue20285 The issue is tagged 2.7. Is object the superclass of all classes in 2.7 ? 2.7 should say 'all new-style classes'. Thanks for noticing and reporting. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: interactive help on the base object
On 12/6/2013 8:35 PM, Terry Reedy wrote: On 12/6/2013 12:03 PM, Mark Lawrence wrote: Is it just me, or is this basically useless? help(object) Help on class object in module builtins: class object | The most base type Given that this can be interpreted as 'least desirable', it could definitely be improved. Surely a few more words, How about something like. '''The default top superclass for all Python classes. Its methods are inherited by all classes unless overriden. ''' When you have 1 or more concrete suggestions for the docstring, open a tracker issue. At Mark's invitation, I have done so. http://bugs.python.org/issue20285 -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: interactive help on the base object
On 10/12/2013 05:16, rusi wrote: On Tuesday, December 10, 2013 10:40:27 AM UTC+5:30, Steven D'Aprano wrote: By the way, I'm curious. Why are discussions about object oriented coding off-topic to Python? This is not a rhetorical question. Well OOP on the python list is certainly on topic. Interminable discussions about why redrawing the inheritance arrows the other way round will save the world is OT (for me!) One of the great joys of reading this list is how wonderfully OT it can get. I have the right to make this statement as I started *THIS* thread. Now what *WERE* we talking about? :) -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: interactive help on the base object
On Mon, Dec 9, 2013 at 8:19 PM, Steven D'Aprano st...@pearwood.info wrote: While I'm very confident at this point that he is a crank, in the same category as circle-squarers, cold fusion proponents, pi-is-a-rational- number theorists, perpetual motion machine inventors, evolution or AGW Denialists[1], and other such obsessive examples of Dunning-Kruger, I'm not *totally* confident that he is a crank. Maybe he'll prove me wrong and actually learn something. Who knows, maybe *I'll* learn something! I would compare him more closely to the Einstein was wrong armchair physics revisionists, myself. -- https://mail.python.org/mailman/listinfo/python-list
Re: interactive help on the base object
On Tuesday, December 10, 2013 3:07:36 PM UTC+5:30, Mark Lawrence wrote: On 10/12/2013 05:16, rusi wrote: On Tuesday, December 10, 2013 10:40:27 AM UTC+5:30, Steven D'Aprano wrote: By the way, I'm curious. Why are discussions about object oriented coding off-topic to Python? This is not a rhetorical question. Well OOP on the python list is certainly on topic. Interminable discussions about why redrawing the inheritance arrows the other way round will save the world is OT (for me!) One of the great joys of reading this list is how wonderfully OT it can get. I have the right to make this statement as I started *THIS* thread. Now what *WERE* we talking about? :) My boy, I see that you are making progress towards your guru -- Nikos. You are spamming MY THREAD -- https://mail.python.org/mailman/listinfo/python-list
Re: interactive help on the base object
On 10/12/2013 7:37 PM, Mark Lawrence wrote: One of the great joys of reading this list is how wonderfully OT it can get. I have the right to make this statement as I started *THIS* thread. Now what *WERE* we talking about? :) The God Object (or Higgs Object for the non-theists). -- https://mail.python.org/mailman/listinfo/python-list
Re: interactive help on the base object
On Mon, Dec 9, 2013 at 6:31 PM, Alan Bawden a...@scooby-doo.csail.mit.edu wrote: I don't believe that this was done for any deep principled reason, but rather it was just permitted because the algorithm for computing method resolution order didn't actually care whether there were inheritance cycles -- it still terminated and returned an ordered list of component classes. How does that work, exactly? How do you have a class inherit (ultimately) from itself, and how does that impact the component class list? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: interactive help on the base object
On 09/12/2013 06:44, rusi wrote: On Monday, December 9, 2013 10:56:28 AM UTC+5:30, ru...@yahoo.com wrote: On 12/08/2013 09:46 PM, rusi wrote: On Monday, December 9, 2013 9:46:30 AM UTC+5:30, Steven D'Aprano wrote: On Sun, 08 Dec 2013 18:58:09 -0800, rusi wrote: [...] Does GG not give you some way of inspecting the post's full headers? Well I spent half hour looking around -- both inside GG and of course searching before asking. If you click on the little down triangle to the right of the reply button for a message, you'll get a menu that includes Show Original. You can see the headers including the Content-Type: in that original. Thanks rurpy -- I only looked for how one may set and not just what is. So now I look at my own post in GG and see Content-Type: text/plain; charset=UTF-8 So far so good. However when I point firefox at my own post in the archive https://mail.python.org/pipermail/python-list/2013-December/662015.html firefox shows encoding as Windows-1252. Note Ive looked at a dozen random pages and for all FF shows encoding as utf-8 except the python list archive ones which show as Win 1252 Note looking into the html I see META http-equiv=Content-Type content=text/html; charset=us-ascii How us-ascii becomes Win-1252 is outside the reach of my meagre intelligence! Though I still suspect something is not quite right with the python mailing-list and/or archive in respect of char encodings. [Am I beginning to sound like jmf is my guru :-) ] I'd mention that I never seem to have a problem using Thunderbird on Windows 7, but I won't as I don't want to be accused of bullying, hating GG, or whatever. Doh!!! :) -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: interactive help on the base object
On Sun, Dec 8, 2013 at 4:01 PM, Mark Janssen dreamingforw...@gmail.com wrote: Likewise, WITH A COMPUTER, there is a definite order which can't be countermanded by simply having this artifice called Object. If you FEE(L)s hadn't noticed (no longer using the insult foos out of respect for the sensativities of the brogrammers), this artifice has just been *called on the floor* with this little innocent question that fired up this discussion again (don't hate the messenger). Again: people entering the community are pointing out a problem -- that Object is both trying to be the BASE and the SUPERclass of all objects. You're mixing two different terminologies. Whereas superclass contrasts with subclass and connotes an imaginary spatial relationship, base contrasts with derived (not top), which pairing does not suggest any spatial relationship at all. There is no inconsistency in that these two words happen to mean the same thing. Likewise it doesn't matter whether we draw class hierarchies from the top down or the bottom up or even sidewise: Have you caught it by now, friends: IT MATTERS TO THE COMPUTER. No, I'm pretty sure the computer doesn't care one whit whether the inheritance hierarchy that I scribble on a random sheet of paper happens to be represented as top-down, bottom-up, left-right, right-left, center-out, ana-kata, or using any other conceivable spatial relationship that I may have omitted. The computer only cares (inasmuch as I'm willing to personify it) about the actual *code* that I feed into it. How the programmer abstracts or visualizes that code is irrelevant. -- https://mail.python.org/mailman/listinfo/python-list
Re: interactive help on the base object
On 12/9/13 12:11 AM, Steven D'Aprano wrote:
On Sun, 08 Dec 2013 15:01:59 -0800, Mark Janssen wrote:
On Sun, Dec 8, 2013 at 2:33 AM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
On Sat, 07 Dec 2013 20:21:06 -0800, Mark Janssen wrote:
Is it just me, or is this basically useless?
class object
| The most *base* type
[[Terry Reedy:]]
How about something like.
The default top *superclass* for all Python classes.
How 'bout you fools just admit that you didn't realize you've been
confused this whole time? (It *is* possible isn't it?)
Mr. Ewing says base has to be interpreted as an *adjective* because
otherwise it would mean the BOTTOM (like the BASE of the pyramid),
while Terry responds that it is the TOP (*super*class). Earlier,
Steven D'Aprano wanted to argue that this distinction was irrelevant,
What are you talking about? Until this very post, I haven't made any
comments in this thread.
It was a few months ago. You do know what I'm talking about because you
just expounded with the exact same argument below. It's like a broken
record.
While I am gratified that you apparently memorise and obsess over things
I wrote months ago, I'm sorry to tell you that I wasn't lying when I said
that I didn't know what you were talking about. I had no idea that you
were referring to a completely different conversation, nor do I recall
every post I write here.
If I repeated the same argument, it is because the argument is still
valid. Drawing the root of the tree at the top of the page is just a
convention, just driving on the left side of the road, or calling the
elected head of state Prime Minister. There are other ways to do such
things which are equally valid, and so long as both parties agree on the
convention, it doesn't matter whether you write from left-to-right like
in Australia, right-to-left like in Egypt, or alternate like in Israel.
(Now if *I* sound like a broken record, it's because no seems
to see the obvious, but carry on.)
It must be such a trial to be the only sane man in a world gone mad.
[...]
What matters is the relationships between the entities, not the
specific direction they are drawn in relative to some imaginary
absolute space. [yadda, yagni, yadda]
But, there IS A DIFFERENCE. Let me explain the concept of a object
model (or type model if you prefer).
In a family inheritance tree, there is this difference -- called the
calendar -- which imposes an ordering which can't be countermanded by
flipping your silly chart around. You made a bullshit example to simply
argue a point and *fooled yourself* into ignoring this. Yes?
No. You haven't explained anything, you have merely made an assertion
with no supporting evidence at all.
In a family tree of ancestors and descendants, the relationship being
draw is time-based. Ancestors exist before descendants. Descendants are
derived in some way from ancestors, not the other way around. We all
agree that your father existed before you. The temporal direction of the
relationship is absolutely fixed, past before present, ancestors before
descendants. We can agree on this.
Explain to me this: what (apart from mere human convention) imposes the
ordering past must be at the top of the page?
If you are reading this as email, your mail client very likely has an
option to sort message in order that they were received, either most-
recent at the top or oldest at the top. Do you really mean to imply that
one of those is logical and the other is delusional?
Likewise, WITH A COMPUTER, there is a definite order which can't be
countermanded by simply having this artifice called Object. If you
FEE(L)s hadn't noticed (no longer using the insult foos out of respect
for the sensativities of the brogrammers), this artifice has just been
*called on the floor* with this little innocent question that fired up
this discussion again (don't hate the messenger). Again: people
entering the community are pointing out a problem -- that Object is both
trying to be the BASE and the SUPERclass of all objects.
How is this a problem? They mean the same thing.
A television is both an appliance and a device. object is both the base
class and a superclass of all other classes.
CS554: A type/object *model* has to define the relationship of these
nice abstractions so that they can be mapped to the *actual
concreteness* of the machine. And there, bro, there is an ordering.
Yes, the ordering is that the subclass is derived from the superclass.
Nobody disputes that. But we can show that relationship using any
convention we like:
superclass - subclass
subclass - superclass
superclass extended by subclass
subclass extends superclass
superclass
↓
subclass
subclass
↑
superclass
Python syntax:
class MySubclass(MySuperclass): ...
Smalltalk syntax:
MySuperclass :subclass #MySubclass
Java syntax:
class MySubclass extends MySuperclass {...}
You're not going to magically flip the hierarchy so that
Re: interactive help on the base object
On 09/12/2013 10:12, Ian Kelly wrote: On Sun, Dec 8, 2013 at 4:01 PM, Mark Janssen dreamingforw...@gmail.com wrote: Likewise, WITH A COMPUTER, there is a definite order which can't be countermanded by simply having this artifice called Object. If you FEE(L)s hadn't noticed (no longer using the insult foos out of respect for the sensativities of the brogrammers), this artifice has just been *called on the floor* with this little innocent question that fired up this discussion again (don't hate the messenger). Again: people entering the community are pointing out a problem -- that Object is both trying to be the BASE and the SUPERclass of all objects. You're mixing two different terminologies. Whereas superclass contrasts with subclass and connotes an imaginary spatial relationship, base contrasts with derived (not top), which pairing does not suggest any spatial relationship at all. There is no inconsistency in that these two words happen to mean the same thing. Likewise it doesn't matter whether we draw class hierarchies from the top down or the bottom up or even sidewise: Have you caught it by now, friends: IT MATTERS TO THE COMPUTER. No, I'm pretty sure the computer doesn't care one whit whether the inheritance hierarchy that I scribble on a random sheet of paper happens to be represented as top-down, bottom-up, left-right, right-left, center-out, ana-kata, or using any other conceivable spatial relationship that I may have omitted. The computer only cares (inasmuch as I'm willing to personify it) about the actual *code* that I feed into it. How the programmer abstracts or visualizes that code is irrelevant. MASCOT is the One True Way http://en.wikipedia.org/wiki/Modular_Approach_to_Software_Construction_Operation_and_Test -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: interactive help on the base object
On 09/12/2013 05:00, Terry Reedy wrote: I think it can be. If you prefer me to open the issue, say so. We should look for existing issues, and closed issues that rejected change. Thanks for the offer Terry and yes, please open an issue. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: interactive help on the base object
On Mon, 09 Dec 2013 05:59:29 -0500, Ned Batchelder wrote: [...] And the cycle continues: [...] Maybe we could just not? A reasonable request, but just because it's reasonable doesn't mean it is a no-brainer that we shouldn't engage with Mark. While I'm very confident at this point that he is a crank, in the same category as circle-squarers, cold fusion proponents, pi-is-a-rational- number theorists, perpetual motion machine inventors, evolution or AGW Denialists[1], and other such obsessive examples of Dunning-Kruger, I'm not *totally* confident that he is a crank. Maybe he'll prove me wrong and actually learn something. Who knows, maybe *I'll* learn something! Even if Mark is a crank and beyond the reach of logic, reason or facts, and I'm 90% convinced his is, consider that he's not the only one reading this thread. If just one person learns something useful or new from a reply to Mark, I believe that it is worthwhile. I daresay that at some point I'll make the same decision as you, that the pain of answering Mark is not worth the benefit to readers, or perhaps that there aren't any readers who will learn something new. But I'm not there yet. (Perhaps I'm just slow.) Speaking of cranks, anyone unaware of the Crack-pot index should check it out: http://math.ucr.edu/home/baez/crackpot.html It's probably more entertaining for those who have actually spent time engaging with cranks in the sciences (e.g. Relativity Denialists) or mathematics. [1] A lot of people dislike the term Denialist. I justify it this way -- there is a difference between those who merely have doubts about the existence of something (say, evolution, global warming, the Holocaust, Operation Gladio, Shakespeare, etc.) and a Denialist. Those doubts don't even need to be *reasonable* doubts. If the person happens to be unknowledgeable (i.e. ignorant) about the subject in question, their doubts may be unreasonable relative to the state of knowledge. What matters is whether the person doing the doubting is reasonable. Denialists are cranks. Not all people who deny, dispute or question accepted knowledge are cranks. Normally the difference between a crank and a non-crank is relatively obvious. One very strong sign is to ask the question what evidence would change your mind?. If the answer is either no evidence at all will change my mind, or something which is impossible to satisfy (e.g. I won't accept evolution until I see a chicken give birth to a human being), then the person is a crank and hence the term Denialist is likely to be apt. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: interactive help on the base object
On Tuesday, December 10, 2013 8:49:46 AM UTC+5:30, Steven D'Aprano wrote: On Mon, 09 Dec 2013 05:59:29 -0500, Ned Batchelder wrote: [...] And the cycle continues: [...] Maybe we could just not? Thanks Ned for your attempts at bringing some order and sense in these parts of the universe A reasonable request, but just because it's reasonable doesn't mean it is a no-brainer that we shouldn't engage with Mark. Some basic statistics Suppose a random variable X takes 2 values x and y with probabilities p and q=1-p. Then expected value of X E[X] = px + qy p = probability of some good result from an interaction q = 1-p = No good x = benefit value y = harm value Even if Mark is a crank and beyond the reach of logic, reason or facts, and I'm 90% convinced his is, consider that he's not the only one reading this thread. So you are pegging 'no-good-probability' at 90% and so p at 10%. Ok lets accept these. And in the benefit value you include the possible benefit to Mark, to whoever engages with him and the random [no relation of random variable X] lurking reader. So far so good And in the harm-value y, are you including the harm done to the random reader from a disorderly, abusive, fruitless and almost completely OT conversation? If just one person learns something useful or new from a reply to Mark, I believe that it is worthwhile. And if 3 people drop out because the levels of bullshit have crossed their thresholds? [BTW: My statistics was never very strong and is now quite rusty. So... Whos that guy who recently added a stats module to python?? Cant remember his name... Maybe I should take some tuitions from him...] -- https://mail.python.org/mailman/listinfo/python-list
Re: interactive help on the base object
On Mon, 09 Dec 2013 20:32:06 -0800, rusi wrote: On Tuesday, December 10, 2013 8:49:46 AM UTC+5:30, Steven D'Aprano wrote: On Mon, 09 Dec 2013 05:59:29 -0500, Ned Batchelder wrote: [...] And the cycle continues: [...] Maybe we could just not? Thanks Ned for your attempts at bringing some order and sense in these parts of the universe A reasonable request, but just because it's reasonable doesn't mean it is a no-brainer that we shouldn't engage with Mark. Some basic statistics Suppose a random variable X takes 2 values x and y with probabilities p and q=1-p. Then expected value of X E[X] = px + qy p = probability of some good result from an interaction Define good result. q = 1-p = No good Define No good. x = benefit value y = harm value Even if Mark is a crank and beyond the reach of logic, reason or facts, and I'm 90% convinced his is, consider that he's not the only one reading this thread. So you are pegging 'no-good-probability' at 90% and so p at 10%. Ok lets accept these. Certainly not. I'm pegging my confidence that Mark is a crank at 90%, which is not the same thing. For example, although Mark is (presumably) a crank, nevertheless I have brought some enjoyment into your life as it has given you the opportunity to regale us all with your opinion on off-topic posts, and show off your advanced knowledge of probability *wink* That counts as a good result. And in the benefit value you include the possible benefit to Mark, to whoever engages with him and the random [no relation of random variable X] lurking reader. So far so good And in the harm-value y, are you including the harm done to the random reader from a disorderly, abusive, fruitless and almost completely OT conversation? You are conflating the magnitude of harm with the probability of harm. But please, do continue in your off-topic rant complaining about off- topic conversations, I'm sure that we're all learning either something or possibly nothing from it. If just one person learns something useful or new from a reply to Mark, I believe that it is worthwhile. And if 3 people drop out because the levels of bullshit have crossed their thresholds? I don't know. If twelve people are moved to drop out of this group because of your post complaining about my post, how would you react? I'd probably feel between 0 and 1/4 times as good. By the way, I'm curious. Why are discussions about object oriented coding off-topic to Python? This is not a rhetorical question. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: interactive help on the base object
On Tuesday, December 10, 2013 10:40:27 AM UTC+5:30, Steven D'Aprano wrote: By the way, I'm curious. Why are discussions about object oriented coding off-topic to Python? This is not a rhetorical question. Well OOP on the python list is certainly on topic. Interminable discussions about why redrawing the inheritance arrows the other way round will save the world is OT (for me!) -- https://mail.python.org/mailman/listinfo/python-list
Re: interactive help on the base object
Chris Angelico ros...@gmail.com writes: How does that work, exactly? How do you have a class inherit (ultimately) from itself, and how does that impact the component class list? How does it work exactly? You're asking me about a feature I never made use of, in a system I have no source for, and that I haven't used in over 25 years! If it wasn't mentioned in a parenthetical comment in the 32-year-old documentation I still have on my bookshelf (Lisp Machine Manual, 4th edition, July 1981, blue cover), I wouldn't trust my own memory that such a thing ever even existed. So you're not getting anything exact here! I have no idea exactly how it worked, but imagine something that walked the superclass graph _as_ _if_ it was a tree, collected classes in some order, and that just skips any class it encounters for the second time. That results in _some_ linear ordering of all the classes you can reach from the starting class. Now use that. Now the results aren't going to be very good by modern standards. As the Common Lisp Object System, Dylan, Python, and others, have all discovered, you really want something that is at _least_ a topological sort of the superclass graph -- and there is no topological sort at all unless your superclass graph is acyclic. But even if the results aren't up to modern standards, you can write a hell of a lot of code before the deficiencies have hurt enough people enough times to motivate you to do better. After all modern Python classes didn't start using their current ordering until Python 2.3. -- Alan Bawden -- https://mail.python.org/mailman/listinfo/python-list
Re: interactive help on the base object
In article 5f7e3e2f-2f86-4a2b-bea5-6e70b6fc2...@googlegroups.com, rusi rustompm...@gmail.com wrote: On Tuesday, December 10, 2013 10:40:27 AM UTC+5:30, Steven D'Aprano wrote: By the way, I'm curious. Why are discussions about object oriented coding off-topic to Python? This is not a rhetorical question. Well OOP on the python list is certainly on topic. Interminable discussions about why redrawing the inheritance arrows the other way round will save the world is OT (for me!) What about whether the arrows should have solid heads, open heads, barbed heads, double-barbed heads, or circles (filled or open)? Surely you can't expect people to write decent programs when they can't even draw the right kind of arrowhead? -- https://mail.python.org/mailman/listinfo/python-list
Re: interactive help on the base object
On Tue, Dec 10, 2013 at 4:27 PM, Alan Bawden a...@scooby-doo.csail.mit.edu wrote: Chris Angelico ros...@gmail.com writes: On Mon, Dec 9, 2013 at 6:31 PM, Alan Bawden ... How does that work, exactly? How do you have a class inherit (ultimately) from itself, and how does that impact the component class list? How does it work exactly? You're asking me about a feature I never made use of, in a system I have no source for, and that I haven't used in over 25 years! If it wasn't mentioned in a parenthetical comment in the 32-year-old documentation I still have on my bookshelf (Lisp Machine Manual, 4th edition, July 1981, blue cover), I wouldn't trust my own memory that such a thing ever even existed. So you're not getting anything exact here! LOL! I have no idea exactly how it worked, but imagine something that walked the superclass graph _as_ _if_ it was a tree, collected classes in some order, and that just skips any class it encounters for the second time. That results in _some_ linear ordering of all the classes you can reach from the starting class. Now use that. Ow, that sounds a bit... weird. I think I prefer an acyclic graph for inheritance! A few weirdnesses are necessary for bootstrapping - type(object) is type, type(type) is type, and type.__bases__ = (object,) - but normally every type should be created before all instances of it, and every superclass before all its subclasses. But of course, *multiple* inheritance is always weird. I've worked in some detail with four systems (C++, Python, Pike, Java), and they're all quite different in how they handle MI. Java says There is no MI... but you can implement multiple interfaces. C++ says There is MI and there is virtual MI, and if one of them doesn't do your head in, the other will. Python says It's all about method resolution, instance data is separate, so make sure everything cooperates. Pike says If both parents define a method, super() will return an array of methods, but that's okay because arrays are callable. It's a fundamentally tricky problem, largely because every real-world analogy we can muster is going to end up looking more like composition than inheritance (a guided missile is-a bomb and is-a rocket, but it's just as valid to say it is-a rocket and it has-a bomb). ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: interactive help on the base object
On Tue, 10 Dec 2013 00:31:15 -0500, Roy Smith wrote: In article 5f7e3e2f-2f86-4a2b-bea5-6e70b6fc2...@googlegroups.com, rusi rustompm...@gmail.com wrote: On Tuesday, December 10, 2013 10:40:27 AM UTC+5:30, Steven D'Aprano wrote: By the way, I'm curious. Why are discussions about object oriented coding off-topic to Python? This is not a rhetorical question. Well OOP on the python list is certainly on topic. Interminable discussions about why redrawing the inheritance arrows the other way round will save the world is OT (for me!) What about whether the arrows should have solid heads, open heads, barbed heads, double-barbed heads, or circles (filled or open)? Surely you can't expect people to write decent programs when they can't even draw the right kind of arrowhead? You mock, and so you should, but I just thought I'd mention that there are standards for this sort of thing: http://en.wikipedia.org/wiki/Unified_Modeling_Language According to UML the type of arrow head does make a difference. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: interactive help on the base object
In article 52a6af26$0$2829$c3e8da3$76491...@news.astraweb.com, Steven D'Aprano st...@pearwood.info wrote: What about whether the arrows should have solid heads, open heads, barbed heads, double-barbed heads, or circles (filled or open)? Surely you can't expect people to write decent programs when they can't even draw the right kind of arrowhead? You mock, and so you should, but I just thought I'd mention that there are standards for this sort of thing: http://en.wikipedia.org/wiki/Unified_Modeling_Language According to UML the type of arrow head does make a difference. Surely you realize that such a carefully constructed mock could not have been generated without knowledge of the mockee? UML, like so many things, started out with a few good ideas. Giving some structure to how you sketch out classes on a whiteboard was a good idea. Sequence diagrams, in particular, are a neat way to understand complicated control flows. I've even used UML tools to make sense of some huge pile of C++ code that was tossed my way. Import the code, then start shoving boxes around on the screen until some sort of logical structure emerges. But, once things got to there being N different types of arrowheads, each having some magical significance, they lost me. PS: other things that fall into the Some good basic ideas, but got totally out of hand include Agile, Six Sigma, and Perl. -- https://mail.python.org/mailman/listinfo/python-list
Re: interactive help on the base object
On Sat, 07 Dec 2013 20:21:06 -0800, Mark Janssen wrote: Is it just me, or is this basically useless? class object | The most *base* type [[Terry Reedy:]] How about something like. The default top *superclass* for all Python classes. How 'bout you fools just admit that you didn't realize you've been confused this whole time? (It *is* possible isn't it?) Mr. Ewing says base has to be interpreted as an *adjective* because otherwise it would mean the BOTTOM (like the BASE of the pyramid), while Terry responds that it is the TOP (*super*class). Earlier, Steven D'Aprano wanted to argue that this distinction was irrelevant, What are you talking about? Until this very post, I haven't made any comments in this thread. but obviously it can't very well be both at once now cannit? Of course it can. To people in the southern hemisphere, the South Pole is at the top of the world and the North Pole is at the bottom. For people in the northern hemisphere, it's the opposite, with the North Pole being up and the South Pole being down. http://cdn.shopify.com/s/files/1/0071/5032/products/upside_down_world_map.png Family trees and other hierarchies, including class inheritance diagrams, have a *relative* direction not an absolute direction. We can all agree that Fred and Wilma are the parents of Pebbles, but it doesn't really matter whether we draw the family tree like this: Fred Wilma (diagrams best viewed in a fixed-width font | | like Courier, Monaco or Lucinda Typewriter) +++ | Pebbles (inheritance goes *down* the page from ancestors to descendants) or like this: Pebbles | +++ | | Fred Wilma (inheritance goes *up* the page from ancestors to descendants). What matters is the relationships between the entities, not the specific direction they are drawn in relative to some imaginary absolute space. Likewise it doesn't matter whether we draw class hierarchies from the top down or the bottom up or even sidewise: object -- int -- myint is the same as: myint -- int -- object Ironically, although it is conventional to draw the most distant ancestor at the *top* of the page, it is called the *base* or *root* of the tree. This Way Up || || || \ || / \||/ -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: interactive help on the base object
On 12/7/13 11:21 PM, Mark Janssen wrote: Is it just me, or is this basically useless? class object | The most *base* type [[Terry Reedy:]] How about something like. The default top *superclass* for all Python classes. How 'bout you fools just admit that you didn't realize you've been confused this whole time? (It *is* possible isn't it?) Mark, if you want to participate in this forum, please refrain from opening with an insult. I've tried talking with you here in the past, and got nothing but sarcastic sneers and put-downs for my trouble. I gave you the benefit of the doubt, and believed that previous contentious points (no tokens on punched cards, initializing arrays to NaN, etc) were due to misunderstandings that could be worked out. You treated me with contempt and refused to discuss the details that would have let us understand each other. I know you have a theory that all of computer science has been confused for half a century. You expounded on this before, but haven't managed to explain your point clearly, and have not convinced anyone that you have a better model than the ones we're already using. Perhaps we are confused, and you have a better idea. I don't know yet, though frankly I doubt it. I'd be glad to learn about your ideas, but you have to present them seriously, and with some humility, to get them to spread. So far, repeated attempts to get details from you have failed. Mr. Ewing says base has to be interpreted as an *adjective* because otherwise it would mean the BOTTOM (like the BASE of the pyramid), while Terry responds that it is the TOP (*super*class). Earlier, Steven D'Aprano wanted to argue that this distinction was irrelevant, but obviously it can't very well be both at once now cannit? Could-the-world-be-so-crazy-confused-and-then-shoot-the-messenger? Sadly, yes. I'm sorry you feel martyred. It's not because you bring truth to crazy-confused people. It's because you can't explain yourself, and you push people away with your style. We try hard to treat each other with respect, and I'll ask you to do the same. MarkJ Tacoma, Washington -- Ned Batchelder, http://nedbatchelder.com -- https://mail.python.org/mailman/listinfo/python-list
Re: interactive help on the base object
On Sun, Dec 8, 2013 at 2:33 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: On Sat, 07 Dec 2013 20:21:06 -0800, Mark Janssen wrote: Is it just me, or is this basically useless? class object | The most *base* type [[Terry Reedy:]] How about something like. The default top *superclass* for all Python classes. How 'bout you fools just admit that you didn't realize you've been confused this whole time? (It *is* possible isn't it?) Mr. Ewing says base has to be interpreted as an *adjective* because otherwise it would mean the BOTTOM (like the BASE of the pyramid), while Terry responds that it is the TOP (*super*class). Earlier, Steven D'Aprano wanted to argue that this distinction was irrelevant, What are you talking about? Until this very post, I haven't made any comments in this thread. It was a few months ago. You do know what I'm talking about because you just expounded with the exact same argument below. It's like a broken record. (Now if *I* sound like a broken record, it's because no seems to see the obvious, but carry on.) but obviously it can't very well be both at once now cannit? Family trees and other hierarchies, including class inheritance diagrams, have a *relative* direction not an absolute direction. We can all agree that Fred and Wilma are the parents of Pebbles, but it doesn't really matter whether we draw the family tree like this: Fred Wilma (diagrams best viewed in a fixed-width font | | like Courier, Monaco or Lucinda Typewriter) +++ | Pebbles (inheritance goes *down* the page from ancestors to descendants) or like this: Pebbles | +++ | | Fred Wilma (inheritance goes *up* the page from ancestors to descendants). What matters is the relationships between the entities, not the specific direction they are drawn in relative to some imaginary absolute space. [yadda, yagni, yadda] But, there IS A DIFFERENCE. Let me explain the concept of a object model (or type model if you prefer). In a family inheritance tree, there is this difference -- called the calendar -- which imposes an ordering which can't be countermanded by flipping your silly chart around. You made a bullshit example to simply argue a point and *fooled yourself* into ignoring this. Yes? Likewise, WITH A COMPUTER, there is a definite order which can't be countermanded by simply having this artifice called Object. If you FEE(L)s hadn't noticed (no longer using the insult foos out of respect for the sensativities of the brogrammers), this artifice has just been *called on the floor* with this little innocent question that fired up this discussion again (don't hate the messenger). Again: people entering the community are pointing out a problem -- that Object is both trying to be the BASE and the SUPERclass of all objects. CS554: A type/object *model* has to define the relationship of these nice abstractions so that they can be mapped to the *actual concreteness* of the machine. And there, bro, there is an ordering. You're not going to magically flip the hierarchy so that your bitless Object becomes a machine word that is the base of all your types. You've been fooled by the magic of the Turing Machine. The modern computer mollifies you with the illusion of total abstraction where there are no bits or 1s and 0s involved, but yea, it did not turn out that way. (Note bene: as a comparison, C++ is very UNAMBIGUOUS about this fact -- all objects inherit from concrete machine types, which is why it remains important, *despite* being one of the worst to do OOP in. Its *type model* is probably the most clear of any object-oriented language). Likewise it doesn't matter whether we draw class hierarchies from the top down or the bottom up or even sidewise: Have you caught it by now, friends: IT MATTERS TO THE COMPUTER. With some apologies for Ned for attempting to be neutral. Apparently you guys are philosophers more than Computer Engineers. MarkJ Tacoma, Washington -- https://mail.python.org/mailman/listinfo/python-list
Re: interactive help on the base object
Mark Janssen wrote: Mr. Ewing says base has to be interpreted as an *adjective* because otherwise it would mean the BOTTOM (like the BASE of the pyramid), Not exactly -- a native English speaker would say something like the bottommost class if that's what they meant. Or they would say the most basic class to mean the simplest one -- but that's not quite what we mean either. The only way that most base class makes grammatical sense is if you interpret base as meaning undesirable, as in base metal (i.e. a non-precious metal), base instinct (the kind of animal urges that humans are meant to be too good for), etc. while Terry responds that it is the TOP (*super*class). Yeah, top or bottom only conveys the right idea if you assume the diagram is drawn a particular way up. Which is why I like the term base class -- you just need to be careful with the grammar! -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: interactive help on the base object
On 07/12/2013 01:35, Terry Reedy wrote: On 12/6/2013 12:03 PM, Mark Lawrence wrote: Is it just me, or is this basically useless? help(object) Help on class object in module builtins: class object | The most base type Given that this can be interpreted as 'least desirable', it could definitely be improved. Surely a few more words, How about something like. '''The default top superclass for all Python classes. Its methods are inherited by all classes unless overriden. ''' When you have 1 or more concrete suggestions for the docstring, open a tracker issue. Terry's suggestion above remains odds on favourite on the grounds that there have been no other suggestions. I'll give it another day, then raise a tracker issue, unless the overwhelming smell of pot that has been drifting around this thread knocks me unconscious. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: interactive help on the base object
On Sun, 08 Dec 2013 23:48:57 +, Mark Lawrence wrote: help(object) Help on class object in module builtins: class object | The most base type '''The default top superclass for all Python classes. Its methods are inherited by all classes unless overriden. ''' Terry's suggestion above remains odds on favourite on the grounds that there have been no other suggestions. I'll give it another day, then raise a tracker issue, unless the overwhelming smell of pot that has been drifting around this thread knocks me unconscious. The root class for all Python classes. Its methods are inherited by all classes unless overriden. -- Denis McMahon, denismfmcma...@gmail.com -- https://mail.python.org/mailman/listinfo/python-list
Re: interactive help on the base object
help(object) Help on class object in module builtins: class object | The most base type '''The default top superclass for all Python classes. Its methods are inherited by all classes unless overriden. ''' The root class for all Python classes. Its methods are inherited by all classes unless overriden. *sits back*. -- MarkJ Tacoma, Washington -- https://mail.python.org/mailman/listinfo/python-list
Re: interactive help on the base object
On 09/12/2013 01:09, Mark Janssen wrote: help(object) Help on class object in module builtins: class object | The most base type '''The default top superclass for all Python classes. Its methods are inherited by all classes unless overriden. ''' The root class for all Python classes. Its methods are inherited by all classes unless overriden. *sits back*. Why? If a newbie is encouraged, as everybody is, to use help at the interactive prompt, then surely them seeing The most base type when typing help(object) is of no use to them at all. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: interactive help on the base object
On 09/12/2013 00:45, Denis McMahon wrote: On Sun, 08 Dec 2013 23:48:57 +, Mark Lawrence wrote: help(object) Help on class object in module builtins: class object | The most base type '''The default top superclass for all Python classes. Its methods are inherited by all classes unless overriden. ''' Terry's suggestion above remains odds on favourite on the grounds that there have been no other suggestions. I'll give it another day, then raise a tracker issue, unless the overwhelming smell of pot that has been drifting around this thread knocks me unconscious. The root class for all Python classes. Its methods are inherited by all classes unless overriden. Thanks Denis, you've reminded me why I asked in the first place. What methods, if any does it provide? Are they all abstract? etc??? Personally I'm not really interested, but a newbie might well be and hence might wonder what the hell is going on. If and only if the situation can be improved I'll raise an issue, if not I'll quietly let it drop, and consider more important things, like why are Australia currently thrashing England at cricket? :) -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: interactive help on the base object
On Sun, 08 Dec 2013 23:48:57 +, Mark Lawrence wrote: Terry's suggestion above remains odds on favourite on the grounds that there have been no other suggestions. I'll give it another day, then raise a tracker issue, It's not merely the default superclass, it *is* the superclass to everything. In Python 3, you cannot create an object that doesn't derive from object. (At least not in pure Python -- perhaps you could do so in a C extension class?) Top is misleading, because it assumes that class diagrams are always drawn with ancestors at the top and descendants at the bottom. No need to say that methods are inherited unless overridden, it goes without saying that you can override methods. object: The most fundamental base class for all Python classes and the root of the class inheritance hierarchy. All classes inherit from object. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: interactive help on the base object
On Mon, 09 Dec 2013 01:43:43 +, Mark Lawrence wrote about object: What methods, if any does it provide? Are they all abstract? etc??? Pretty much nothing useful :-) py dir(object) ['__class__', '__delattr__', '__dir__', '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__', '__gt__', '__hash__', '__init__', '__le__', '__lt__', '__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__'] What few methods there are typically do nothing, or nothing interesting. A few implement basic functionality, e.g. __eq__ performs equality based on identity (an object is equal to itself and nothing else). -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: interactive help on the base object
What methods, if any does it provide? Are they all abstract? etc??? Pretty much nothing useful :-) py dir(object) [...] So (prodding the student), Why does everything inherit from Object if it provides no functionality? Practicality-beats-purity-yours? -- MarkJ Tacoma, Washington -- https://mail.python.org/mailman/listinfo/python-list
Re: interactive help on the base object
On Mon, Dec 9, 2013 at 10:01 AM, Mark Janssen dreamingforw...@gmail.com wrote:
(Note bene: as a comparison, C++ is very UNAMBIGUOUS about
this fact -- all objects inherit from concrete machine types, which is
why it remains important, *despite* being one of the worst to do OOP
in. Its *type model* is probably the most clear of any
object-oriented language).
Factually wrong. In C++, it is actually *impossible* to inherit from a
concrete machine type, by which presumably you mean the classic
types int/char/float etc.
struct foo: public int
{
foo() {}
};
1.cpp:1:20: error: expected class-name before ‘int’
1.cpp:1:20: error: expected ‘{’ before ‘int’
1.cpp:2:1: error: expected unqualified-id before ‘{’ token
Okay, that's a parse error. Maybe if we avoid the language keyword?
typedef int integer;
struct foo: public integer
{
foo() {}
};
1.cpp:4:1: error: expected class-name before ‘{’ token
Nope. There are two completely different groups here: the basic types
(called here [1] Fundamental data types) and the structure types.
The latter are created by the struct/class keyword and can use
inheritance. The former... aren't. Not every C++ type is part of the
type hierarchy.
This is actually somewhat true of Python, too, but the set of types
that are unavailable for inheritance is much smaller and less useful.
You can't inherit from the 'function' type, for instance:
class foo(type(lambda:1)):
pass
Traceback (most recent call last):
File pyshell#80, line 1, in module
class foo(type(lambda:1)):
TypeError: type 'function' is not an acceptable base type
And yet class 'function' inherits from class 'object', so it's not
entirely outside in the way C++ int is. And I can apparently subclass
module, though not generator, and unsurprisingly NoneType can't be
inherited from. (Though you can instantiate it, and it's probably the
only class that will appear to have no return value from
instantiation.)
C++ has you *compose* structs/classes from primitives, but this is not
the same as inheritance. They're completely separate concepts.
ChrisA
[1] http://www.cplusplus.com/doc/tutorial/variables/
--
https://mail.python.org/mailman/listinfo/python-list
Re: interactive help on the base object
On Mon, Dec 9, 2013 at 1:41 PM, Mark Janssen dreamingforw...@gmail.com wrote:
What methods, if any does it provide? Are they all abstract? etc???
Pretty much nothing useful :-)
py dir(object)
[...]
So (prodding the student), Why does everything inherit from Object if
it provides no functionality?
Practicality-beats-purity-yours?
Nothing useful to call directly. An int has some useful methods in Python:
(258).to_bytes(2,little)
b'\x02\x01'
So does a list:
[1,4,1,5,9].count(1)
2
But there's nothing you'd normally want to call from object itself
(except maybe __repr__). There *are*, however, important pieces of
default functionality. Steven mentioned __eq__, and there's also its
pair __hash__. The default system works because the root type provides
implementations of those two functions:
a = object()
b = object()
a == b
False
d = {a:A, b:B}
d[a]
'A'
And it's important that these sorts of things work, because otherwise
a simple Python class would look like this:
class Foo:
def __new__(self): pass
def __init__(self): pass
def __hash__(self): return id(self)
def __eq__(self, other): return self is other
# ...
This repetition is exactly what inheritance is good at solving.
Therefore putting that functionality into a base class makes sense;
and since everything MUST have these functions to be able to be used
plausibly, putting them in the lowest base class of all makes the most
sense.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: interactive help on the base object
On Monday, December 9, 2013 8:11:47 AM UTC+5:30, zipher wrote: What methods, if any does it provide? Are they all abstract? etc??? Pretty much nothing useful :-) py dir(object) [...] So (prodding the student), Why does everything inherit from Object if it provides no functionality? Thats right. What does a collection object like [] or the empty set ∅ (assuming the unicode-gods will allow and bless that) do when it collects nothing? Lets make sure all lists and sets start non-empty. And why have a stupid number like 0 when it counts nothing? Lets go back to roman numerals which is so much more… Practicality-beats-purity-yours? Practical!!⸮¿¡ PS Can some kind soul inform me whether I could convince GG to unicode my post? -- https://mail.python.org/mailman/listinfo/python-list
Re: interactive help on the base object
On Sun, Dec 8, 2013 at 6:44 PM, Chris Angelico ros...@gmail.com wrote: On Mon, Dec 9, 2013 at 10:01 AM, Mark Janssen dreamingforw...@gmail.com wrote: (Note bene: as a comparison, C++ is very UNAMBIGUOUS about this fact -- all objects inherit from concrete machine types, which is why it remains important, *despite* being one of the worst to do OOP in. Its *type model* is probably the most clear of any object-oriented language). Factually wrong. In C++, it is actually *impossible* to inherit from a concrete machine type, by which presumably you mean the classic types int/char/float etc. Wow, you guys trip me out, but I guess I've been working in a different universe where I was mapping classes into basic types (using generic programming along with typedef). I'm going to have to re-think all this confusion. But, in any case, if you don't have a way to map your abstract objects into machine types, you're working on magic, not computer science. MarkJ Tacoma, Washington -- https://mail.python.org/mailman/listinfo/python-list
Re: interactive help on the base object
On Mon, Dec 9, 2013 at 2:05 PM, Mark Janssen dreamingforw...@gmail.com wrote: But, in any case, if you don't have a way to map your abstract objects into machine types, you're working on magic, not computer science. Maybe, but that mapping isn't always an inheritance relationship. Ultimately the computer can't work with my data without it being represented in memory and in registers (at least in part - relational database could be considered a type, the full implementation of which is never actually loaded into memory), but the most common way to do this is effectively some form of composition. For instance, C++ has a type called pair (actually a template); what's the most obvious way to define the type pair of integers? Place the first integer, then place the second integer. The pair has two members, first and second. The pair isn't the first integer, nor is it the second integer. It doesn't make sense to inherit pair from integer, so you don't. You compose it of two integers. class Pair(object): # in C++, we'd need to declare these: # int first; # int second; def __init__(self, first, second): self.first, self.second = first, second Calling integer methods on a Pair makes no sense. Which of its members did you want to call that on? Both of them? (Wouldn't make sense if you had a mixed pair, like pairemployee,gun which could be a little awkward to try to fire().) You can't sensibly use a Pair in a context where an integer would be wanted, so it fails LSP. It composes, but does not inherit from, int. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: interactive help on the base object
On Sun, 08 Dec 2013 18:58:09 -0800, rusi wrote: PS Can some kind soul inform me whether I could convince GG to unicode my post? Does GG not give you some way of inspecting the post's full headers? Anyway, here you go: Content-Type: text/plain; charset=UTF-8 Your plan succeeded. Personally, I wouldn't stress too much about this. While it would be nice, and desirable, for GG to always use UTF-8 instead of picking a different encoding based on the phase of the moon, the main thing is that it picks a valid encoding. So far I see no reason to accuse GG of using an invalid encoding. Valid but legacy encodings are better than mojibake :-) -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: interactive help on the base object
Thanks for the info. On Monday, December 9, 2013 9:46:30 AM UTC+5:30, Steven D'Aprano wrote: On Sun, 08 Dec 2013 18:58:09 -0800, rusi wrote: PS Can some kind soul inform me whether I could convince GG to unicode my post? Does GG not give you some way of inspecting the post's full headers? Well I spent half hour looking around -- both inside GG and of course searching before asking. Anyway, here you go: Content-Type: text/plain; charset=UTF-8 Your plan succeeded. Personally, I wouldn't stress too much about this. While it would be nice, and desirable, for GG to always use UTF-8 instead of picking a different encoding based on the phase of the moon, the main thing is that it picks a valid encoding. So far I see no reason to accuse GG of using an invalid encoding. Valid but legacy encodings are better than mojibake :-) Heh! I'm hardly a heavy-duty user of unicode -- just keeping track of bugs and workarounds. I am of course using 'bug' in a wide pragmatic sense of preventing communication. Mojibake is a technical problem. Non (human) communication is a more fundamental problem. Keeping an eye on the latter is (for me) a bigger issue than the former. -- https://mail.python.org/mailman/listinfo/python-list
Re: interactive help on the base object
On 12/8/2013 8:43 PM, Mark Lawrence wrote: On 09/12/2013 00:45, Denis McMahon wrote: On Sun, 08 Dec 2013 23:48:57 +, Mark Lawrence wrote: help(object) Help on class object in module builtins: class object | The most base type '''The default top superclass for all Python classes. Its methods are inherited by all classes unless overriden. ''' I said 'top' instead of 'bottom' or 'base' to loosen up thinking a bit. I did not expect Mark to make a mound out of that flip. Terry's suggestion above remains odds on favourite on the grounds that there have been no other suggestions. I'll give it another day, then raise a tracker issue, unless the overwhelming smell of pot that has been drifting around this thread knocks me unconscious. The root class for all Python classes. Its methods are inherited by all classes unless overriden. 'Root' is even better, since it does not depend on whether a tree is drawn up or down. Thanks. Thanks Denis, you've reminded me why I asked in the first place. What methods, if any does it provide? Good question. dir(object) ['__class__', '__delattr__', '__dir__', '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__', '__gt__', '__hash__', '__init__', '__le__', '__lt__', '__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__'] Are they all abstract? etc??? No. Personally I'm not really interested, but a newbie might well be and hence might wonder what the hell is going on. For everything else, help lists the special name methods directly associated with the object, along with docstrings. help(C) Help on class C in module __main__: class C(builtins.object) | Data descriptors defined here: | | __dict__ | dictionary for instance variables (if defined) | | __weakref__ | list of weak references to the object (if defined) I think help should do the same for object object.__hash__.__doc__ 'x.__hash__() == hash(x)' is equivalent to | __abs__(...) | x.__abs__() == abs(x) etc printed for help(int) The fact that __dict__ does not exist for object but is only added for subclasses explains why one must subclass object to get instances that allow attributes. o = object() o.a = 1 Traceback (most recent call last): File pyshell#8, line 1, in module o.a = 1 AttributeError: 'object' object has no attribute 'a' c = C() c.a=1 If and only if the situation can be improved I'll raise an issue I think it can be. If you prefer me to open the issue, say so. We should look for existing issues, and closed issues that rejected change. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: interactive help on the base object
On Sun, 08 Dec 2013 15:01:59 -0800, Mark Janssen wrote:
On Sun, Dec 8, 2013 at 2:33 AM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
On Sat, 07 Dec 2013 20:21:06 -0800, Mark Janssen wrote:
Is it just me, or is this basically useless?
class object
| The most *base* type
[[Terry Reedy:]]
How about something like.
The default top *superclass* for all Python classes.
How 'bout you fools just admit that you didn't realize you've been
confused this whole time? (It *is* possible isn't it?)
Mr. Ewing says base has to be interpreted as an *adjective* because
otherwise it would mean the BOTTOM (like the BASE of the pyramid),
while Terry responds that it is the TOP (*super*class). Earlier,
Steven D'Aprano wanted to argue that this distinction was irrelevant,
What are you talking about? Until this very post, I haven't made any
comments in this thread.
It was a few months ago. You do know what I'm talking about because you
just expounded with the exact same argument below. It's like a broken
record.
While I am gratified that you apparently memorise and obsess over things
I wrote months ago, I'm sorry to tell you that I wasn't lying when I said
that I didn't know what you were talking about. I had no idea that you
were referring to a completely different conversation, nor do I recall
every post I write here.
If I repeated the same argument, it is because the argument is still
valid. Drawing the root of the tree at the top of the page is just a
convention, just driving on the left side of the road, or calling the
elected head of state Prime Minister. There are other ways to do such
things which are equally valid, and so long as both parties agree on the
convention, it doesn't matter whether you write from left-to-right like
in Australia, right-to-left like in Egypt, or alternate like in Israel.
(Now if *I* sound like a broken record, it's because no seems
to see the obvious, but carry on.)
It must be such a trial to be the only sane man in a world gone mad.
[...]
What matters is the relationships between the entities, not the
specific direction they are drawn in relative to some imaginary
absolute space. [yadda, yagni, yadda]
But, there IS A DIFFERENCE. Let me explain the concept of a object
model (or type model if you prefer).
In a family inheritance tree, there is this difference -- called the
calendar -- which imposes an ordering which can't be countermanded by
flipping your silly chart around. You made a bullshit example to simply
argue a point and *fooled yourself* into ignoring this. Yes?
No. You haven't explained anything, you have merely made an assertion
with no supporting evidence at all.
In a family tree of ancestors and descendants, the relationship being
draw is time-based. Ancestors exist before descendants. Descendants are
derived in some way from ancestors, not the other way around. We all
agree that your father existed before you. The temporal direction of the
relationship is absolutely fixed, past before present, ancestors before
descendants. We can agree on this.
Explain to me this: what (apart from mere human convention) imposes the
ordering past must be at the top of the page?
If you are reading this as email, your mail client very likely has an
option to sort message in order that they were received, either most-
recent at the top or oldest at the top. Do you really mean to imply that
one of those is logical and the other is delusional?
Likewise, WITH A COMPUTER, there is a definite order which can't be
countermanded by simply having this artifice called Object. If you
FEE(L)s hadn't noticed (no longer using the insult foos out of respect
for the sensativities of the brogrammers), this artifice has just been
*called on the floor* with this little innocent question that fired up
this discussion again (don't hate the messenger). Again: people
entering the community are pointing out a problem -- that Object is both
trying to be the BASE and the SUPERclass of all objects.
How is this a problem? They mean the same thing.
A television is both an appliance and a device. object is both the base
class and a superclass of all other classes.
CS554: A type/object *model* has to define the relationship of these
nice abstractions so that they can be mapped to the *actual
concreteness* of the machine. And there, bro, there is an ordering.
Yes, the ordering is that the subclass is derived from the superclass.
Nobody disputes that. But we can show that relationship using any
convention we like:
superclass - subclass
subclass - superclass
superclass extended by subclass
subclass extends superclass
superclass
↓
subclass
subclass
↑
superclass
Python syntax:
class MySubclass(MySuperclass): ...
Smalltalk syntax:
MySuperclass :subclass #MySubclass
Java syntax:
class MySubclass extends MySuperclass {...}
You're not going to magically flip the hierarchy so that
Re: interactive help on the base object
On 12/08/2013 09:46 PM, rusi wrote: On Monday, December 9, 2013 9:46:30 AM UTC+5:30, Steven D'Aprano wrote: On Sun, 08 Dec 2013 18:58:09 -0800, rusi wrote: [...] Does GG not give you some way of inspecting the post's full headers? Well I spent half hour looking around -- both inside GG and of course searching before asking. If you click on the little down triangle to the right of the reply button for a message, you'll get a menu that includes Show Original. You can see the headers including the Content-Type: in that original. Of course this means you have to post first and find out after... -- https://mail.python.org/mailman/listinfo/python-list
Re: interactive help on the base object
On Sun, 08 Dec 2013 18:41:47 -0800, Mark Janssen wrote: What methods, if any does it provide? Are they all abstract? etc??? Pretty much nothing useful :-) py dir(object) [...] So (prodding the student), Why does everything inherit from Object if it provides no functionality? You cut out the part of my post where I explained that object does in fact provide a minimal set of useful functionality. The example I gave was __eq__ (equal), but there is also __ne__ (not equal), __hash__ (hashing), __str__ and __repr__ (although many classes will wish to override them) and a few more. They're useful, even necessary, but hardly exciting. The other reasons for inheriting from object include: - If all classes are part of a single hierarchy, it must logically end at one (or more, if you support multiple inheritance, which Python does) bases classes. (Unless there are loops, which are generally prohibited in all OOP systems I know of). The simplest way to do this is with a single base class. - Pragmatism: it was the easiest way to unify types and classes way back in Python 2.2, prior to which there was no single hierarchy and all classes were (in a sense) distinct. Pedants will of course realise that Python 2 has *two* object hierarchies, classic classes which don't share a base class, and types (a.k.a. new style classes) which do. In Python 3, classic classes are gone, and there is a single class hierarchy with object the base. There may be other reasons. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: interactive help on the base object
On Monday, December 9, 2013 10:56:28 AM UTC+5:30, ru...@yahoo.com wrote: On 12/08/2013 09:46 PM, rusi wrote: On Monday, December 9, 2013 9:46:30 AM UTC+5:30, Steven D'Aprano wrote: On Sun, 08 Dec 2013 18:58:09 -0800, rusi wrote: [...] Does GG not give you some way of inspecting the post's full headers? Well I spent half hour looking around -- both inside GG and of course searching before asking. If you click on the little down triangle to the right of the reply button for a message, you'll get a menu that includes Show Original. You can see the headers including the Content-Type: in that original. Thanks rurpy -- I only looked for how one may set and not just what is. So now I look at my own post in GG and see Content-Type: text/plain; charset=UTF-8 So far so good. However when I point firefox at my own post in the archive https://mail.python.org/pipermail/python-list/2013-December/662015.html firefox shows encoding as Windows-1252. Note Ive looked at a dozen random pages and for all FF shows encoding as utf-8 except the python list archive ones which show as Win 1252 Note looking into the html I see META http-equiv=Content-Type content=text/html; charset=us-ascii How us-ascii becomes Win-1252 is outside the reach of my meagre intelligence! Though I still suspect something is not quite right with the python mailing-list and/or archive in respect of char encodings. [Am I beginning to sound like jmf is my guru :-) ] -- https://mail.python.org/mailman/listinfo/python-list
Re: interactive help on the base object
Steven D'Aprano st...@pearwood.info writes: - If all classes are part of a single hierarchy, it must logically end at one (or more, if you support multiple inheritance, which Python does) bases classes. (Unless there are loops, which are generally prohibited in all OOP systems I know of). The simplest way to do this is with a single base class. The original Lisp Machine Flavors system (one of the ancestors of the Common Lisp Object System) allowed inheritance to be an arbitrary directed graph -- possibly with cycles. I don't believe that this was done for any deep principled reason, but rather it was just permitted because the algorithm for computing method resolution order didn't actually care whether there were inheritance cycles -- it still terminated and returned an ordered list of component classes. I do not remember seeing any code that made use of this ability, so don't ask me if it was good for anything, but it was definitely there... -- Alan Bawden -- https://mail.python.org/mailman/listinfo/python-list
Re: interactive help on the base object
Mark Lawrence wrote: Is it just me, or is this basically useless? class object | The most base type It's also a somewhat strange construction from an English language point of view. To make sense, it requires interpreting the word base as an adjective, and when used that way it has connotations of something to turn your nose up at. I'm assuming that's not the impression we want to give! Maybe something like The ultimate base class of all classes would be better. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: interactive help on the base object
On 12/7/13 7:10 PM, Gregory Ewing wrote: Mark Lawrence wrote: Is it just me, or is this basically useless? class object | The most base type It's also a somewhat strange construction from an English language point of view. To make sense, it requires interpreting the word base as an adjective, and when used that way it has connotations of something to turn your nose up at. I'm assuming that's not the impression we want to give! Maybe something like The ultimate base class of all classes would be better. I've heard this described as the root of the class hierarchy. -- Ned Batchelder, http://nedbatchelder.com -- https://mail.python.org/mailman/listinfo/python-list
Re: interactive help on the base object
Is it just me, or is this basically useless? class object | The most *base* type [[Terry Reedy:]] How about something like. The default top *superclass* for all Python classes. How 'bout you fools just admit that you didn't realize you've been confused this whole time? (It *is* possible isn't it?) Mr. Ewing says base has to be interpreted as an *adjective* because otherwise it would mean the BOTTOM (like the BASE of the pyramid), while Terry responds that it is the TOP (*super*class). Earlier, Steven D'Aprano wanted to argue that this distinction was irrelevant, but obviously it can't very well be both at once now cannit? Could-the-world-be-so-crazy-confused-and-then-shoot-the-messenger? Sadly, yes. MarkJ Tacoma, Washington -- https://mail.python.org/mailman/listinfo/python-list
Re: interactive help on the base object
On Fri, Dec 6, 2013 at 9:03 AM, Mark Lawrence breamore...@yahoo.co.uk wrote: Is it just me, or is this basically useless? help(object) Help on class object in module builtins: class object | The most base type Surely a few more words, or a pointer to this http://docs.python.org/3/library/functions.html#object, would be better? It's good enough to give anyone that's seen it before a reminder of what it is. pydoc is useless or worse if you don't know anything about what you're reading. For example, the HTML docs frequently point out potential security vulnerabilities in usages of libraries where pydoc does not. (The wording *is* awkward, though.) -- Devin -- https://mail.python.org/mailman/listinfo/python-list
interactive help on the base object
Is it just me, or is this basically useless? help(object) Help on class object in module builtins: class object | The most base type Surely a few more words, or a pointer to this http://docs.python.org/3/library/functions.html#object, would be better? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: interactive help on the base object
On 12/6/2013 12:03 PM, Mark Lawrence wrote: Is it just me, or is this basically useless? help(object) Help on class object in module builtins: class object | The most base type Given that this can be interpreted as 'least desirable', it could definitely be improved. Surely a few more words, How about something like. '''The default top superclass for all Python classes. Its methods are inherited by all classes unless overriden. ''' When you have 1 or more concrete suggestions for the docstring, open a tracker issue. or a pointer to this http://docs.python.org/3/library/functions.html#object, would be better? URLs don't belong in docstrings. People should know how to find things in the manual index. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
