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 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 wrote:
>>>
>>> On Sun, 23 Jul 2023 at 14:08, Dom Grigonis 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
