anomaly

zipher dreamingforward at gmail.com
Mon May 11 12:43:49 EDT 2015


On Monday, May 11, 2015 at 10:49:01 AM UTC-5, Skip Montanaro wrote:
> On Mon, May 11, 2015 at 10:11 AM, zipher <dreamingforward at gmail.com> wrote:
> > I also bought the idea of everything as an object, it has a unbeatable purity to it.  But we won't ever get to the point were OOP is like the purity of math because the greatest utility of OOP is working with real-world data.  And that real-world puts bounds on the otherwise abstract purity in which a language is theoretically capable.
> 
> Did someone here say it would? Sure, OOP isn't as pure as math, but
> most object-oriented languages aren't pure OO languages, either.

SKip, it's fine to have a loose definition of things in a language when you're not sure where you want it to go.  I think taking Python into the land of "everything is an object" was a neat exploration.  I even supported it.  But, now that I want to create a data ecosystem, sloppiness in design criteria or inadequacies in implementation gets exercised.  Perhaps it won't be Python's goals, but I would argue that it's the best direction for Python.

These aren't failings of the dev-team either -- no one's done this before.  There are some attempts like CORBA, but either they remained in proprietary domains or they simply weren't capable of scaling to every kind of data.  I've, in fact, had to invent a new data structure to do it, a data structure I'm implementing in Python and where the issue of the *nature* of OOP came to the fore.

For example, have you ever contemplated this:

class WeightedVertex(vertex_common(Vertex(dict))):
    """test class"""

That currently isn't valid Python code, but the idea is that I'm making composite objects that expand one upon the other -- another basic idea in the realm of theoretical OOP that this boneheaded community couldn't wrap it's head around.

Anyway, I'm also saying that it's better to have real design goals when such noble goals can be made, rather than be content with a sloppy flexibility.

> The practicality side of things suggests that even though
> everything-is-an-object isn't perfect, it may be good enough.
> People/projects/companies generally can't afford to follow every
> change that blows through their environment.

True.  Which is why theoretical CS exists -- to find deeper and better abstractions to encompass everything you want to do.  It started with variables, then linked lists, then trees, then graphs and I'm taking that trajectory to it's end point.  It's real Computer Science.  Most people here haven't seemed to understand the power of Graphs yet, or perhaps they just can't agree upon an API so leave out such a powerful data structure.  I'm currently refactoring my own implementation, so that it could be considered for inclusion in the collections module.

Mark

P.S. Sorry for the "boneheaded" insult -- I get called anything from a troll to a drug addict around here.



More information about the Python-list mailing list