[Python-ideas] [Python-Dev] matrix operations on dict :)

[Jim Jewett]

On Thu, Feb 9, 2012 at 7:11 PM, Mark Janssen <dreamingforward at gmail.com> wrote:
> On Wed, Feb 8, 2012 at 9:54 AM, julien tayon <julien at tayon.net> wrote:
>>
>> 2012/2/7 Mark Janssen <dreamingforward at gmail.com>:
>> > On Mon, Feb 6, 2012 at 6:12 PM, Steven
>> > D'Aprano <steve at pearwood.info> wrote:

>> > I have the problem looking for this solution!

>> > The application for this functionality is in coding a fractal graph (or
>> > "multigraph" in the literature).

I think that would be better represented using an object of some sort,
such as a MultiGraphNode and/or MultiGraphEdge, instead of
re-purposing dict.

> Okay, I guess I did not make myself very clear.  What I'm proposing probably
> will (eventually) require changes to the "object" model of Python

That means you're talking about Python 4, at a minimum, and you would
need to show how valuable it is by building a workaround version and
getting people to use that extensively in Python 3.

And frankly, you should probably do that anyhow; this feels to me like
a bad plan for language defaults, but it is still a valid use case --
and I don't think this sort of math exploration should (or will) wait
for Python 4; people will model it somehow in an existing language.

> The symbol that denotes a compound would be the colon
> (":") and associates a left hand side with right-hand side value,
> a NAME with a VALUE.   A dictionary would (then) be a SET
> of these. (Voila! things have already gotten simplified.)

That sounds like an association list.  I think you're dealing with
sufficiently abstract problems that you don't want to restrict your
keys to hashable things, and it is worth suffering a bit slower
performance in return.

> Eventually, I also think this will seque and integrate
> nicely into Mark Shannon's "shared-key dict" proposal (PEP 410).

I'm pretty sure he doesn't intend to change the semantics of dict at
all. He does want to make the implementation more efficient, at least
in terms of space; any semantic differences are considered either bugs
or costs worth paying for that efficiency.

> While in the abstract one might think to allow any arbitrary data-type for
> right-hand-side values, in PRACTICE, integers are sufficient.

By integers, do you really mean pointers or (possibly abstract)
references to other structures?  Because if you do, then ordinary
arithmetic isn't the right solution, but if you don't, then I don't
see them as sufficient.

> ... It makes sense to use ... a maximally abstract top-most level --
> this is simply an abstract grouping type (i.e. a collection).  I'm going to
> suggest a SET is the most abstract (i.e. sufficient) because it does
> not impose an order

I agree that it is the most abstract (at least of the well-known)
type, and that all the other types can be represented in terms of
sets.  The catch is that these representations may be massively
inefficient.  If you're doing mathematical exploration, that may be a
reasonable tradeoff, but Python also caters to other use cases.

> (Could one represent a python CLASS heirarchy more simply with this
> fractalset object somehow....?)

Depending on what you want to represent, probably.

But if you want to represent the ancestors of a given class for
efficient method and attribute access, then no; it is hard to beat an
array for efficiency of sequential access.

-jJ