interactive help on the base object

[Mark Lawrence]

Is it just me, or is this basically useless?
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?

 

[Gregory Ewing]

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.

 

[Ned Batchelder]

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."

 

[Mark Janssen]

Is it just me, or is this basically useless?

[[Terry Reedy:]]
How about something like.
The default top *superclass* for all Python classes.

How 'bout you foo<l>s 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

 

[Steven D'Aprano]

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 foo<l>s 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
||
||
||
\ || /
\||/

 

[Ned Batchelder]

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 foo<l>s 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.

 

[Mark Janssen]

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 foo<l>s 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 "foo"s 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

 

[Gregory Ewing]

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!

 

[Chris Angelico]

(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:
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/

 

[Mark Janssen]

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

 

[Chris Angelico]

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 pair<employee,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

 

[Steven D'Aprano]

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 foo<l>s 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 "foo"s 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 your bitless
Object becomes a machine word that is the base of all your types.

You seem to be labouring under the delusion that inheritance, which is a
high-level concept which only applies to objects, goes "all the way down"
to low-level concepts like words and bits.

Objects do not *inherit* from bits. They are *composed* of bits.

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).

You haven't actually programmed in C++ have you?

There's no shame in answering that you haven't. I've never programmed in
C++. It's on my to-do list, after giving myself an appendectomy with a
dull rusty knife and just ahead of buying the complete collection of
Justin Bieber albums. But even I know that you cannot inherit from native
types, on account that they aren't objects.

Have you caught it by now, friends: IT MATTERS TO THE COMPUTER.

How the hell does the computer know which way I draw my class diagrams?

 

[Ian Kelly]

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 "foo"s 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.

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.

 

[Ned Batchelder]

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 foo<l>s 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 "foo"s 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 your bitless
Object becomes a machine word that is the base of all your types.

You seem to be labouring under the delusion that inheritance, which is a
high-level concept which only applies to objects, goes "all the way down"
to low-level concepts like words and bits.

Objects do not *inherit* from bits. They are *composed* of bits.

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).

You haven't actually programmed in C++ have you?

There's no shame in answering that you haven't. I've never programmed in
C++. It's on my to-do list, after giving myself an appendectomy with a
dull rusty knife and just ahead of buying the complete collection of
Justin Bieber albums. But even I know that you cannot inherit from native
types, on account that they aren't objects.

Have you caught it by now, friends: IT MATTERS TO THE COMPUTER.

How the hell does the computer know which way I draw my class diagrams?

And the cycle continues:

1. A thread mentions some fundamental aspect of computing.

2. Mark Janssen jumps in to hint that we are all confused, and he knows
how things should really work, with no details.

3. The discussion expands to the point of Mark making some claim which
sounds close to a truth, but seems actually wrong ("It matters to the
computer").

4. Reasonable people try to engage in an actual discussion of what was said.

5. (Coming next) Mark ignores the bulk of the discussion, picks out one
detail, and continues making snide and incorrect remarks, skittering
away from the light of reason.

Maybe we could just not?

 

[Mark Lawrence]

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.


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

 

[Steven D'Aprano]

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.

 

[rusi]

[...]
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...]

 

[Steven D'Aprano]

[...]
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


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.

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.

 

[rusi]

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!)

 

[Roy Smith]

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?