Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #48968 > unrolled thread

What is the semantics meaning of 'object'?

Back to article view | Back to comp.lang.python

Contents

  What is the semantics meaning of 'object'? Adam <jiang.adam@gmail.com> - 2013-06-22 19:58 -0700
    Re: What is the semantics meaning of 'object'? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-23 03:20 +0000
      Re: What is the semantics meaning of 'object'? Ian Kelly <ian.g.kelly@gmail.com> - 2013-06-22 22:27 -0600
        Re: What is the semantics meaning of 'object'? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-23 05:23 +0000
          Re: What is the semantics meaning of 'object'? Ian Kelly <ian.g.kelly@gmail.com> - 2013-06-22 23:40 -0600
            Re: What is the semantics meaning of 'object'? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-23 17:29 +0000
              Re: What is the semantics meaning of 'object'? Rotwang <sg552@hotmail.co.uk> - 2013-06-24 02:53 +0100
                Re: What is the semantics meaning of 'object'? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-24 06:31 +0000
                  Re: What is the semantics meaning of 'object'? Rotwang <sg552@hotmail.co.uk> - 2013-06-24 16:00 +0100
                    Re: What is the semantics meaning of 'object'? Ian Kelly <ian.g.kelly@gmail.com> - 2013-06-24 11:23 -0600
      Re: What is the semantics meaning of 'object'? Adam Jiang <jiang.adam@gmail.com> - 2013-06-23 22:35 +0900
      Re: What is the semantics meaning of 'object'? Ian Kelly <ian.g.kelly@gmail.com> - 2013-06-23 10:15 -0600
        Re: What is the semantics meaning of 'object'? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-23 16:35 +0000
          Re: What is the semantics meaning of 'object'? Roy Smith <roy@panix.com> - 2013-06-23 12:49 -0400
            Re: What is the semantics meaning of 'object'? Ian Kelly <ian.g.kelly@gmail.com> - 2013-06-23 11:08 -0600
              Re: What is the semantics meaning of 'object'? Roy Smith <roy@panix.com> - 2013-06-23 14:14 -0400
            Re: What is the semantics meaning of 'object'? Ian Kelly <ian.g.kelly@gmail.com> - 2013-06-23 11:18 -0600
              Re: What is the semantics meaning of 'object'? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-23 17:36 +0000
                Re: What is the semantics meaning of 'object'? Ian Kelly <ian.g.kelly@gmail.com> - 2013-06-23 12:04 -0600
                  Re: What is the semantics meaning of 'object'? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-23 18:50 +0000
                    Re: What is the semantics meaning of 'object'? Ian Kelly <ian.g.kelly@gmail.com> - 2013-06-23 13:09 -0600
                      Re: What is the semantics meaning of 'object'? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-24 01:12 +0000
                    Re: What is the semantics meaning of 'object'? Roy Smith <roy@panix.com> - 2013-06-23 15:24 -0400
                      Re: What is the semantics meaning of 'object'? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-24 01:27 +0000
                        Re: What is the semantics meaning of 'object'? Roy Smith <roy@panix.com> - 2013-06-23 21:38 -0400
                          Re: What is the semantics meaning of 'object'? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-24 08:06 +0000
                            Re: What is the semantics meaning of 'object'? Roy Smith <roy@panix.com> - 2013-06-24 08:41 -0400
                    Re: What is the semantics meaning of 'object'? Mark Janssen <dreamingforward@gmail.com> - 2013-06-24 08:58 -0700
                      Re: What is the semantics meaning of 'object'? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-24 23:51 +0000
                    Re: What is the semantics meaning of 'object'? Ian Kelly <ian.g.kelly@gmail.com> - 2013-06-24 11:26 -0600
                    Re: What is the semantics meaning of 'object'? Ethan Furman <ethan@stoneleaf.us> - 2013-06-26 13:14 -0700
                      Re: What is the semantics meaning of 'object'? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-26 23:54 +0000
                        Re: What is the semantics meaning of 'object'? Ian Kelly <ian.g.kelly@gmail.com> - 2013-06-26 19:03 -0600
                        Re: What is the semantics meaning of 'object'? Ethan Furman <ethan@stoneleaf.us> - 2013-06-26 17:38 -0700
            Re: What is the semantics meaning of 'object'? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-23 18:46 +0000
              Re: What is the semantics meaning of 'object'? Ian Kelly <ian.g.kelly@gmail.com> - 2013-06-23 13:05 -0600
              Re: What is the semantics meaning of 'object'? Ethan Furman <ethan@stoneleaf.us> - 2013-06-26 13:37 -0700
            Re: What is the semantics meaning of 'object'? Rick Johnson <rantingrickjohnson@gmail.com> - 2013-06-23 13:33 -0700
          Re: What is the semantics meaning of 'object'? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2013-06-23 21:33 +0200
          Re: What is the semantics meaning of 'object'? Ian Kelly <ian.g.kelly@gmail.com> - 2013-06-25 11:44 -0600
          Re: What is the semantics meaning of 'object'? Mark Janssen <dreamingforward@gmail.com> - 2013-06-25 14:58 -0700
          Re: What is the semantics meaning of 'object'? Chris Angelico <rosuav@gmail.com> - 2013-06-26 08:17 +1000
          Re: What is the semantics meaning of 'object'? Ian Kelly <ian.g.kelly@gmail.com> - 2013-06-25 16:21 -0600
          Re: What is the semantics meaning of 'object'? Ian Kelly <ian.g.kelly@gmail.com> - 2013-06-25 16:25 -0600
          Re: What is the semantics meaning of 'object'? Mark Janssen <dreamingforward@gmail.com> - 2013-06-25 15:29 -0700
          Re: What is the semantics meaning of 'object'? Mark Janssen <dreamingforward@gmail.com> - 2013-06-25 15:27 -0700
          Re: What is the semantics meaning of 'object'? Mark Janssen <dreamingforward@gmail.com> - 2013-06-25 15:38 -0700
          Re: What is the semantics meaning of 'object'? Chris Angelico <rosuav@gmail.com> - 2013-06-26 08:39 +1000
          Re: What is the semantics meaning of 'object'? Chris Angelico <rosuav@gmail.com> - 2013-06-26 08:47 +1000
          Re: What is the semantics meaning of 'object'? Chris Angelico <rosuav@gmail.com> - 2013-06-26 08:57 +1000
            Re: What is the semantics meaning of 'object'? Rotwang <sg552@hotmail.co.uk> - 2013-06-26 16:16 +0100
              Re: What is the semantics meaning of 'object'? Chris Angelico <rosuav@gmail.com> - 2013-06-27 01:23 +1000
          Re: What is the semantics meaning of 'object'? Ian Kelly <ian.g.kelly@gmail.com> - 2013-06-25 17:07 -0600
          Re: What is the semantics meaning of 'object'? Chris Angelico <rosuav@gmail.com> - 2013-06-26 09:08 +1000
          Re: What is the semantics meaning of 'object'? Ian Kelly <ian.g.kelly@gmail.com> - 2013-06-25 17:10 -0600
          Re: What is the semantics meaning of 'object'? Mark Janssen <dreamingforward@gmail.com> - 2013-06-25 16:19 -0700
            Re: What is the semantics meaning of 'object'? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-26 08:36 +0000
            Re: What is the semantics meaning of 'object'? alex23 <wuwei23@gmail.com> - 2013-06-28 10:19 +1000
              Re: What is the semantics meaning of 'object'? Mark Janssen <dreamingforward@gmail.com> - 2013-06-28 11:55 -0700
          Re: What is the semantics meaning of 'object'? Mark Janssen <dreamingforward@gmail.com> - 2013-06-25 16:00 -0700
          Re: What is the semantics meaning of 'object'? Ian Kelly <ian.g.kelly@gmail.com> - 2013-06-25 18:19 -0600
          Re: What is the semantics meaning of 'object'? Mark Janssen <dreamingforward@gmail.com> - 2013-06-25 18:07 -0700
          Re: What is the semantics meaning of 'object'? Chris Angelico <rosuav@gmail.com> - 2013-06-26 17:25 +1000
          Re: What is the semantics meaning of 'object'? Ian Kelly <ian.g.kelly@gmail.com> - 2013-06-26 02:53 -0600
          Re: What is the semantics meaning of 'object'? Chris Angelico <rosuav@gmail.com> - 2013-06-26 09:54 +1000
          Re: What is the semantics meaning of 'object'? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2013-06-26 12:56 +0200
        Re: What is the semantics meaning of 'object'? Rick Johnson <rantingrickjohnson@gmail.com> - 2013-06-23 13:12 -0700

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#49191

