LangWart: Method congestion from mutate multiplicty

[Mark Janssen]

On Sun, Feb 10, 2013 at 6:29 AM, Steven D'Aprano
<steve+comp.lang.python at pearwood.info> wrote:
> Mark Janssen wrote:
>> I have to agree with Rick, I think requiring the user to explicitly
>> create a new object, which is already a good and widely-used practice,
>
> Perhaps so, but consider how you creates new objects in Python. Very rarely
> do you do so with an explicit call to the constructor. For example:
>
> n = 5  # Yes.
> # or
> n = int("5")  # No.

Good, alright, this is the point where the concept of a unified object
model comes into play.  (Actually, I'm going to say "unified data
model" (or UDM) from now on so as to avoid the confusion that you
point out below that Python seems to already have a "unified object
model" because everything derives from "Object".  The point is
actually rather subtle.)

A unified data model as I define it, specifies a canonical atomic unit
(like the unit integer) and an abstract grouping construct in which
these atomic units can be arranged.  By themselves, these two can
construct arbitrary levels of data structure complexity.  Add the
ability to apply names to these levels, and you have a complete data
model for a happy programming environment.  My work, to give you some
context, involves the invention of a "fractal graph" which is where
the name "unified object model" came from, because a fractal graph, I
argue can represent every part of the physical world at every scale.

(Note that everything in a computer is series of these "atomic" bits
organized by the machine into "words" (merely for sake of the
efficiency that such parallelization affords), yet we have these
human-language constructs such as lists and sets (or records, files,
arrays, etc) where *no such things exist in the computer*.   Hence,
the usefulness of considering a unified data model as part of the
computer *science*.)

In your example above, you can verify, for example, that the identity
of 5 and int("5") is the same -- even though you're using a
constructor syntax, you're not *constructing* anything at all, which
you may know already (somewhere in the Python docs, Guido points out
that Python pre-constructs the first 100 or so integers as I recall.)
There is, in addition, an implicit constructor for integers, such that
saying 656565 in python will actually construct the integer as if you
said "int("656565")".

In any case, one never operates or concerns oneself with copies of
atomic elements because they are all the same.  It's a subtle
meta-philosophical(?) point, not that different that that which occurs
in the science of physics regarding electrons and protons ("Is there
only one electron?":
http://en.wikipedia.org/wiki/One-electron_universe).

> py> import this
> [...]
> There should be one-- and preferably only one --obvious way to do it.

Yes, that is the reference.

>> Guessing method names is far
>> suboptimal to this simple, easy idiom.  As for the point Chris was
>> making as to making all types one, I actually agree there too,
>
> Oh dear. Chris was being sarcastic. I thought that, even if the sarcasm
> wasn't obvious, his "Ook. Ook!" at the end should have given it away:

Yes, I was aware of his sarcasm.  But I was actually wanting to agree
with the fundamental idea:  that one could reduce all data types to 1
atomic unit and 1 grouping construct, and like set theory in
mathematics, derive everything else.

>> it's
>> just that in order to do that, python would need a unified object
>> model and it doesn't have one yet.
>
> I'm not sure what you mean by "unified object model", but I'm pretty sure
> that Python has one. Everything is an object, with a single[1] hierarchy of
> classes.

Hopefully the elucidation above clears up some of that confusion.

Mark