What is the semantics meaning of 'object'?

[Mark Janssen]

So instead of super(), you would have sub()? It's an interesting

concept, but I don't think it changes anything. You still have to
design your classes cooperatively if you expect to use them with
multiple inheritance.

Yes, and let new instances of the child classes automatically ensure
the contracts of the parent classes. I suppose it could be called
delegation....

 

[Mark Janssen]

Sorry my last message got sent prematurely. Retrying...

So instead of super(), you would have sub()? It's an interesting
concept, but I don't think it changes anything. You still have to
design your classes cooperatively if you expect to use them with
multiple inheritance.

Yes, and let new instances of the child classes automatically ensure
the contracts of the parent classes -- managed within the Python
interpreter, not the developer.

As for sub(), I suppose it could be called delegate().

The issue of classes cooperating isn't as big as it seems, because
since you're working now from a useful, agreed-upon common base (the
non-negotiable, but also non-arbitrary) machine types, you're now all
(the python and ideally the *object* community) speaking the same
language. Who's going to argue about integers (as the atomic type)
and sets (as the most basic grouping type) being THE common set of
bases for everything else? I mean, it doesn't get anymore ideal and
pure than integers and sets. Combining integers with sets I can make
a Rational class and have infinite-precision arithmetic, for example.

That's a lot of power derived simply from using generic data
structures, not some panzy generic meta-Object that doesn't do
anything but tie people to an implicit type-theology.

 

[Chris Angelico]

class BlackHole(object):
def __getattr__(self, attr):
return lambda *args, **kwargs: None

There's no way to restrict it to just methods, because there's no
fundamental difference in Python between methods and other attributes,
and at the point that you're looking it up you have no way of knowing
whether the result is about to be called or not.

Right, but what I mean is that you don't need any sort of
special-casing to pick an object type to return. Just return a
function, because that's going to be safe.

And even if there were, this would be an excellent way to hide bugs.

Ehh, true. Don't know a way around that one. Meh.

ChrisA

 

[Chris Angelico]

Here's how it *should* be made: the most superest, most badassed
object should take care of its children. New instances should
automatically call up the super chain (and not leave it up to the
subclasses), so that the parent classes can take care of the chil'en.
When something goes wrong the parent class has to look in and see
what's wrong.

So what you're saying is that the first class defined does everything,
and subclasses _restrict_ what can be done? I disagree strongly:

1) That breaks the Liskov Substitution Principle. A subclass of list
ought to fulfill the contracts of a basic list.

2) It implies that someone can invent an all-encompassing superclass
before any subclassing is done. This kinda violates the laws of
information. Programmers, being creative entities, will be adding to
the pool of knowledge. Trying to shoehorn everything into one object
won't work.

It may be that you're not saying that, but you mean that the
superclass decides which subclass's method to call. If that's what you
meant, then I really don't know how it would be any different from the
object itself making that decision, which is how things currently are.
Or are both these interpretations wrong?

ChrisA

 

[Chris Angelico]

Combining integers with sets I can make
a Rational class and have infinite-precision arithmetic, for example.

Combining two integers lets you make a Rational. Python integers are
already infinite-precision. Or are you actually talking of using
"machine words" and sets as your fundamental? Also, you need an
ordered set - is the set {5,3} greater or less than the set {2} when
you interpret them as rationals? One must assume, I suppose, that any
one-element set represents the integer 1, because any number divided
by itself is 1. Is the first operand 3/5 or 5/3?

That's a lot of power derived simply from using generic data
structures, not some panzy generic meta-Object that doesn't do
anything but tie people to an implicit type-theology.

Sure. And if you want assembly language, you know where to find it.
Personally, I don't want to have to code the fundamentals of data
structures in Python - that's C's job. The details of hashing
algorithms, fill factors, collision handling, and so on, are the
concern of the dict implementation, and unless there's a good reason
to dig into it (like when I'm explaining to my boss about a
hash-collision attack and why it means we have to upgrade to a newer
interpreter version), I don't care about the minutiae.

What you're doing is actually in the same theological / theoretical
level as what you're complaining of. It's equivalent to pointing out
that every single data structure you use, and every piece of
information in this world, can be represented with an aggregation of
the digits 1 and 0 - that's an awesomely powerful, clean, and
all-encompassing abstraction, but in day-to-day life, we really don't
need to think about it.

ChrisA

 

[Mark Janssen]

Here's how it *should* be made: the most superest, most badassed

So what you're saying is that the first class defined does everything,
and subclasses _restrict_ what can be done? I disagree strongly:

That's right. Just as the *machine* restricts what can be done. It's
an upturning of the purity model and going back to practicality.

1) That breaks the Liskov Substitution Principle. A subclass of list
ought to fulfill the contracts of a basic list.

We don't need LSP. I write about this on the WIkiWikiWeb where there
were many arguments documented and many hairs frazzled. LSP was
derived from AlanKay's abstract idea of "Everything is an object".
But no -- there is a *physics* for information, and it ends at the
machine types.

2) It implies that someone can invent an all-encompassing superclass
before any subclassing is done.