> This bothers me as well.  If you look at Raymond Hettinger's "super()
> considered super" article, he includes the (correct) advice that
> super() needs to be used at every level of the call chain.  At the end
> of the article, he offers this example to show how "easy" multiple
> inheritance can be:
> [...]
> oc = OrderedCounter('abracadabra')
>
> Which is pretty cool in its simplicity, but here's the rub (which I
> have previously noted on this list): OrderedDict doesn't use super.
> Counter does, but not cooperatively; it just calls super().__init__()
> with no arguments.  So the fact that this example works at all is
> basically luck.

Ah, and here we see the weakness in the object architecture that has
evolved in the past decade (not just in Python, note).  It hasn't
really ironed out what end is what.   Here's a proposal:  the highest,
most "parental", most general object should be in charge, not
subclasses calling specific parent's init methods
(Parent.__init__(myparams)), etc. -- ***THIS IS WHERE WE WENT
WRONG***.

After the "type/class unification", python tried to make the most
generic, most useless class be the parent of *all of them*, but
there's been no use whatsoever in that.  It was a good idea in the
beginning, so pure as it was, but it has not panned out in practice.
Sorry...

I'm trying to start a recovery plan at the wikiwikiweb
(http://c2.com/cgi/wiki?WikiWikiWeb) and I don't want to hear any more
smarmy comments about it.  The confusion is deeper than Python.
-- 
MarkJ
Tacoma, Washington

[toc] | [prev] | [next] | [standalone]

#49192

On Wed, Jun 26, 2013 at 3:44 AM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
> On Sun, Jun 23, 2013 at 1:33 PM, Antoon Pardon
> <antoon.pardon@rece.vub.ac.be> wrote:
>> Op 23-06-13 18:35, Steven D'Aprano schreef:
>>> Please don't. This is false economy. The time you save will be trivial,
>>> the overhead of inheritance is not going to be the bottleneck in your
>>> code, and by ignoring super, you only accomplish one thing:
>>>
>>> - if you use your class in multiple inheritance, it will be buggy.
>>
>>
>> Which is why I don't understand that the python standard library still
>> contains that kind of code. At least it did in 3.2 and I saw nothing
>> in the 3.3 release notes that would make me suspect this has changed.
>
> This bothers me as well.  If you look at Raymond Hettinger's "super()
> considered super" article, he includes the (correct) advice that
> super() needs to be used at every level of the call chain.  At the end
> of the article, he offers this example to show how "easy" multiple
> inheritance can be:
>
> from collections import Counter, OrderedDict
>
> class OrderedCounter(Counter, OrderedDict):
>      'Counter that remembers the order elements are first seen'
>      def __repr__(self):
>          return '%s(%r)' % (self.__class__.__name__,
>                             OrderedDict(self))
>      def __reduce__(self):
>          return self.__class__, (OrderedDict(self),)
>
> oc = OrderedCounter('abracadabra')
>
> Which is pretty cool in its simplicity, but here's the rub (which I
> have previously noted on this list): OrderedDict doesn't use super.
> Counter does, but not cooperatively; it just calls super().__init__()
> with no arguments.  So the fact that this example works at all is
> basically luck.

