> Right. That is a very real difference, which is why there is a very
> real difference between early-bound and late-bound defaults. But both
> are argument defaults.
I don't 100% agree with that.
I mean, here's another way to come at this. Suppose we have this under
the proposal (using some random syntax picked at random):
def foo(a=1, b="two", c@=len(b), d@=a+c):
You keep saying that c and d "are argument default" just like a and b.
So can you tell me what the argument default for each of those arguments?
I'm trying to figure out if this is a (english language) semantics issue or a real conceptual issue.
Yes, we don't know what the default "value" (by either the general english definition or the python definition), but we do know that the default will be set to the result of the depression when evaluated in the context of the function, which is very clear to me, at least.
The default for argument a is an integer. The default for argument b
is a string. Can you tell me, in comparable terms, what the defaults
for arguments c and d are?
yes: the default for c is the result of evaluating `len(b)`, and default to d is the result of evaluating `a+c`
in contrast, what are defaults in this case?
def foo(a=1, b="two", c=None, d=None):
obviously, they are None -- but how useful is that? How about:
def foo(a=1, b="two", c=None, d=None):
"""
...
if None, c is computed as the length of the value of b, and d is computed as that length plus a
"""
if c is None:
c = len(b)
if d is None:
d = a + c
Is that really somehow more clear? And you'd better hope that the docstring matches the code!
I'm having a really hard time seeing how this PEP would make anything less clear or confusing.
-CHB
Currently, every argument default is a first-class value. As I
understand it, your proposal breaks that assumption, and now argument
defaults can be some kind of "construct" that is not a first class
value, not any kind of object, just some sort of internal entity that no
one can see or manipulate in any way, it just gets automatically
evaluated later.
I really don't like that. One of the things I like about Python is the
"everything is an object" approach under which most of the things that
programmers work with, apart from a very few base syntactic constructs,
are objects. Many previous expansions to the language, like decorators,
context managers, the iteration protocol, etc., worked by building on
this object model. But this proposal seems to diverge quite markedly
from that.
If the "late-bound default" is not an object of some kind just like the
early-bound ones are, then I can't agree that both "are argument defaults".
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a trail."
--author unknown
_______________________________________________
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/Q7OGRKD7CRMNOB6NFF4KZTOC7ZJ3GNSO/
Code of Conduct: http://python.org/psf/codeofconduct/
Christopher Barker, PhD (Chris)
Python Language Consulting
- Teaching
- Scientific Software Development
- Desktop GUI and Web Development
- wxPython, numpy, scipy, Cython