Well, as a user of JSON in Python I *would* be surprised by it, since the actual JSON notation uses dicts, and most Python code I've seen that access raw JSON data directly uses dict notation. Where you see dot notation is if the raw JSON dict is verified and converted to a regular object (usually with the help of some schema library), but there dict notation is questionable.
On Tue, Apr 14, 2020 at 8:50 PM Kyle Stanley email@example.com wrote:
Guido van Rossum wrote:
I've seen this pattern a lot at a past employer, and despite the obvious
convenience I've come to see it as an anti-pattern: for people expecting Python semantics it's quite surprising to read code that writes foo.bar and then reads back foo['bar'].
Would it be significantly less surprising if it were to be exclusively allowed for the JSON module rather than anything that accepts custom dicts? To me, that seems like the most useful and intuitive location for the dot notation, and it would keep the Python semantics intact everywhere else. I think it's fairly unlikely that most users of JSON would be surprised by it, but I can see that it could be surprising elsewhere.
On Tue, Apr 14, 2020 at 11:33 PM Guido van Rossum firstname.lastname@example.org wrote:
On Tue, Apr 14, 2020 at 8:06 PM Raymond Hettinger < email@example.com> wrote:
SimpleNamespace() is really good at giving attribute style-access. I would like to make that functionality available to the JSON module (or just about anything else that accepts a custom dict) by adding the magic methods for mappings so that this works:
catalog = json.load(f, object_hook=SimpleNamespace)
print(catalog['clothing']['mens']['shoes']['extra_wide']['quantity']) # currently possible with dict() print(catalog.clothing.mens.shoes.extra_wide.quantity]) # proposed with SimpleNamespace() print(catalog.clothing.boys['3t'].tops.quantity # would also be supported
I've already seen something like this in production; however, people are having to write custom subclasses to do it. This is kind of bummer because the custom subclasses are a pain to write, are non-standard, and are generally somewhat slow. I would like to see a high-quality version this made more broadly available.
The core idea is keep the simple attribute access but make it easier to load data programmatically:
>>> ns = SimpleNamespace(roses='red', violets='blue') >>> thing = input() sugar >>> quality = input() sweet >>> setattr(ns, thing, quality) # current >>> ns['sugar'] = 'sweet' # proposed
If the PEP 584 __ior__ method were supported, updating a SimpleNamespace would be much cleaner:
ns |= some_dict
I posted an issue on the tracker: https://bugs.python.org/issue40284 . There was a suggestion to create a different type for this, but I don't see the point in substantially duplicating everything SimpleNamespace already does just so we can add some supporting dunder methods. Please add more commentary so we can figure-out the best way to offer this powerful functionality.
Python-Dev mailing list -- firstname.lastname@example.org To unsubscribe send an email to email@example.com https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://firstname.lastname@example.org/message/JOMND56P... Code of Conduct: http://python.org/psf/codeofconduct/
-- --Guido van Rossum (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-change-the-world/ _______________________________________________ Python-Dev mailing list -- email@example.com To unsubscribe send an email to firstname.lastname@example.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://email@example.com/message/EJ6XJW6S... Code of Conduct: http://python.org/psf/codeofconduct/