On 5/13/2021 7:48 AM, Petr Viktorin wrote:
On 13. 05. 21 11:45, Antoine Pitrou wrote:
Le 13/05/2021 à 11:40, Irit Katriel a écrit :
On Thu, May 13, 2021 at 10:28 AM Antoine Pitrou <anto...@python.org
<mailto:anto...@python.org>> wrote:
I agree that <optional> is a reasonable spelling.
I initially suggested <optional>, but now I'm not sure because it
doesn't indicate what happens when you don't provide it (as in, what
is the default value). So now I'm with <derived> or <implicit>.
"<derived>" makes think of a derived class, and leaves me confused.
"<implicit>" is a bit better, but doesn't clearly say what the
default value is, either. So in all cases I have to read the
docstring in addition to the function signature.
Is <default> the term you're looking for?
In the dataclasses docs
https://docs.python.org/3/library/dataclasses.html I document the
module-level sentinel MISSING, then I document the function as:
dataclasses.field(*, default=MISSING, default_factory=MISSING,
repr=True, hash=None, init=True, compare=True, metadata=None)
And I explain what MISSING means.
The help looks like:
field(*, default=<dataclasses._MISSING_TYPE object at 0x6fffffe46610>,
default_factory=<dataclasses._MISSING_TYPE object at 0x6fffffe46610>,
init=True, repr=True, hash=None, compare=True, metadata=None)
None of this is particularly awesome, but no one has complained about it
yet.
I think it's important to state an actual value for the default value,
instead of just using something like "<default>". Unless you know the
actual default value, you can't write a wrapper.
Say I wanted to write something that calls dataclasses.field, but
doesn't allow the user to specify repr, hash, init, compare, and
metadata. I could write it as:
def myfield_func(*, default=MISSING, default_factory=MISSING):
...
If the real default values for "default" and "default_factory" weren't
documented, there wouldn't be any easy way to write this.
I do think a python-wide standard for this would be helpful, but I don't
see how to change existing code given backward compatibility constraints.
Eric
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/ICKR43MC35QNBEWZLJ6NW2RG2M4O27FU/
Code of Conduct: http://python.org/psf/codeofconduct/
