Guido, Thank you for your generous comments. All of them. On 2019/11/18 15:33, Guido van Rossum wrote:
It won't be easy to add this to the stdlib.
Maybe there are other existing threads that considered a new recursive mapping object for stblib that someone can point me to?
One thing that bugs me in particular is that you can access key via '.attr' notation (the example shows t['a']['b']['c']['d'] as equivalent to t.a.b.c.d). This feels problematic: What should happen if the key happens to be the name of a method (e.g. .keys or .update)? The choices you have are either to mask the method or to mask the key. Neither solution seems ideal. JavaScript has this equivalence and it makes me very uncomfortable.
Well, let's see:
t.set_path('a.b.c.update', 'Hello') t.a.b.c.update <built-in method update of Thesaurus object at 0x7f78b99df8e0> t.a.b.c['update'] 'Hello'
Attribute aliasing has limitations the coder must understand. Thesaurus attempts to deal with them gracefully. When in doubt normal key names should always work (including keys with dots in them) and if they don't I have something to fix. With the focus on being a datatype primitive I consider anything more to be the job of higher level modules. (ThesaurusCfg being an example) The benefit of course is dramatically cleaner code for heavily nested objects and recursive string replacement compatibility. (f-string, printf, format, template) And with that said, if the only obstacle to a new recursive mapping object for stblib is attribute aliasing, then it can be removed. Dave
I'm not denying that Thesaurus[Cfg] looks useful. But, like Tal, I must stress that that's not enough to consider inclusion in the stdlib.
On Mon, Nov 18, 2019 at 4:25 PM Dave Cinege <dave@cinege.com <mailto:dave@cinege.com>> wrote:
Hello Tal,
Yes I understand that. I posted this here because it's been suggested by those less in the know that Thesaurus and ThesaurusCfg (or some of the the concepts contained in them) might have a place in the future mainline.
Remember that Thesaurus is a data type and ThesaurusCfg is a alternative to configparser. Additionally I could bring this full circle to something that integrates with or provides an alternative to argparse. (providing an integrated cfg file and command line argument solution which currently does not exist.)
I hope with this in mind this thread is considered on-topic and I'd highly value any feedback from the 'serious people' on this list if they should take a look.
Dave
On 2019/11/18 08:51, Tal Einat wrote: > Hi Dave, > > Thesaurus looks interesting and it is obvious that you've put a lot of > effort into it! > > This list is for the discussion of the development *of* Python itself, > however, rather than development *with* Python, so it's not an > appropriate place for such posts. > > I suggest you post this on python-list and/or python-announce, to get > this in front of a wider audience. > > - Tal Einat > > On Mon, Nov 18, 2019 at 7:17 AM Dave Cinege <dave@cinege.com <mailto:dave@cinege.com> > <mailto:dave@cinege.com <mailto:dave@cinege.com>>> wrote: > > If you are not aware: > > - Thesaurus is a mapping data type with recursive keypath map > and attribute aliasing. It is a subclass of dict() and is mostly > compatible as a general use dictionary replacement. > > - ThesaurusExtended is a subclass of Thesaurus providing additional > usability methods such as recursive key and value searching. > > - ThesaurusCfg is a subclass of ThesaurusExtended providing a nested > key configuration file parser and per key data coercion methods. > > The README.rsl will give a better idea: > https://git.cinege.com/thesaurus/ > > > After 7 years I might have reached the point of 'interesting' with > my Thesaurus and ThesaurusCfg modules. > > To anyone that is overly bored, I'd appreciate your terse review and > comments on how mundane and worthless they still actually are. :-) > > I'm primarily interested in suggestions to what I've done conceptually > here. While I'm not completely ashamed of the state of the Thesaurus > code, ThesaurusCfg is not far beyond the original few hours I > slapped it > together one day in frustration. > > After considering suggestions I intend to make changes towards a formal > release. > > Thanks in advance, > > Dave > _______________________________________________ > Python-Dev mailing list -- python-dev@python.org <mailto:python-dev@python.org> > <mailto:python-dev@python.org <mailto:python-dev@python.org>> > To unsubscribe send an email to python-dev-leave@python.org <mailto:python-dev-leave@python.org> > <mailto:python-dev-leave@python.org <mailto:python-dev-leave@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/CTXKJUTT... > Code of Conduct: http://python.org/psf/codeofconduct/ > _______________________________________________ Python-Dev mailing list -- python-dev@python.org <mailto:python-dev@python.org> To unsubscribe send an email to python-dev-leave@python.org <mailto:python-dev-leave@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/VXA7EZYV... Code of Conduct: http://python.org/psf/codeofconduct/
-- --Guido van Rossum (python.org/~guido <http://python.org/~guido>) /Pronouns: he/him //(why is my pronoun here?)/ <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c...>