The main problem is getting to the top/end of the call chain. Classic
example is with __init__, but the same problem can also happen with
other calls. Just a crazy theory, but would it be possible to
construct a black-holing object that, for any given method name,
returns a dummy function that ignores its args? (Other forms of
attribute lookup aren't going to be a problem, I think, so this can be
just methods/functions.) Then you just subclass from that all the
time, instead of from object itself, and you should be able to safely
call super's methods with whatever kwargs you haven't yourself
processed. Would that work?

Caveat: I have not done much with MI in Python, so my idea may be
complete balderdash.

ChrisA

[toc] | [prev] | [next] | [standalone]

#49194

On Tue, Jun 25, 2013 at 3:58 PM, Mark Janssen <dreamingforward@gmail.com> wrote:
> Ah, and here we see the weakness in the object architecture that has
> evolved in the past decade (not just in Python, note).  It hasn't
> really ironed out what end is what.   Here's a proposal:  the highest,
> most "parental", most general object should be in charge, not
> subclasses calling specific parent's init methods
> (Parent.__init__(myparams)), etc. -- ***THIS IS WHERE WE WENT
> WRONG***.
>
> After the "type/class unification", python tried to make the most
> generic, most useless class be the parent of *all of them*, but
> there's been no use whatsoever in that.  It was a good idea in the
> beginning, so pure as it was, but it has not panned out in practice.
> Sorry...

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.

