> 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 <adithyanjot...@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 adithyanjot...@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-le...@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
> <mailto:python-ideas@python.org>
> To unsubscribe send an email to python-ideas-le...@python.org
> <mailto:python-ideas-le...@python.org>
> https://mail.python.org/mailman3/lists/python-ideas.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/
>
> <https://mail.python.org/archives/list/python-ideas@python.org/message/LWOSXQSZKYO6KUKIZCA6ONUDKRKD4N7G/>
> Code of Conduct: http://python.org/psf/codeofconduct/
> <http://python.org/psf/codeofconduct/>
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@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/2PEZGXFAXMOIIEWAORJPACL2UAB6YGII/
Code of Conduct: http://python.org/psf/codeofconduct/
