It’s 2 options: a) It is a special constant - the only one with such property. Then it would be used solely for this purpose. I don’t think you can prevent someone from using it for something else. But I don’t think this case of misusage is a big exception to the way things are. As this would be only such constant, it then should be used only for this purpose. Standard sentinels would be used for everything else and None could be left for cross-language cases, such as json null value and similar. But as of now, it is not possible to do what I am referring to with either sentinels or None. The standard is to override default such as None with itself, witch means ‘NotProvided', but it actually is. Then that value is checked within the function’s body and if it is ’NotProvided’, then default is set. I appreciate that None value is singleton and technically it is the same one, but special value is useful if one was to have a more complex default argument and wanted to enforce it from outside, while retaining ability to specify it as well. It is simply cleaner than what is being done now. And without this PEP, I don’t think there would be a big case for it, but with this PEP, it seems more compelling as it seems to encourage more complex defaults. So no, I don’t think it is likely that another special value would be needed. All the other “special values” can be handled with sentinels. If this case is not special enough, then (b) could work. b) Property of a callable to specify an object which is treated in such manner as special constant in (a) or a decorator which emulates such behaviour. This might be even better approach as long as it is performant and reliable. Decorator could be a good option, but that depends on how performant it is. If it’s the same as e.g. `getcallargs` then, at least to me, not a very attractive option. But I think there might be case for special value as well. But again, only my opinion, I don’t really have an issue with the way things currently are with function arguments. Just answered questionnaire regarding this PEP and this is my opinion. —————— I am more excited about deferred-eval, which if was implemented with neat syntax, would improve things for me in many different places in one go and from what I have seen would benefit many different areas and provide more neat solutions for several cases that came to this group & fairly elegant (although maybe not as pythonic) ones for several PEPs that were deferred or rejected. DG
On 23 Jul 2023, at 14:40, Richard Damon <Richard@Damon-Family.org> wrote:
I think the question is, how is that fundamentally different than the value "None". Once you create this "special value", some function will decide to make it have a meaning as a passed in value, and then need a DIFFERENT "special value" as a default.
On 7/23/23 1:13 AM, Dom Grigonis wrote:
Or maybe you are not listening to what I am saying.
It would only take effect for arguments, which have default value.
So. dict().__setitem__(key, NotGiven) type(NotGiven) Exception(NotGiven) getattr(NotGiven, name)
Ok, maybe there are some crucial functions, which have argument defaults. But again, there is another solution then, implement efficient decorator in standard library, maybe as part of sentinels, maybe as part of your PEP, maybe separately.
I never said that it isn’t hard to write low-level python code. I will do that when the time is right for me. And I am not claiming that it is possible. If you read my language, all of my doubts are clearly expressed. You just seem to read everything as black and white even when it is not so.
However, such statements are in no way valid arguments in such discussion. If my idea is not optimal, not necessary, no-one needs it or any other valid responses, why it is not a good one - I can accept it. But commenting that “it makes no sense” without properly explaining to me why after giving it some thought - it’s not fair.
Also, if you looked at things from a bit more positive perspective, maybe you could come up with some nice new ways how it could be done. Maybe not exactly what I am proposing, but some alternative, which would make it work. Most likely something much better than I am proposing.
After all, I am trying to see how your PEP can be improved, because if it could be used in all cases, where None can be, then at least to me, it would be a no-brainer to use it instead and to adapt it as best practice.
DG
On 23 Jul 2023, at 07:35, Chris Angelico <rosuav@gmail.com> wrote:
On Sun, 23 Jul 2023 at 14:08, Dom Grigonis <dom.grigonis@gmail.com> wrote:
IT IS AN OBJECT. Never said otherwise. One that you can't do any of the operations I described. There is no way to use it as an object.
`inspect.getcallargs` can seemingly be modified for such behaviour. I just wrote a decorator, which does what I proposed using `inspect` module for a chosen sentinel value. The issue is that it would be a bottleneck if used on any callable, which is continuously used. `inspect.getcallargs`, `signature`, `getfullargspec` are very expensive.
If that can be done, theoretically it should be able to be done at lower level as well. After all, behaviour of it should be modelled after what is happening at the function call.
Since you clearly are not listening to the discussion, I will leave you with one final recommendation: Write some code. Don't just claim that it's possible; write actual code that makes it happen. You will discover exactly how hard it is. If I am wrong, you will be able to PROVE that I am wrong, instead of merely claiming it.
ChrisA
-- Richard Damon
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org <mailto:python-ideas@python.org> To unsubscribe send an email to python-ideas-leave@python.org <mailto:python-ideas-leave@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/JEIZYD... <https://mail.python.org/archives/list/python-ideas@python.org/message/JEIZYDJGK3RDW77FNZX5TZUP47JJT4XW/> Code of Conduct: http://python.org/psf/codeofconduct/ <http://python.org/psf/codeofconduct/>