Steven D'Aprano <steve+pyt...@pearwood.info> added the comment: Hi Richard,
> Also, using _asdict() seems strange as an exposed API, since it's an > underscore method and users hence might not be inclined to use it. I don't consider this a strong argument. Named tuple in general has to use a naming convention for public methods that cannot clash with field names, hence the single underscore, but your concrete named tuple class can offer any methods you like since you know which field names are used and which are not. Just add a public method "asdict" or any name you prefer, and delegate to the single underscore method. > It would be nicer to have my type just return this appropriate dict when > invoking dict(BasicStats(…)). As we speak there is a discussion on Python-Ideas about this. https://mail.python.org/archives/list/python-id...@python.org/thread/2HMRGJ672NDZJZ5PVLMNVW6KP7OHMQDI/#UYDIPMY2HXGL4OLEEFXBTZ2T4CK6TSVU Your input would be appreciated. > This would require me to override the __iter__() method to yield key / value > tuples for the dict. The dict constructor does not require that. See discussion on the thread above. If you search the Python-Ideas archives, I am sure you will find past proposals for a `__json__` protocol. If I recall correctly, there was some concern about opening the flood-gates for dunder protocols (will this be followed with demands for __yaml__, __xml__, __cson__, __toml__, etc?) but perhaps the time is right to revisit this idea. ---------- nosy: +steven.daprano _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue42765> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
