[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!
On Wed, Dec 01, 2021 at 07:47:49AM -, Jeremiah Vivian wrote: > > 2) Independently: Is the syntactic distinction between "=" and "=>" a > > cognitive burden? > No, it isn't much of a cognitive burden. You say that now, but if you read function definitions that looked like this: def process(func:List->int=>xs=>expression)->int: ... would you still agree? -- Steve ___ 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/ICCQ6VJ7MOXGC7MTMSEISXJVIEXGI2M3/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!
Answering questions: > 1) If this feature existed in Python 3.11 exactly as described, would > you use it? I would definitely use it. > 2) Independently: Is the syntactic distinction between "=" and "=>" a > cognitive burden? No, it isn't much of a cognitive burden. > 3) If "yes" to question 1, would you use it for any/all of (a) mutable > defaults, (b) referencing things that might have changed, (c) > referencing other arguments, (d) something else? Probably all options other than (d). > 5) Do you know how to compile CPython from source, and would you be > willing to try this out? Please? :) Yes I do know how to, and I'm gonna try it out soon enough. I'll reply to this comment once I've done so. ___ 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/62QKLLLO6ISAL3OXASRJEXV73TC23PHZ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!
> On 1 Dec 2021, at 10:16 AM, Chris Angelico wrote: > > I've just updated PEP 671 https://www.python.org/dev/peps/pep-0671/ > with some additional information about the reference implementation, > and some clarifications elsewhere. > > *PEP 671: Syntax for late-bound function argument defaults* > > Questions, for you all: > > 1) If this feature existed in Python 3.11 exactly as described, would > you use it? Yes I will use it. > > 2) Independently: Is the syntactic distinction between "=" and "=>" a > cognitive burden? No, because it would look like a lambda (if the new lambda syntax were approved), indicating this will be evaluated each time the function is run. > > (It's absolutely valid to say "yes" and "yes", and feel free to say > which of those pulls is the stronger one.) > > 3) If "yes" to question 1, would you use it for any/all of (a) mutable > defaults, (b) referencing things that might have changed, (c) > referencing other arguments, (d) something else? I will definitely use it for default mutable collections like list, set, dictionary etc. I will also use it to reference things that might have changed. For example, when making callbacks to GUI push buttons, I find myself at the start of the function/callback to be fetching the values from other widgets so we can do something with them. Now those values can be directly passed as late-bound defaults from their respective widgets (e.g., def callback(self, text1 => self.line_edit.text()): …). > > 4) If "no" to question 1, is there some other spelling or other small > change that WOULD mean you would use it? (Some examples in the PEP.) > NA > 5) Do you know how to compile CPython from source, and would you be > willing to try this out? Please? :) I haven’t done it from source. I might try to learn how to do it in the next weekend and give it a try. > > I'd love to hear, also, from anyone's friends/family who know a bit of > Python but haven't been involved in this discussion. If late-bound > defaults "just make sense" to people, that would be highly > informative. I will show this to some of my coworkers who are python experts and I will report back. > > Any and all comments welcomed. I mean, this is python-ideas after > all... bikeshedding is what we do best! > > The reference implementation currently has some test failures, which > I'm looking into. I'm probably going to make this my personal default > Python interpreter for a while, to see how things go. > > ChrisA > ___ > 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/UVOQEK7IRFSCBOH734T5GFJOEJXFCR6A/ > Code of Conduct: http://python.org/psf/codeofconduct/ ___ 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/EBF27XGKOZPVR2WE46ZF4EWFPY4KU4W2/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Enhancing iterator objects with map, filter, reduce methods
On Wed, Dec 1, 2021 at 6:14 PM Abdulla Al Kathiri wrote: > > Thanks for the clarification. Yeah I agree it will look ugly if we use it not > as a first argument many times in a row but what if there is one or two > functions in the middle that they are not playing along and don’t have > teamwork ethics, meaning they put the parameter we are interested in as a > second or third parameter or as a keyword only parameter and it will make > really good sense to chain those calls? I believe an option should be given > to the programmer to do this, but it shouldn’t be encouraged to do it a lot. > _ could be used as a placeholder or anything really. > 1 -> add(2) -> pow(3, _) equivalent to 1 -> add(_, 2) -> pow(3, _). > _ is where your output goes into. _ as a first argument can be omitted. > It's always possible to make a proposal more general by making it less clean. Is the loss of generality from "must pipe into the first argument" (or "must pipe into last argument", pick whichever one you want to go with) actually as restrictive as you think? People don't tend to write add() and pow() like this, because we have operators. With real-world code, how commonly is this actually going to be a problem? ChrisA ___ 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/YAWWKU3BRXNVJAJIPPKNOOHXWLSUGQU2/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Enhancing iterator objects with map, filter, reduce methods
Thanks for the clarification. Yeah I agree it will look ugly if we use it not as a first argument many times in a row but what if there is one or two functions in the middle that they are not playing along and don’t have teamwork ethics, meaning they put the parameter we are interested in as a second or third parameter or as a keyword only parameter and it will make really good sense to chain those calls? I believe an option should be given to the programmer to do this, but it shouldn’t be encouraged to do it a lot. _ could be used as a placeholder or anything really. 1 -> add(2) -> pow(3, _) equivalent to 1 -> add(_, 2) -> pow(3, _). _ is where your output goes into. _ as a first argument can be omitted. > On 1 Dec 2021, at 2:14 AM, Chris Angelico wrote: > > Otherwise you end up with a much more complicated proposal with far > less beauty to it. ___ 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/B5ATJZ3KYQGWJI3SFCKSIYTYJXU7P2C7/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] PEP 671 (late-bound arg defaults), next round of discussion!
I've just updated PEP 671 https://www.python.org/dev/peps/pep-0671/ with some additional information about the reference implementation, and some clarifications elsewhere. *PEP 671: Syntax for late-bound function argument defaults* Questions, for you all: 1) If this feature existed in Python 3.11 exactly as described, would you use it? 2) Independently: Is the syntactic distinction between "=" and "=>" a cognitive burden? (It's absolutely valid to say "yes" and "yes", and feel free to say which of those pulls is the stronger one.) 3) If "yes" to question 1, would you use it for any/all of (a) mutable defaults, (b) referencing things that might have changed, (c) referencing other arguments, (d) something else? 4) If "no" to question 1, is there some other spelling or other small change that WOULD mean you would use it? (Some examples in the PEP.) 5) Do you know how to compile CPython from source, and would you be willing to try this out? Please? :) I'd love to hear, also, from anyone's friends/family who know a bit of Python but haven't been involved in this discussion. If late-bound defaults "just make sense" to people, that would be highly informative. Any and all comments welcomed. I mean, this is python-ideas after all... bikeshedding is what we do best! The reference implementation currently has some test failures, which I'm looking into. I'm probably going to make this my personal default Python interpreter for a while, to see how things go. ChrisA ___ 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/UVOQEK7IRFSCBOH734T5GFJOEJXFCR6A/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Enhancing iterator objects with map, filter, reduce methods
On Tue, Nov 30, 2021 at 2:17 PM Chris Angelico wrote: > > I don’t like the fact this is used only as a first parameter. What if > you want the preceding output to go as a second parameter? > > > in real world situations, > that's easily the most common form needed. > Exactly -- the goal here (to me) is to have an easy and intuitive way to chain operations -- not to have a new way to call functions in the general case. - CHB -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython ___ 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/SE5IRCSMLIIQRQDR54QRECROO52T33GR/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Enhancing iterator objects with map, filter, reduce methods
On Wed, Dec 1, 2021 at 9:09 AM Abdulla Al Kathiri wrote: > > How about using the typing return arrow -> to indicate the return of the > preceding goes as a first parameter in the function: > 1 -> add(2) That's a possibility. The same arrow then means "this function produces that value" in a definition, and "this value then goes into that function" in an expression. > I don’t like the fact this is used only as a first parameter. What if you > want the preceding output to go as a second parameter? > Abdulla > Then write it the classic way. The vast majority of the time, you'll want it to be the first parameter. It's like how dot chaining of methods only works for the return value becoming the 'self' parameter - yes, that's incredibly restrictive, but in real world situations, that's easily the most common form needed. Otherwise you end up with a much more complicated proposal with far less beauty to it. ChrisA ___ 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/UYM2YKWFTEXJW27CIM4KZRO5FIEYIW4O/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Enhancing iterator objects with map, filter, reduce methods
How about using the typing return arrow -> to indicate the return of the preceding goes as a first parameter in the function: 1 -> add(2) I don’t like the fact this is used only as a first parameter. What if you want the preceding output to go as a second parameter? Abdulla Sent from my iPhone > On 29 Nov 2021, at 9:55 PM, Chris Angelico wrote: > > 1 |> add(2) > > is exactly equivalent to this: > > add(1, 2) > > then neither the iterator nor the consumer needs to be aware of the > new protocol. > > I don't like that syntax though, and this will live or die on a good syntax. ___ 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/P4R4NSNVWGLADQCA3HDVAR26LQP2WJ6D/ Code of Conduct: http://python.org/psf/codeofconduct/