[toc] | [prev] | [next] | [standalone]

#49196

On Tue, Jun 25, 2013 at 4:17 PM, Chris Angelico <rosuav@gmail.com> wrote:
> The main problem is getting to the top/end of the call chain. Classic
> example is with __init__, but the same problem can also happen with
> other calls. Just a crazy theory, but would it be possible to
> construct a black-holing object that, for any given method name,
> returns a dummy function that ignores its args? (Other forms of
> attribute lookup aren't going to be a problem, I think, so this can be
> just methods/functions.) Then you just subclass from that all the
> time, instead of from object itself, and you should be able to safely
> call super's methods with whatever kwargs you haven't yourself
> processed. Would that work?

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.

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

[toc] | [prev] | [next] | [standalone]

#49198

> 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....
-- 
MarkJ
Tacoma, Washington

[toc] | [prev] | [next] | [standalone]

#49199

> The main problem is getting to the top/end of the call chain. Classic
> example is with __init__, but the same problem can also happen with
> other calls. Just a crazy theory, but would it be possible to
> construct a black-holing object that, for any given method name,
> returns a dummy function that ignores its args? (Other forms of
> attribute lookup aren't going to be a problem, I think, so this can be
> just methods/functions.) Then you just subclass from that all the
> time, instead of from object itself, and you should be able to safely
> call super's methods with whatever kwargs you haven't yourself
> processed. Would that work?
>
> Caveat: I have not done much with MI in Python, so my idea may be
> complete balderdash.

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.

In other words, this habit of specializing a Class to make up for the
weaknesses of its parent are THE WRONG WAY.   Instead, let the
specialization start at the machine types (where it doesn't get more
specialized), and work UPWARDS.

Let the standard library make the grouping (or collection types) to
point to the standard way of data structuring, and then everything
else becomes little mini-apps making a DataEcosystem.

--mark

[toc] | [prev] | [next] | [standalone]

#49202

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.

-- 
MarkJ
Tacoma, Washington

[toc] | [prev] | [next] | [standalone]

#49203

