[Python-ideas] Message passing syntax for objects

[Mark Janssen]

On Mon, Mar 18, 2013 at 5:39 PM, Steven D'Aprano <steve at pearwood.info> wrote:
>>> >So you've replaced one method of a collections API by your magical
>>> > operator,
>>> >for all collections.
>>
>> Yes -- for all collections.  That's a pretty big gain right?
>
> No, not at all. If it's a gain at all, it's a tiny, microscopic gain. But
> it's not a gain. We lose a lot:
>
> - we can no longer distinguish between *adding* something to an unordered
> collection, and *appending* to an ordered collection;

Your ClassName or __doc__ is supposed to make that clear, because your
API doesn't.  This is the problem I'm referring to when I talk about
"hyper-personal API's" -- you have to learn the programmer's personal
language.  Even 15 years of python append and extend are still
ambiguous and confusing.  You've adapted to this.

> - we can no longer distinguish between (for example) *appending* to the end
> of a list, *extending* a list with a sequence, and *inserting* somewhere
> inside a list.

Well, these are old data paradigm operations which will go away in my
view.  The very thinking in terms of "lists within lists" is very
personal and no one else will be able to use whatever you're building.

> - we cannot even distinguish between "put this thing in your collection" and
> "search your collection for this thing", since we're limited to a single >>
> "send message" operator.

Ummm, perhaps you missed something in Python: "search your collection
for this thing" is done with "in"; i.e. , "item in myObject".  That
already is TOWTDI way to do it.  Obviously, the first item is already
handled with the messaging operator.

> E.g. what syntax would you use for something like this? [...]

Keeping in mind, this idea would require a major refactoring of the
standard library.  Instead of these very ornate (byzantine?) complex
classes, we have many smaller, more universal/general classes,
building up to the complexity desired (like Unix pipes did for shell
scripting, files, and the O.S.).  Those "universals" haven't been
conceived yet for Python, so I don't know yet what it will look like.

> * Open a file with that name.

Why does everyone seem to pick the most corner-type cases?  As this is
about a "universal data model", issues with interacting within the
existing operating system becomes an issue and has to be specially
handled.  So you have to ask how deep you want me to go in this
architectural model I'm envisioning, because as it is a universal
model, ultimately the O.S. changes radically (which is why I was
suggesting that the issue of Python async behavior be postponed).

But now that you have me thinking on it, I see the file system as
being composed of namespaces organized in a tree.  The Python
interpreter would access them directly.

Mark