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/