Brendan Barnwell writes: > The ability to write something in the function signature that we > can already write in the body, and that quite naturally belongs in > the body, because it is executed when the function is called, not > when it is defined.
I'm basically in sympathy with your conclusion, but I don't think it's useful to prejudice the argument by saying it *naturally belongs* in the body. Some languages quite naturally support thunks/blocks (Ruby) or even go so far as to equate code to data (Lisp), and execute that code in lieu of what appear to be variable references. But maybe it's *Pythonic* to necessarily place the source code in the body? I can't say that. > > I *really* don't like the idea that some types of object will be > > executed instead of being used, just because they have a flag > > set. >From a syntactic point of view, that's how Ruby blocks work. Closer to home, that's how properties work. And in the end, *all* objects are accessed by executing code. This is a distinction without a difference, except in our heads. I wouldn't want to be asked to explain the dividing line between objects that were "just used" and objects that were "produced by code that was executed instead of being just used". > I *really* don't like the idea that some types of argument will be > inlined into the function body instead of being stored as first-class > values like other `__defaults__`, just because there happens to be this > one extra character next to the equals sign in the function signature. > That strikes me as the sort of thing that should be incredibly > scary. Properties have *no* visible syntax if they're imported from a module. Properties are extremely useful, and we all use them all the time without noticing or caring. I see no reason in principle why the same kind of feature wouldn't be useful and just as invisible and just as "natural" for local or global variables -- or callable parameters, as long as properly restricted. Chris's proposal is nothing if not restricted! :-) My issues with Chris's proposal are described elsewhere, but I don't really see a problem in principle. _______________________________________________ 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/GSMTALVKO5SMP7JJFBQDG2CD352GRYDF/ Code of Conduct: http://python.org/psf/codeofconduct/