No, we start with basic types and work upwards. The
"all-encompassing" superclass it an all-encompassing data object: in
mathematics, it's called a SET -- and mathematics has already done the
work to prove that it's the most generic and all-encompassing, a field
of SET THEORY.

This kinda violates the laws of
information. Programmers, being creative entities, will be adding to
the pool of knowledge. Trying to shoehorn everything into one object
won't work.

No, we don't need programmers adding to the "pool of knowledge" -- the
internet does that. We need programmers making data objects that can
present data in new and more interesting ways -- starting from basic
principles.

 

[Ian Kelly]

Sorry my last message got sent prematurely. Retrying...


Yes, and let new instances of the child classes automatically ensure
the contracts of the parent classes -- managed within the Python
interpreter, not the developer.

It sounds like you want to be using Eiffel, not Python.

As for sub(), I suppose it could be called delegate().

You can call it that, but you'll just be muddying the waters since
there's already a perfectly good pattern by that name, which involves
having multiple distinct objects and has nothing to do with
inheritance.

The issue of classes cooperating isn't as big as it seems, because
since you're working now from a useful, agreed-upon common base (the
non-negotiable, but also non-arbitrary) machine types, you're now all
(the python and ideally the *object* community) speaking the same
language. Who's going to argue about integers (as the atomic type)
and sets (as the most basic grouping type) being THE common set of
bases for everything else? I mean, it doesn't get anymore ideal and
pure than integers and sets. Combining integers with sets I can make
a Rational class and have infinite-precision arithmetic, for example.

I don't see how this solves anything. At some point you have to be
able to add methods and attributes to your objects. For example, your
Rational class is going to need some sort of "reduce" method to reduce
a Rational instance to lowest terms. That's not a method that belongs
on an integer or set type. If you can't add functionality, then all
you will ever have are integers and sets, and if you can add
functionality, then what difference does it make what your fundamental
base class is?

From a programming perspective, I think it is proper that "object" is

the most fundamental base class, because all it has is identity.
Integers and sets add other functionality on top of that.

 

[Chris Angelico]

We don't need LSP. I write about this on the WIkiWikiWeb where there
were many arguments documented and many hairs frazzled. LSP was
derived from AlanKay's abstract idea of "Everything is an object".
But no -- there is a *physics* for information, and it ends at the
machine types.

Then you're talking about composition, not inheritance. We already
have that - just declare a new type that consists only of other,
simpler, types. That's the way class definitions work. (Okay, in
Python it's a little different because everything's dynamic, but still
there's a general concept that you're building the complex from the
simple - a Point from a number of integers, a Shape2D from a number of
points, etc.)

No, we don't need programmers adding to the "pool of knowledge" -- the
internet does that. We need programmers making data objects that can
present data in new and more interesting ways -- starting from basic
principles.

The internet creates knowledge all on its own? Wow. The Singularity
has been reached!

No. Programmers add to code. That's what we get paid for. All those
commits going onto source control aren't the creation of the internet.

ChrisA

 

[Ian Kelly]

I don't see how this solves anything. At some point you have to be
able to add methods and attributes to your objects. For example, your
Rational class is going to need some sort of "reduce" method to reduce
a Rational instance to lowest terms. That's not a method that belongs
on an integer or set type. If you can't add functionality, then all
you will ever have are integers and sets, and if you can add
functionality, then what difference does it make what your fundamental
base class is?

Oh, and just in case you're not aware, Python already has a Fraction
class that supports unlimited-precision arithmetic. It doesn't need
to inherit from tuple to accomplish this, and in fact that would be a
bad way to approach it, since a fraction is *not* a tuple.

 

[Mark Janssen]

Combining integers with sets I can make

Combining two integers lets you make a Rational.

Ah, but what is going to group them together? You see you've already
gotten seduced. Python already uses a set to group them together --
it's called a Dict and it's in every Class object.

Python integers are
already infinite-precision. Or are you actually talking of using
"machine words" and sets as your fundamental?

Probably. It depends on where we need the flexibility of the
abstraction and where the code is written.

Also, you need an
ordered set - is the set {5,3} greater or less than the set {2} when
you interpret them as rationals?

The ordering (and hence the interpretation) is done WITHIN the Class
(i.e. the SET as I say above).

One must assume, I suppose, that any
one-element set represents the integer 1, because any number divided
by itself is 1.

Ah, very good, observation. But that must remain an improper question. ;^)

Sure. And if you want assembly language, you know where to find it.

Well you've been spoiled by all the work that came before you. The
issue now is not to go "back to the machine" so much as to tear down
and build up again from raw materials, objects of more and more
complexity where very complex "meta-objects" upon meta-objects can be
built until the "whole of human knowledge can be contained".

Did you ever hear of the Glass Bead Game?

 

[Chris Angelico]

Did you ever hear of the Glass Bead Game?

Yeah, it's Magic: The Gathering and its counters.

http://www.wizards.com/magic/magazine/Article.aspx?x=mtgcom/daily/mr195



ChrisA

 

[Ian Kelly]

Ah, but what is going to group them together? You see you've already
gotten seduced. Python already uses a set to group them together --
it's called a Dict and it's in every Class object.

