On Tue., 19 Nov. 2019, 7:32 am Dave Cinege, <d...@cinege.com> wrote:

> Tal,
>
> On 2019/11/18 10:59, Tal Einat wrote:
> >
> > These days, thanks to pip and PyPI, anyone can publish libraries and it
> > is easy for developers to find and use them if they like. There is no
> > longer a need to add things to the stdlib just to make them widely
> > available.
>
> Fair enough, only that you possibly neglected to remember the benefits
> to my ego if I get something accepted into mainline. :-D
>
> Framing this a little more specifically:
>
> Aside from my original Thesaurus release in Dec 2012, there have been
> many many attempts at extended/recursive dictionary objects. The use
> case for such a thing is well established. (JSON maybe enough to mention)
>
> I would argue that a new standardized mapping datatype, possibly (some
> form of) Thesaurus, could be warranted in stdlib.
>
> At this stage I consider Thesaurus 'serious' and 'interesting' because:
>
>         - I've been using some version of it for 7 years in my own
>         production code; many of the concepts in it are mature.
>
>         - It's tightly wrapped around and highly compatible with dict.
>
>         - I've paid close attention to performance
>
>         - The recent extended features for tree searches and the slicing
>         you can do with 'keypaths' (my own term) appears novel.
>


I think there's one potential avenue for making the case that a new
JSON-centric data type would be worth including: framing it as an
alternative to the None-aware operator proposal in PEP 505.

It may still not be successful, but ad hoc data manipulation has been the
most compelling use case presented for that PEP so far, and a standard
library addition would be a less intrusive change than a syntax update.

So if you wanted to pursue this idea further, my suggestions would be:

* post a thread on python-ideas seeking advice on building a credible case
for improving arbitrarily nested data container support in the standard
library, as we currently make it easy to build them, but not so easy to
destructure them later. (Replies to my suggestions below would also be
better directed to python-ideas)
* review PEP 505 and consider how the library might help with the use cases
mentioned there
* review other APIs like https://glom.readthedocs.io/en/latest/ and
consider the trade-offs between a data manipulation library that can work
with existing libraries that produce plain dictionaries and one that
requires a new data structure
* in the same vein, review whether it might be possible to use a "dict
wrapper" approach over a "dict subclass" approach (many potential users
will balk at a data copy operation, but would be amenable to a ChainMap
style wrapper)
* consider your options for tackling the naming conflict with
https://libraries.io/pypi/thesaurus (I must admit, "nested data structure
manipulation" is not what springs to mind when I hear "thesaurus". I'm far
more likely to think of synonyms, antonyms, and natural language processing)

Cheers,
Nick.




>
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/VAZOMJXUQCC6E57U656JQPNPVVZBXQ2Z/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to