[Python-ideas] PEP 505 vs matrix multiplication

Paul Moore p.f.moore at gmail.com
Fri Dec 1 09:16:36 EST 2017


On 1 December 2017 at 13:40, Nick Coghlan <ncoghlan at gmail.com> wrote:
> I genuinely don't think these kinds of operators are all that useful
> outside the specific domain of working with semi-structured
> hierarchical data stored in graph databases and document stores like
> MongoDB, ElasticSearch, and PostgreSQL JSONB columns, or else piping
> data between such stores and JSON consuming clients.

In that case, surely there are 3rd party libraries that help with
extracting such data from raw objects? Or if not, how seriously has
anyone looked at developing one? With the ability to create
specialised getattr and getitem behaviour, is it really so difficult
to produce a class that allows users to extract hierarchical data? I
know it probably couldn't do as good a job as if there were dedicated
syntax, but as a basis for a proposal that said "current best practice
(using module XXX) looks like this, but would be improved with the
following language support" it would help to ground the discussion in
real use cases. In the context of comparisons with matrix
multiplication, PEP 465 put a lot of time into explaining how all the
ways of approaching the problem short of a language change had been
tried and found wanting. Maybe PEP 505 should be held to a similar
standard?

At the moment, 99% of the discussion seems rooted in generalised "it
would help a lot of code" with readability arguments based on
artificial examples, and that's not really helping move the discussion
forward.

To be clear, I understand the problem of reading semi-structured data.
I've hit it myself and been frustrated by it. But my reaction was "why
am I not able to find a library that does this?", and when I couldn't
find such a library, my assumption was that people in general don't
find the current behaviour sufficiently frustrating to do anything
about it. And I was in the same situation - it annoys me, but not
enough to write a helper module (and certainly not enough that I'm
crying out for a language change). So I do appreciate the need, I just
don't think "language change" should be the first thing that's
suggested.

Paul

PS Some of the above may have been covered in the PEPs and previous
discussions. I haven't reread them - but any serious reboot of the
discussion should probably start with a summary of where we're up to.


More information about the Python-ideas mailing list