I understand your perspective, but the fact is that this makes the code lengthier and adds an extra step to what I am already trying to do. Additionally, if I understand correctly, I could implement a built-in method as a function that takes in the key and uses a try-except block to get the value or return None, which is essentially Python's way of handling missing values (similar to get()).
I proposed this solution because Python is widely used by many people and organizations for web scraping and API integrations, where None values are often expected and need to be handled efficiently. I believe this could be a valuable addition, but please correct me if I'm wrong.
I think adding an extra method is the only reasonable solution anyways. Modifying `dict.get` even if not breaking any existing functionality, would result in decreased performance across the whole landscape of code that uses `get`, which doesn’t seem like a big cost, but from experience, dictionary methods do tend to become bottlenecks in highly-optimised python code (which is often the case given the obvious disadvantage of interpreted language).

So the only question here is whether to add an extra method in python core. Such as you did e.g. `get_if`, or leave it to the user. If left to the user, then maybe it is possible to solve several issues at the same time by providing elegant, optimised & flexible one-liners (see my other e-mail) to do such thing, leaving implementation details to the user.

You are concerned about `None`, maybe someone else is concerned about some other value that he wishes to treat as non-valid. Permutations are endless in value-space and depth.

Implementing and especially changing already existing functionality in core-python requires consideration of many perspectives, which I, myself, do not have enough, so this is just my opinion.

But from what I have gathered from experience analysing others' and my own suggestions in this group, the one you are proposing (at least taken at it’s face value) is too limiting, and potentially too invasive for too little benefit in relation to how close to `python’s metal` it is.


On 15 Jul 2023, at 20:57, Jothir Adithyan <adithyanjothir@gmail.com> wrote:

Dom Grigonis wrote:
This feels superfluous. Instead of creating new dict class I would propose either:
1. Not to have None values
 a) It is most likely possible to pre-delete all None values before you use the dict = {k: v for k, v in dict if v is not None}
 b) Not to create them in the first place (if it depends on you)
2. Or simply: (dict.get(‘k1’) or dict()).get(‘child_key')
On 10 Jul 2023, at 22:18, Jothir Adithyan adithyanjothir@gmail.com wrote:
Hi everyone,
I would like to briefly present my idea regarding the `get` function commonly used with dictionaries. When working with large amounts of JSON data, I often encounter code that doesn't feel very Pythonic to me.
Problem Statement:
The `get` function allows chaining of method calls, which is quite useful when working with dictionaries. It also has a convenient `default` parameter that returns a default value if the key is not found in the dictionary. This feature makes it safe and easy to use. However, problems arise when the dictionary contains the key we are accessing, but the corresponding value is `None`. In such cases, subsequent `get` calls fail because the `get` method belongs to objects of type `dict` and not `None`. To address this, I propose adding a new parameter to the `get` function or introducing a new function called `get_or` that swiftly handles this issue. This new parameter, called `arbitrary`, would accept an arbitrary value to be returned by subsequent `get` calls in case the retrieved value of the key is `None`.
Assumptions:
The problem statement is based on a few assumptions:

You prefer chaining `get` statements for cleaner code.
You expect at least some of the `get` methods to return `None`.
You want to avoid the hassle of using `try` and `except` for every `get` chain.

If you fall into the category of people who wish for a simpler way to work with dictionaries and handle large amounts of data, I hope you can empathise with this proposal.
I have made a simple implementation by modifying the `get` method, which is below this thread. I would appreciate your valuable input on this feature. Before diving into coding, I want to make sure this is not a bad idea waiting to reveal itself in the dark.
Thank you for taking the time to read this thread. Your feedback is greatly appreciated.
Best regards,  
Jothir Adithyan
**Runnable Version**  
https://replit.com/@Adithyan71/GetOr
**Code Samples.**
class PlayDict(dict):  
   def get_or(self, key, arbitrary=None, default=None):  
       if not self.__contains__(  
           key  
       ):  # case 1 the key does not exist hence the default value  
           return default  
       elif (  
           self[key] is None  
       ):  # case 2 key does exist but the value is None return the arb value  
           return arbitrary  
       return self[key]  # case 3 the key is present and the value is not None  


import contextlib  
parent_dict = PlayDict()  
parent_dict['k1'] = None  
parent_dict['k2'] = {"child_key": "val"} # Parent dict can contain nested dicts  

with contextlib.suppress(AttributeError):  
   result = parent_dict.get("k1", {}).get("child_key") # This will raise AttributeError  

result = parent_dict.get_or("k1", default={}, arbitrary={}).get("child_key") # This will work  

print(result)  


Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-leave@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/IELDCU...
Code of Conduct: http://python.org/psf/codeofconduct/



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