Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder1.news.weretis.net!feeder.erje.net!1.eu.feeder.erje.net!newsfeed.xs4all.nl!newsfeed3a.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
MIME-Version: 1.0
In-Reply-To: <CAMjeLr-_jd2wAJJTZRO3+p58hzD+B3UiDyrkhz-Vw-=Lopmrmg@mail.gmail.com>
References: <CAMjeLr--RfnfgWc1hdOcHiEBpq3QwC7SZk-m14wM65JtpbgMLQ@mail.gmail.com> <CAMjeLr-_jd2wAJJTZRO3+p58hzD+B3UiDyrkhz-Vw-=Lopmrmg@mail.gmail.com>
Date: Sun, 10 May 2015 18:26:06 -0500
Subject: Re: anomaly
From: Mark Rosenblitt-Janssen <dreamingforward@gmail.com>
To: python-list@python.org
Content-Type: text/plain; charset=ISO-8859-1
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.325.1431300374.12865.python-list@python.org>
Lines: 76
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:90311

Along those lines, it makes no sense for mix-in classes to inherit
from Object at all -- they're neither expanding on object nor
specializing it.

For example, I'm refactoring my python Graph class so that people can
have different Vertex behaviors by using different composition of
mix-in classes.  But instead of letting them figure out the object
inheritence order (so there's no conflicts), I'm going to make some
classes that pre-specify the right ordering for different
combiniations of behaviors.

class Vertex(object):
    """Basic Vertex base class, giving a dictionary of edges.""""

class WVertex(Vertex, weighted_mixin):  #the weighted_mixin will
override some of the methods in Vertex.
    """Use this when initializing a Graph class for weighted edges."""

class RWVertex(WVertex, reverse_edge_mixin):
    """Use this class for O(1) access to the edges coming into Vertices."""

class Graph(dict):

    def __init__(self, init={}, VertexType=Vertex):
        """Creates a Graph with the specified behaviors within VertexType."""

-----
No one has to see the mix-in classes.

I'm inventing a new term for this kind of inheritence:  expansion.
I've enclosed one class inside of another, but yet it's not quite
"encapsulation" (in the C++ sense).

Cheers,

Mark J
----
http://wiki.hackerspaces.org/Hacking_with_the_Tao


On 5/10/15, Mark Rosenblitt-Janssen <dreamingforward@gmail.com> wrote:
> Here's where this exploration came from.  I've (once again) been
> contemplating the OO nature.
>
> It's clear to me that there needs to be a distinction between
> specialization of an object vs. expansion of an object (a new term I'm
> proposing to the OOP lexicon).  The latter *adds* more functionality
> (like what everyone does with the Object class), while the former
> changes the behavior of some class for more specific behavior that was
> not programmed in the original class.
>
> It's a difference between, for example, concrete base types and ABCs.
> Python artificially tried to make int inherit from object, just
> because it can, but this is wrong.  It`s messed with the Zen-thing.
> "Purity has hammered practicality [like the fact that we actually have
> to work on concrete types in the CPU] into the ground. " (addition
> mine).
>
> Sorry I can't spend more time clarifying.  I hope that there's at
> least one person who sees the issue.
>
> Mark
>
>
>
> On 5/10/15, Mark Rosenblitt-Janssen <dreamingforward@gmail.com> wrote:
>> Here's something that might be wrong in Python (tried on v2.7):
>>
>>>>> class int(str): pass
>>
>>>>> int(3)
>> '3'
>>
>> Mark
>>
>