When you inherit a "set" to make a Rational, you're making the
statement (to the interpreter, if nothing else) that a Rational is-a
set.

When a Python class uses an instance dict to store the numerator and
denominator of a Fraction, it's not *inheriting* Fraction from dict,
which is good because a Fraction is not a dict. It's merely *using* a
dict. It comes back once again to the distinction between inheritance
and composition.

The ordering (and hence the interpretation) is done WITHIN the Class
(i.e. the SET as I say above).

So "set" is just your name for a class? I understood earlier that
with integers and sets you were trying to derive your type system from
number theory. Now it sounds like you want sets to be containers of
attributes. Which is it?

 

[Mark Janssen]

Combining two integers lets you make a Rational.

When you inherit a "set" to make a Rational, you're making the
statement (to the interpreter, if nothing else) that a Rational is-a
set.

No you don't *inherit* a set to make a Rational, although you gain a
set to make it. It's a subtle thing, because at the center of it
articulates the very difference between a piece of data and a
container to hold that data. Or is the container the data?

C++ already solves this di-lemma. It made "class" which is exactly
like a "struct", but hides all it's data members. That critical
distinction makes all the difference. I don't know how many people on
the list really appreciate it.

 

[Chris Angelico]

No you don't *inherit* a set to make a Rational, although you gain a
set to make it. It's a subtle thing, because at the center of it
articulates the very difference between a piece of data and a
container to hold that data. Or is the container the data?

C++ already solves this di-lemma. It made "class" which is exactly
like a "struct", but hides all it's data members. That critical
distinction makes all the difference. I don't know how many people on
the list really appreciate it.

I certainly don't. In fact, I hardly use "class" in C++ these days - I
just use "struct" and let the members be public. How is that
significant?

The thing you're completely missing, though, is that NONE of what
you're saying has anything to do with inheritance or super(). It's all
composition.

ChrisA

 

[Steven D'Aprano]

Well you've been spoiled by all the work that came before you. The
issue now is not to go "back to the machine" so much as to tear down and
build up again from raw materials, objects of more and more complexity
where very complex "meta-objects" upon meta-objects can be built until
the "whole of human knowledge can be contained".

It must be a wonderful view from way, way up there, but how do you
breathe?

http://www.joelonsoftware.com/items/2008/05/01.html

 

[Ian Kelly]

No you don't *inherit* a set to make a Rational, although you gain a
set to make it.

Okay, then. Since you started this discussion from the topic of
multiple inheritance I was under the impression that you were talking
about using inheritance to construct Rationals from integers and sets.
Evidently that is not so, and you've been talking about composition
all along, in which case I have no idea how any of this relates to
your original suggestion of putting superclasses "in charge" of their
subclasses.

 

[Antoon Pardon]

Op 26-06-13 00:27, Mark Janssen schreef:

Here's how it *should* be made: the most superest, most badassed
object should take care of its children. New instances should
automatically call up the super chain (and not leave it up to the
subclasses), so that the parent classes can take care of the chil'en.
When something goes wrong the parent class has to look in and see
what's wrong.

Could you explain why you think it should work this way? Maybe illustrate
how this is supposed to work.

Let take a very simple example. We have a class that works with a stream
(anything with a write method).

class Streamer:
def __init__(self, strm):
...

Now we find that we very often use this class with a file, so we would
like to make a subclass that takes a filename as parameter. This we would
write somehow like the following

class Filer(Streamer):
def __init__(self, fn):
fl = open(fn, "a+")
super.__init__(fl)
...


Can you explain how this example should be written en work as you view things?

 

[Rotwang]

Combining two integers lets you make a Rational. Python integers are
already infinite-precision. Or are you actually talking of using
"machine words" and sets as your fundamental? Also, you need an
ordered set - is the set {5,3} greater or less than the set {2} when
you interpret them as rationals? One must assume, I suppose, that any
one-element set represents the integer 1, because any number divided
by itself is 1. Is the first operand 3/5 or 5/3?

You could use Kuratowski ordered pairs:

http://en.wikipedia.org/wiki/Ordered_pair#Kuratowski_definition

Not that doing so would be sensible, of course. I don't know much about
low-level data structures but it seems obvious that it's much easier to
implement an ordered container type than an unordered set on a computer.

 

[Ethan Furman]

What else would you call a function that does lookups on the current
object's superclasses?

Well, I would call it super(). Trouble is, that is not all that super() does. Going back to Ian's example:

Notice how Base1 calls super(), but depending on circumstances, it could by Base2 that super() calls. Surely you are
not suggesting that Base2 is therefore an ancestor of Base1?

It's too late to change the name now, but pretending there is no good and valid reason for confusion doesn't help.

 

[Ethan Furman]

I don't like the idea of doing this with a cooperative __init__
method. If any keyword arguments were passed that weren't consumed,
that is probably a bug, and this just swallows the exception instead
of reporting it.
+1

Z
Of course, if you're doing cooperative inheritance with some other
method that doesn't exist on object, then this technique is necessary
to prevent the topmost class from trying to call that method on object
and erroring out.

But in that case the Blocker wouldn't call super since it is acting as the base class.