On Wed, Jun 26, 2013 at 8:25 AM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
> On Tue, Jun 25, 2013 at 4:17 PM, Chris Angelico <rosuav@gmail.com> wrote:
>> The main problem is getting to the top/end of the call chain. Classic
>> example is with __init__, but the same problem can also happen with
>> other calls. Just a crazy theory, but would it be possible to
>> construct a black-holing object that, for any given method name,
>> returns a dummy function that ignores its args? (Other forms of
>> attribute lookup aren't going to be a problem, I think, so this can be
>> just methods/functions.) Then you just subclass from that all the
>> time, instead of from object itself, and you should be able to safely
>> call super's methods with whatever kwargs you haven't yourself
>> processed. Would that work?
>
> 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

[toc] | [prev] | [next] | [standalone]

#49204

On Wed, Jun 26, 2013 at 8:27 AM, Mark Janssen <dreamingforward@gmail.com> wrote:
> 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

[toc] | [prev] | [next] | [standalone]

#49206

On Wed, Jun 26, 2013 at 8:38 AM, Mark Janssen <dreamingforward@gmail.com> wrote:
> 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

[toc] | [prev] | [next] | [standalone]

#49263

On 25/06/2013 23:57, Chris Angelico wrote:
> On Wed, Jun 26, 2013 at 8:38 AM, Mark Janssen <dreamingforward@gmail.com> wrote:
>> 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?

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.

[toc] | [prev] | [next] | [standalone]

#49265

On Thu, Jun 27, 2013 at 1:16 AM, Rotwang <sg552@hotmail.co.uk> wrote:
> On 25/06/2013 23:57, Chris Angelico wrote:
>>
>> On Wed, Jun 26, 2013 at 8:38 AM, Mark Janssen <dreamingforward@gmail.com>
>> wrote:
>>>
>>> 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?
>
>
> 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.

Yeah, I don't think Mark is much concerned about implementing things
on actual computers, somehow :)

ChrisA

[toc] | [prev] | [next] | [standalone]

#49207

On Tue, Jun 25, 2013 at 4:38 PM, Mark Janssen <dreamingforward@gmail.com> wrote:
> 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.

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.

[toc] | [prev] | [next] | [standalone]

#49208

On Wed, Jun 26, 2013 at 9:00 AM, Mark Janssen <dreamingforward@gmail.com> wrote:
>> 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.

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

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

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

[toc] | [prev] | [next] | [standalone]

#49209

On Tue, Jun 25, 2013 at 5:07 PM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
> On Tue, Jun 25, 2013 at 4:38 PM, Mark Janssen <dreamingforward@gmail.com> wrote:
>> 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?

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.

[toc] | [prev] | [next] | [standalone]

#49210

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

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

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

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?
-- 
MarkJ
Tacoma, Washington

[toc] | [prev] | [next] | [standalone]

#49235

On Tue, 25 Jun 2013 16:19:08 -0700, Mark Janssen wrote:

> 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


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#49353

On 26/06/2013 9:19 AM, Mark Janssen wrote:
> Did you ever hear of the Glass Bead Game?

Which was Hesse's condemnation of the 
pure-academic-understanding-unbound-by-pragmatic-use approach as mental 
masturbation, _not_ a recommendation for how human knowledge should 
work. If you think otherwise, you might want to read the last few 
chapters again.

[toc] | [prev] | [next] | [standalone]

#49406

> On 26/06/2013 9:19 AM, Mark Janssen wrote:
>>
>> Did you ever hear of the Glass Bead Game?
>
> Which was Hesse's condemnation of the
> pure-academic-understanding-unbound-by-pragmatic-use approach as mental
> masturbation,

It was not.  He was conflicted.  On the one hand he knew the
enterprise was noble, but on the other he saw it could lead to crystal
palaces that were good to nobody.
-- 
MarkJ
Tacoma, Washington

[toc] | [prev] | [next] | [standalone]

#49211

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

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.

-- 
MarkJ
Tacoma, Washington

[toc] | [prev] | [next] | [standalone]

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

Back to top | Article view | comp.lang.python

csiph-web