Re: [Python-ideas] Backtick expression: similar to a shorter lambda syntax
On Wed, Jan 23, 2019 at 1:07 PM James Lu wrote: > Backtick expressions (now) use the same scoping and same binding rules as > other functions. > What do you mean by "now"?? There are no backtick expressions in Python anymore and they were never functions. > The only difference is that > class Class: > stacticmethod = `...` > staticmethod = lambda: ... > def instancemethod = `...` # an instancemethod that's called with self > passed in > def property = property(`...`) # an instancemethod that's called with > self passed in > You seem to be inventing new syntax as you go. And you haven't told us how the first two above differ. > > The only thing that I can think of is that you want `foo + ^bar` to be > another way of writing lambda bar: foo + bar with some under-specified > behavior > for evaluating foo and different under-specified behavior for evaluating > bar. > > That is what `lambda bar: foo + ^bar` means. > I have no idea what this means. You're giving syntax without semantics. The word "that" in your sentence is an unbound reference. > > A caret in a backtick expression indicates that the name after the caret > is a parameter. All names with the same name must have a caret before them. > Mandatory parameters can be passed in as keyword arguments or as positional > ones. > In a word, ick. So to find the parameters for a function, I need to scan through the entire text of the function looking for ^? And you think that's an improvement? You've given no explanation of how this is better and saving typing the word lambda isn't enough. All in all this sounds like "but these go to 11" justification and that really is insufficient. I'm -11. --- Bruce ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Potential PEP: with/except
I have a neutral feeling about the proposal but I’d like to suggest something We can extend the try/with to other blocks, as suggested. What could be done to prevent any ambiguity is : try with blabla as blabla2 : ... except: ... Which is equivalent of : try: with blabla as blabl2: ... except: Any other combination should be explicit, except if there’s a nice syntax but I didn’t find it. Extending to other blocks would give : try for ... in ...: ... except: ... But if we use the « else » here, what’s going on ? It’s a one line saver (which is useless) but having many indented blocks doesn’t produce readable code in my opinion. Saving one indented block while keeping things clear is a good thing in my opinion. As long as it stays clear (which is not the case in the for block). But adding this feature to the with block without using it for other blocks is a bit strange, imho. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Backtick expression: similar to a shorter lambda syntax
> > > The only thing that I can think of is that you want `foo + ^bar` to be > another way of writing lambda bar: foo + bar with some under-specified > behavior > for evaluating foo and different under-specified behavior for evaluating > bar. > > That is what `lambda bar: foo + ^bar` means. > Now you have a lambda inside a back tick expression?!? > > A caret in a backtick expression indicates that the name after the caret > is a parameter. All names with the same name must have a caret before them. > Mandatory parameters can be passed in as keyword arguments or as positional > ones. > So are all the ^ names positional parameters? And only them? And are they on the order they first appear in the expression? How about when there are parentheses, so the order evaluated my not be the same as the order written? Anyway, IIUC, this is a way to write a lambda with less typing, and harder to read. And fewer features— any way to do keyword (with default) parameters? “Explicit is bettter than implicit” So -1 from me. -CHB > > As for the under-specification, I've been working on an example > implementation I'll send soon for backtick expressions. > > I've also been doing the "look for use cases in stdlib" thing that > Johnathan and Steve mentioned. > > > On Wed, Jan 23, 2019 at 3:02 AM Bruce Leban wrote: > >> On Sun, Jan 20, 2019 at 6:43 PM James Lu wrote: >> >>> Backtick expressions work exactly like lambdas, except that they are >>> bound to the instance they are created in every time that class is used to >>> create one. To illustrate, ... >> >> >> First, if there is a useful procedure I am strongly against using >> backticks because (1) it's been used in the past with an entirely different >> meaning and (2) it looks ugly and is not visually suggestive at all of what >> it does, especially not the subtle difference between other function >> definitions. >> >> Second, I don't understand exactly what this difference or why it would >> be useful. It would help for you to give examples comparing lambda and this >> variation. >> >> Third, you mention using ^ in "explicit" expressions to refer to >> parameters of the "created function" and I do not know what function you >> are referring to or what the exact semantics of this are. Again, a >> comparison of two expressions with and without that ^ would help. An >> expression is not a function and not all expressions are written inside >> functions. (And as to the specific proposed syntax, there already is the >> ^ xor operator and the most expected meaning of ^value is ~value. just >> as the unary + and - operators corresponds to the binary operators. >> >> The only thing that I can think of is that you want `foo + ^bar` to be >> another way of writing lambda bar: foo + bar with some under-specified >> behavior >> for evaluating foo and different under-specified behavior for evaluating >> bar. >> >> Finally, if there is some other useful semantics for references inside a >> function definition, then I would think the best way to do that is to >> implement that, not add a new function difference. For example, >> >> lambda foo: foo + $bar >> >> def sample(foo): >> >> return foo + $foo >> >> >> where I'm arbitrarily using $ to represent the new semantics whatever >> they are (no point in bikeshedding syntax when semantics are yet to be >> defined). >> >> --- Bruce >> > ___ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Backtick expression: similar to a shorter lambda syntax
Backtick expressions (now) use the same scoping and same binding rules as other functions. The only difference is that class Class: stacticmethod = `...` staticmethod = lambda: ... def instancemethod = `...` # an instancemethod that's called with self passed in def property = property(`...`) # an instancemethod that's called with self passed in > The only thing that I can think of is that you want `foo + ^bar` to be another way of writing lambda bar: foo + bar with some under-specified behavior for evaluating foo and different under-specified behavior for evaluating bar . That is what `lambda bar: foo + ^bar` means. A caret in a backtick expression indicates that the name after the caret is a parameter. All names with the same name must have a caret before them. Mandatory parameters can be passed in as keyword arguments or as positional ones. As for the under-specification, I've been working on an example implementation I'll send soon for backtick expressions. I've also been doing the "look for use cases in stdlib" thing that Johnathan and Steve mentioned. On Wed, Jan 23, 2019 at 3:02 AM Bruce Leban wrote: > On Sun, Jan 20, 2019 at 6:43 PM James Lu wrote: > >> Backtick expressions work exactly like lambdas, except that they are >> bound to the instance they are created in every time that class is used to >> create one. To illustrate, ... > > > First, if there is a useful procedure I am strongly against using > backticks because (1) it's been used in the past with an entirely different > meaning and (2) it looks ugly and is not visually suggestive at all of what > it does, especially not the subtle difference between other function > definitions. > > Second, I don't understand exactly what this difference or why it would be > useful. It would help for you to give examples comparing lambda and this > variation. > > Third, you mention using ^ in "explicit" expressions to refer to > parameters of the "created function" and I do not know what function you > are referring to or what the exact semantics of this are. Again, a > comparison of two expressions with and without that ^ would help. An > expression is not a function and not all expressions are written inside > functions. (And as to the specific proposed syntax, there already is the ^ > xor operator and the most expected meaning of ^value is ~value. just as > the unary + and - operators corresponds to the binary operators. > > The only thing that I can think of is that you want `foo + ^bar` to be > another way of writing lambda bar: foo + bar with some under-specified > behavior > for evaluating foo and different under-specified behavior for evaluating > bar. > > Finally, if there is some other useful semantics for references inside a > function definition, then I would think the best way to do that is to > implement that, not add a new function difference. For example, > > lambda foo: foo + $bar > > def sample(foo): > > return foo + $foo > > > where I'm arbitrarily using $ to represent the new semantics whatever they > are (no point in bikeshedding syntax when semantics are yet to be defined). > > --- Bruce > ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Backtick expression: similar to a shorter lambda syntax
On Sun, Jan 20, 2019 at 6:43 PM James Lu wrote: > Backtick expressions work exactly like lambdas, except that they are bound > to the instance they are created in every time that class is used to create > one. To illustrate, ... First, if there is a useful procedure I am strongly against using backticks because (1) it's been used in the past with an entirely different meaning and (2) it looks ugly and is not visually suggestive at all of what it does, especially not the subtle difference between other function definitions. Second, I don't understand exactly what this difference or why it would be useful. It would help for you to give examples comparing lambda and this variation. Third, you mention using ^ in "explicit" expressions to refer to parameters of the "created function" and I do not know what function you are referring to or what the exact semantics of this are. Again, a comparison of two expressions with and without that ^ would help. An expression is not a function and not all expressions are written inside functions. (And as to the specific proposed syntax, there already is the ^ xor operator and the most expected meaning of ^value is ~value. just as the unary + and - operators corresponds to the binary operators. The only thing that I can think of is that you want `foo + ^bar` to be another way of writing lambda bar: foo + bar with some under-specified behavior for evaluating foo and different under-specified behavior for evaluating bar . Finally, if there is some other useful semantics for references inside a function definition, then I would think the best way to do that is to implement that, not add a new function difference. For example, lambda foo: foo + $bar def sample(foo): return foo + $foo where I'm arbitrarily using $ to represent the new semantics whatever they are (no point in bikeshedding syntax when semantics are yet to be defined). --- Bruce ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
