from __future__ import runtime_default_kwargs
When from __future__ import runtime_default_kwargs Is run, def a(b=1, c=b+2, d=[]): pass behaves as (if the peephole optimizer didn’t exist) def a(b=None, c=None): if b is None: b = 1 if c is None: c = b + 2 if d is None: d = [] i.e. the keyword expression is evaluated at runtime. Perhaps a restriction on “literals only” can be made so people don’t abuse this.
On Mon, Mar 11, 2019 at 10:28 PM James Lu <jamtlu@gmail.com> wrote:
A future directive is appropriate only if the language is planned to be changed. Is that what you're actually asking for? If so, ask for that (and then the future directive becomes a transition tool). As an alternative, consider tagging the specific function, not the whole module (future directives always apply to the entire module). The best way to tag a function would probably be a decorator. ChrisA
Thank you, James, for your idea. For the benefit of those who may not know, please explain the problem you wish to solve. That way we could suggest, discuss and compare other solutions. -- Jonathan
Hi James, Some weeks ago, you started a discussion here about "Clearer Communication". Here's another suggestion to help: don't expect your readers to either guess, or infer from the code, what your proposal means. As the Zen of Python says: Explicit is better than implicit. Looking at your sample code, I'm guessing that you want support for late binding of function parameter defaults. Python uses early binding, see the FAQs: https://docs.python.org/3/faq/programming.html#why-are-default-values-shared... Am I correct? If not, can you please explain what it is that you are actually suggesting. Note that early binding is not a bug to be fixed, it is a design choice which is sometimes useful and sometimes not useful. Mutable defaults being shared is sometimes a good feature to have, and for immutable defaults, early binding is more efficient. I don't think that changing the behaviour will be acceptible, I know I would argue strongly in favour of keeping early binding. (If the language defaults to early binding, it is easy to implement late binding in the body of the function; but if the language uses late binding, it is difficult and annoying to get early binding when you want it. We should stick to the status quo.) But having a nice, clean way to get late binding semantics as an alternative might be acceptible, if we can agree on acceptible syntax and a mechanism. -- Steven
Steven D'Aprano wrote:
For me, the canonical guidelines for the use of this list are [1] http://python.org/psf/codeofconduct/ Summary: Open, Considerate, Respectful [2] https://mail.python.org/mailman/listinfo/python-ideas This list is to contain discussion of speculative language ideas for Python for possible inclusion into the language. If an idea gains traction it can then be discussed and honed to the point of becoming a solid proposal to put to python-dev as appropriate. [3] https://devguide.python.org/coredev/#responsibilities As a core developer, there are certain things that are expected of you. First and foremost, be a good person. This might sound melodramatic, but you are now a member of the Python project and thus represent the project and your fellow core developers whenever you discuss Python with anyone. We have a reputation for being a very nice group of people and we would like to keep it that way. Core developers responsibilities include following the PSF Code of Conduct. ASIDE The system puts the first two URLs at the foot of every email it sends out. It might help if it also added https://devguide.python.org/ I'll suggest that to the forum moderators. -- Jonathan
On 11/03/2019 12:17, Jonathan Fine wrote:
May I suggest that hijacking a thread to discuss something unrelated at length is neither considerate nor respectful?
That makes it sound like we're all core developers, which would be a considerable discouragement to discussion. I would expect that the core devs actually know this already, and reminding them at every turn is rather insulting. -- Rhodri James *-* Kynesim Ltd
Someone made a proposal whose purpose was not clear. A second person criticised the first person for this. A third person (me) referred to the public guidelines for the use of this list. A fourth person, in a new thread, accused the third person of hijacking the thread. The third person (me) responded, with the previous remarks. Silence, sometimes, is golden. Or at least better than the alternative. -- Jonatha
On Tue, Mar 12, 2019 at 2:30 AM Jonathan Fine <jfine2358@gmail.com> wrote:
TBH your link to the public guidelines was not quite a response to the second post, as the second post was talking about *content* and you were talking about *behaviour*. It's perfectly possible to remain entirely within the Code of Conduct, but still not provide enough context for the post; it's also entirely possible to make a post that has all sorts of useful information, but is caustic, rude, racist, sexist, or in any other way violates the CoC. The former is perfectly legitimate content, but will result in an on-topic response asking for more details; the latter might get you banned from the list. That said, though - I don't think Rhodri's response was really necessary here. Calling your post "unrelated" is stretching it a bit, and it wasn't an inconsiderate post, just not quite a direct response. *shrug* ChrisA
On 11/03/2019 15:37, Chris Angelico wrote:
Had Jonathan retitled his post to be clear he was not addressing the original issue (the first unclear post), I wouldn't have had an issue with it. However he didn't, and his post wasn't on the subject (or attempting to clarify the subject) of the the first post. In a post talking about respect and good conduct, that's quite a failing. In my opinion, obviously. -- Rhodri James *-* Kynesim Ltd
On Mon, Mar 11, 2019 at 10:28 PM James Lu <jamtlu@gmail.com> wrote:
A future directive is appropriate only if the language is planned to be changed. Is that what you're actually asking for? If so, ask for that (and then the future directive becomes a transition tool). As an alternative, consider tagging the specific function, not the whole module (future directives always apply to the entire module). The best way to tag a function would probably be a decorator. ChrisA
Thank you, James, for your idea. For the benefit of those who may not know, please explain the problem you wish to solve. That way we could suggest, discuss and compare other solutions. -- Jonathan
Hi James, Some weeks ago, you started a discussion here about "Clearer Communication". Here's another suggestion to help: don't expect your readers to either guess, or infer from the code, what your proposal means. As the Zen of Python says: Explicit is better than implicit. Looking at your sample code, I'm guessing that you want support for late binding of function parameter defaults. Python uses early binding, see the FAQs: https://docs.python.org/3/faq/programming.html#why-are-default-values-shared... Am I correct? If not, can you please explain what it is that you are actually suggesting. Note that early binding is not a bug to be fixed, it is a design choice which is sometimes useful and sometimes not useful. Mutable defaults being shared is sometimes a good feature to have, and for immutable defaults, early binding is more efficient. I don't think that changing the behaviour will be acceptible, I know I would argue strongly in favour of keeping early binding. (If the language defaults to early binding, it is easy to implement late binding in the body of the function; but if the language uses late binding, it is difficult and annoying to get early binding when you want it. We should stick to the status quo.) But having a nice, clean way to get late binding semantics as an alternative might be acceptible, if we can agree on acceptible syntax and a mechanism. -- Steven
Steven D'Aprano wrote:
For me, the canonical guidelines for the use of this list are [1] http://python.org/psf/codeofconduct/ Summary: Open, Considerate, Respectful [2] https://mail.python.org/mailman/listinfo/python-ideas This list is to contain discussion of speculative language ideas for Python for possible inclusion into the language. If an idea gains traction it can then be discussed and honed to the point of becoming a solid proposal to put to python-dev as appropriate. [3] https://devguide.python.org/coredev/#responsibilities As a core developer, there are certain things that are expected of you. First and foremost, be a good person. This might sound melodramatic, but you are now a member of the Python project and thus represent the project and your fellow core developers whenever you discuss Python with anyone. We have a reputation for being a very nice group of people and we would like to keep it that way. Core developers responsibilities include following the PSF Code of Conduct. ASIDE The system puts the first two URLs at the foot of every email it sends out. It might help if it also added https://devguide.python.org/ I'll suggest that to the forum moderators. -- Jonathan
On 11/03/2019 12:17, Jonathan Fine wrote:
May I suggest that hijacking a thread to discuss something unrelated at length is neither considerate nor respectful?
That makes it sound like we're all core developers, which would be a considerable discouragement to discussion. I would expect that the core devs actually know this already, and reminding them at every turn is rather insulting. -- Rhodri James *-* Kynesim Ltd
Someone made a proposal whose purpose was not clear. A second person criticised the first person for this. A third person (me) referred to the public guidelines for the use of this list. A fourth person, in a new thread, accused the third person of hijacking the thread. The third person (me) responded, with the previous remarks. Silence, sometimes, is golden. Or at least better than the alternative. -- Jonatha
On Tue, Mar 12, 2019 at 2:30 AM Jonathan Fine <jfine2358@gmail.com> wrote:
TBH your link to the public guidelines was not quite a response to the second post, as the second post was talking about *content* and you were talking about *behaviour*. It's perfectly possible to remain entirely within the Code of Conduct, but still not provide enough context for the post; it's also entirely possible to make a post that has all sorts of useful information, but is caustic, rude, racist, sexist, or in any other way violates the CoC. The former is perfectly legitimate content, but will result in an on-topic response asking for more details; the latter might get you banned from the list. That said, though - I don't think Rhodri's response was really necessary here. Calling your post "unrelated" is stretching it a bit, and it wasn't an inconsiderate post, just not quite a direct response. *shrug* ChrisA
On 11/03/2019 15:37, Chris Angelico wrote:
Had Jonathan retitled his post to be clear he was not addressing the original issue (the first unclear post), I wouldn't have had an issue with it. However he didn't, and his post wasn't on the subject (or attempting to clarify the subject) of the the first post. In a post talking about respect and good conduct, that's quite a failing. In my opinion, obviously. -- Rhodri James *-* Kynesim Ltd
participants (5)
-
Chris Angelico -
James Lu -
Jonathan Fine -
Rhodri James -
Steven D'Aprano