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

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

Re: anomaly

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: anomaly Mark Rosenblitt-Janssen <dreamingforward@gmail.com> - 2015-05-10 18:26 -0500

#90311 — Re: anomaly

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

[toc] | [standalone]

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

csiph-web