x )= f as shorthand for x=f(x)

Title says it all. Got used to += et al. My mind often expects augmented assignment syntax to exist uniformly for whatever transform. If I am not mistaken, python syntax doesn't permit augmented assignment operators to sit between parens so that )= wouldn't risk confusing quick machine- or eye-scans to match parens. Cheers, BB

On 11/9/07, Boris Borcic <bborcic@gmail.com> wrote:
Agreed. Whether it is worth the costs is a different question. I'm not sure it is, and I'm sure it isn't with this particular syntax.
There are plenty of tools (and plenty of eyes, including mine) that don't use the full ruleset. A parenthesis inside a string has no syntactic meaning. In practice, it still messes up some syntax colorings. (1, 2, """3, 4) """, 5) I don't think there is any reason to encourage the use of unmatched parentheses for any purpose. -jJ

On Nov 9, 2007 12:39 PM, Boris Borcic <bborcic@gmail.com> wrote:
Bizarre syntax. Close-parens should close something. Also, al it saves is 1 char. -- http://www.advogato.org/person/eopadoan/ Bookmarks: http://del.icio.us/edcrypt

Eduardo O. Padoan wrote:
Typical motivating usecase is like for other augmented assignment Just as a[<complex_expression>] += n saves both the typing and the computation of an <complex_expression> over a[<complex_expression>] += a[<complex_expression>] + n and an temporary variable assignment over temp = <complex_expression> a[temp]=a[temp]+n so would a[<complex_expression>] )= f save over a[<complex_expression>] = f(a[<complex_expression>]) etc. More than "just 1 char", anyway. BB

Fredrik Johansson wrote:
Ah, indeed I almost itemized my remark about current python syntax with a (1), to add a "(2) makes closing parens before an augmented assignment (part of) a superfluous construct". I'd make it a syntax error, to answer your question. I'd be interested in examples out of the "wild". Cheers, BB
Fredrik

Fredrik Johansson wrote:
Ah, and what about (x,y)=f - more likely to already exist in the wild, isn't it ? Well, if ')=' was an augmented assignment operator, I'd say (x,y)=f should parse as a destructuring assignment as it already does while (x)=f should become a syntax error. I admit it's debatable, of course. I think a case could be made in terms of lookahead tokens in favor of that solution (all other things equal). Cheers, BB

On Nov 9, 2007 7:39 AM, Boris Borcic <bborcic@gmail.com> wrote:
Title says it all. Got used to += et al. My mind often expects augmented assignment syntax to exist uniformly for whatever transform.
I'm not really a Guido channeler, but I'd guess this has about a 0% chance of ever making it into Python. Function calls in Python are indicated by () following the function name. Your proposal puts the parentheses (or one of them) *before* the function name. Breaking the consistency here seems like an *extremely* bad idea. STeVe -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy

On Nov 9, 2007 7:39 AM, Boris Borcic <bborcic@gmail.com> wrote:
Title says it all. Got used to += et al. My mind often expects augmented assignment syntax to exist uniformly for whatever transform.
And the "most inane proposal in python-ideas" award goes to... ;-)

George Sakkis wrote:
[Is the name of "sarkkasm" (sarkkism ?) the one obvious way to make your remark escape appropriate qualification as...] But please be precise, are you saying (1) that it is inane to suggest that <code> x=f(x) </code> has enough in common with say <code> x=x%n </code> that special syntax paralleling the latter's shorthand <code> x%=n </code> could or would make sense for the former ? (2) that the proposed choice of special syntax is "most inane". In case you mean only (2), please back your claim with some facts, by proposing "less inane" special syntax. Cheers, BB

Steven Bethard wrote:
I contend that x )= f captures some perfume of the invariant you mention, although I admit there is no comparably simple formula for the relaxed invariant (if indeed it exists). Note that current python syntax requires any ) to follow a ( that it balances, so that's not one but two rules broken in coordination. (-1)*(-1)==(+1)-ly yours, Boris Borcic -- What happened to our chief humorist and python zen master, BTW ?

Boris, give it up. That syntax is never going to fly. If you have to ask why, you're just not cut out to be a language designer. On Nov 9, 2007 10:33 AM, Boris Borcic <bborcic@gmail.com> wrote:
-- --Guido van Rossum (home page: http://www.python.org/~guido/)

Guido van Rossum wrote:
Boris, give it up. That syntax is never going to fly. If you have to ask why, you're just not cut out to be a language designer.
Guido, I did not intend to pose as a language designer. I just bumped for the nth time on a corner of the language and came up with the closest approximation to a solution I could invent, expecting the (actual and potential) language designers of the forum to find a better solution if any can be dreamed up. Maybe I was mistaken about this newsgroup's purpose, but imho playing the devil's advocate is a perfectly honorable manner to push ideas (as opposed to designs). I must admit I wasn't expecting the discussion to rely so quickly on involving my character. In conclusion, I guess I'm warranted to take this to mean "we can dream up no appropriate syntax". Regards, Boris --- PS,FYI : a notation borne from letting parens live independent lives, and indeed could fly http://en.wikipedia.org/wiki/Bra-ket_notation

Some people wrote:
Function calls in Python are indicated by () following the function name. I contend that "x )= f" captures some perfume of the invariant you mention,
But not enough of it. A syntax of "x ()= f" would seem to have more chance of being accepted. But I would still give it no more than 0.1% chance, based on the potential confusion between it and "x() = f"...
In conclusion, I guess I'm warranted to take this to mean "we can dream up no appropriate syntax".
If I were you, I would take it more as "that suggestion is too Functional (or perhaps just too confusing) for Python." (If you're looking for a language that has filed all the corners off, might I suggest Scheme. No, seriously, I'm not making a parenthesis joke here.) Later, Blake.

Boris, I'm posting this publicly because you aren't the first to feel this way, so I think an answer should be archived. On 11/9/07, Boris Borcic <bborcic@gmail.com> wrote:
I did not intend to pose as a language designer.
Suggesting a change in python is acting (in a small way) as a language designer.
came up with the closest approximation to a solution I could invent,
Which is fine. The catch is that no one -- not even Guido -- gets everything right the first time. There is a natural desire to just tweak the proposal to work, or even to explain why things are already OK. For a good proposal, you need to do this to make it great. Unfortunately, that turns out to be running in circles for the proposals that -- like most proposals -- turn out to be dead ends. So you need to be willing to step back and figure out (1) How important the problem really is. (2) How expensive the proposed solutions really are.
I must admit I wasn't expecting the discussion to rely so quickly on involving my character.
I don't think that was anyone's intent. I suspect you were thinking of lines like:
That syntax is never going to fly. If you have to ask why, you're just not cut out to be a language designer.
These don't mean you're bad person; they just mean that you don't yet know how to answer those two questions the same way Guido (for example) would.
In conclusion, I guess I'm warranted to take this to mean "we can dream up no appropriate syntax".
Yes, but there is also a question about whether to do it at all. Remember that x = f(x) is one step of reduce -- and reduce is something Guido wants to take back out of the language because, in practice, it is too confusing. (a) Is this operation frequent enough to be worth a syntactic shortcut? Would it actually make the code easier to read? (b) Is the sort of code that uses this operation something that should be encouraged? Or is making it hard a *good* thing that steers people towards other idioms?
PS,FYI : a notation borne from letting parens live independent lives, and indeed could fly http://en.wikipedia.org/wiki/Bra-ket_notation
The question isn't whether it is possible, but whether it is worth the cost. The costs are different for physics and for a generic programming language -- and different still for Python in particular. -jJ

Jim Jewett wrote:
Ah, thanks for caring, Jim. And for your nice explanations. Stephen J. Turnbull wrote: [...]
It's like a judge silencing a advocate by saying "It's no, and if you can't plead the other side's view now that it's over, this means you don't have what it takes to be judge". Now the competent advocate is deferential to the judge and in general won't dream he could replace the judge any more than he would ignore any judge's simple demand for silence. But he will nevertheless recognize that the test the judge proposes is one by which to recognize a competent advocate foremost, and a competent judge only subsidiarily if ever. IOW, deciding given pros and cons isn't the same as listing them. And if courts tend to distribute the role of listing the pros, that of listing the cons, and that of deciding, to three distinct persons or parties, it's not without good reasons, imo. And... I've a "good" enough personal history of driving myself into undecidable dilemmas, thanks. The above is what I was first tempted to reply in short to Guido, but felt it was rather OT, so I settled on a shortcut. 'nough said. [...]
I-always-wanted-to-be-a-language-designer-too-ly y'rs,
But-I-never-really-did-ly y'rs, Boris

Boris Borcic writes:
I must admit I wasn't expecting the discussion to rely so quickly on involving my character.
Some people have natural talent for a particular kind of design, some don't. If one doesn't, it's no big deal, s/he still can contribute, even to design---but coming up with original ideas is likely to waste her/his time and that of others. (I don't say it's impossible to develop it as a skill, but it would take real work.) Why not take Guido's comment literally, "*if* you don't have it," and think about the "litmus test" he described? (Ie, think about why this proposal is unattractive.) Of course, there is an implication that you *don't* have it, but it will be better all around if you ignore that implication, and leave it an open question as long as you want to contribute in this way.
In conclusion, I guess I'm warranted to take this to mean "we can dream up no appropriate syntax".
I wouldn't say "impossible". However, the senior developers who have spoken up clearly think that your proposal (a) is not an improvement over x = f(x) in most use cases (and IMO often would be worse, because x += y expresses accumulation of y, while x = y expresses replacement) and (b) seems to have very few, if any, appropriate use cases. So "why bother?" is the message.
PS,FYI : a notation borne from letting parens live independent lives, and indeed could fly http://en.wikipedia.org/wiki/Bra-ket_notation
As I understand it, the bra-ket notation arose in physics because both the bra part and the ket part make sense as operators, but only in the lefthand role for the bra, and righthand role for the ket. So they don't really live independent lives, any more than the dx and the dy do in conventional calculus. However, in your syntax you do (c) lose the kind of implied symmetry that the bra-ket and infinitesimal notations have. You could "fix" that by using the notation "apply-and-assign" x ()= f, but that syntax already has a meaning in python, and runs even more forcefully into STeVe's criticism that parens are a postfix operator, not infix. Note that I myself can come up with criticisms like (a), (b), and (c) but to the best of my knowledge I've never invented any useful syntax.<wink> I-always-wanted-to-be-a-language-designer-too-ly y'rs,

"Boris Borcic" <bborcic@gmail.com> wrote in message news:fh1rhm$ui$1@ger.gmane.org... | | Title says it all. Got used to += et al. My mind often expects augmented | assignment syntax to exist uniformly for whatever transform. I the analogy can be improved. x += y # abbreviates x = x + y # which could have been defined to have been written x = +(x,y) # and which usually *is* equivalent to x = type(x).__add__(x,y) Hence by analogy, I would rewrite x = f(x,y) # as x f= y # ;-) Making the obvious generalization to n params, and specializing to one, gives x f= tjr

Terry Reedy schrieb:
Hah, I have the solution! x λ= f unicode-ly yours, Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.

Georg Brandl wrote:
Georg has even written a Python enhancement proposals about the topic: http://www.python.org/dev/peps/pep-3117/ It should be hard to get the idea into it ... *just kidding* Christian

On 11/9/07, Boris Borcic <bborcic@gmail.com> wrote:
Agreed. Whether it is worth the costs is a different question. I'm not sure it is, and I'm sure it isn't with this particular syntax.
There are plenty of tools (and plenty of eyes, including mine) that don't use the full ruleset. A parenthesis inside a string has no syntactic meaning. In practice, it still messes up some syntax colorings. (1, 2, """3, 4) """, 5) I don't think there is any reason to encourage the use of unmatched parentheses for any purpose. -jJ

On Nov 9, 2007 12:39 PM, Boris Borcic <bborcic@gmail.com> wrote:
Bizarre syntax. Close-parens should close something. Also, al it saves is 1 char. -- http://www.advogato.org/person/eopadoan/ Bookmarks: http://del.icio.us/edcrypt

Eduardo O. Padoan wrote:
Typical motivating usecase is like for other augmented assignment Just as a[<complex_expression>] += n saves both the typing and the computation of an <complex_expression> over a[<complex_expression>] += a[<complex_expression>] + n and an temporary variable assignment over temp = <complex_expression> a[temp]=a[temp]+n so would a[<complex_expression>] )= f save over a[<complex_expression>] = f(a[<complex_expression>]) etc. More than "just 1 char", anyway. BB

Fredrik Johansson wrote:
Ah, indeed I almost itemized my remark about current python syntax with a (1), to add a "(2) makes closing parens before an augmented assignment (part of) a superfluous construct". I'd make it a syntax error, to answer your question. I'd be interested in examples out of the "wild". Cheers, BB
Fredrik

Fredrik Johansson wrote:
Ah, and what about (x,y)=f - more likely to already exist in the wild, isn't it ? Well, if ')=' was an augmented assignment operator, I'd say (x,y)=f should parse as a destructuring assignment as it already does while (x)=f should become a syntax error. I admit it's debatable, of course. I think a case could be made in terms of lookahead tokens in favor of that solution (all other things equal). Cheers, BB

On Nov 9, 2007 7:39 AM, Boris Borcic <bborcic@gmail.com> wrote:
Title says it all. Got used to += et al. My mind often expects augmented assignment syntax to exist uniformly for whatever transform.
I'm not really a Guido channeler, but I'd guess this has about a 0% chance of ever making it into Python. Function calls in Python are indicated by () following the function name. Your proposal puts the parentheses (or one of them) *before* the function name. Breaking the consistency here seems like an *extremely* bad idea. STeVe -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy

On Nov 9, 2007 7:39 AM, Boris Borcic <bborcic@gmail.com> wrote:
Title says it all. Got used to += et al. My mind often expects augmented assignment syntax to exist uniformly for whatever transform.
And the "most inane proposal in python-ideas" award goes to... ;-)

George Sakkis wrote:
[Is the name of "sarkkasm" (sarkkism ?) the one obvious way to make your remark escape appropriate qualification as...] But please be precise, are you saying (1) that it is inane to suggest that <code> x=f(x) </code> has enough in common with say <code> x=x%n </code> that special syntax paralleling the latter's shorthand <code> x%=n </code> could or would make sense for the former ? (2) that the proposed choice of special syntax is "most inane". In case you mean only (2), please back your claim with some facts, by proposing "less inane" special syntax. Cheers, BB

Steven Bethard wrote:
I contend that x )= f captures some perfume of the invariant you mention, although I admit there is no comparably simple formula for the relaxed invariant (if indeed it exists). Note that current python syntax requires any ) to follow a ( that it balances, so that's not one but two rules broken in coordination. (-1)*(-1)==(+1)-ly yours, Boris Borcic -- What happened to our chief humorist and python zen master, BTW ?

Boris, give it up. That syntax is never going to fly. If you have to ask why, you're just not cut out to be a language designer. On Nov 9, 2007 10:33 AM, Boris Borcic <bborcic@gmail.com> wrote:
-- --Guido van Rossum (home page: http://www.python.org/~guido/)

Guido van Rossum wrote:
Boris, give it up. That syntax is never going to fly. If you have to ask why, you're just not cut out to be a language designer.
Guido, I did not intend to pose as a language designer. I just bumped for the nth time on a corner of the language and came up with the closest approximation to a solution I could invent, expecting the (actual and potential) language designers of the forum to find a better solution if any can be dreamed up. Maybe I was mistaken about this newsgroup's purpose, but imho playing the devil's advocate is a perfectly honorable manner to push ideas (as opposed to designs). I must admit I wasn't expecting the discussion to rely so quickly on involving my character. In conclusion, I guess I'm warranted to take this to mean "we can dream up no appropriate syntax". Regards, Boris --- PS,FYI : a notation borne from letting parens live independent lives, and indeed could fly http://en.wikipedia.org/wiki/Bra-ket_notation

Some people wrote:
Function calls in Python are indicated by () following the function name. I contend that "x )= f" captures some perfume of the invariant you mention,
But not enough of it. A syntax of "x ()= f" would seem to have more chance of being accepted. But I would still give it no more than 0.1% chance, based on the potential confusion between it and "x() = f"...
In conclusion, I guess I'm warranted to take this to mean "we can dream up no appropriate syntax".
If I were you, I would take it more as "that suggestion is too Functional (or perhaps just too confusing) for Python." (If you're looking for a language that has filed all the corners off, might I suggest Scheme. No, seriously, I'm not making a parenthesis joke here.) Later, Blake.

Boris, I'm posting this publicly because you aren't the first to feel this way, so I think an answer should be archived. On 11/9/07, Boris Borcic <bborcic@gmail.com> wrote:
I did not intend to pose as a language designer.
Suggesting a change in python is acting (in a small way) as a language designer.
came up with the closest approximation to a solution I could invent,
Which is fine. The catch is that no one -- not even Guido -- gets everything right the first time. There is a natural desire to just tweak the proposal to work, or even to explain why things are already OK. For a good proposal, you need to do this to make it great. Unfortunately, that turns out to be running in circles for the proposals that -- like most proposals -- turn out to be dead ends. So you need to be willing to step back and figure out (1) How important the problem really is. (2) How expensive the proposed solutions really are.
I must admit I wasn't expecting the discussion to rely so quickly on involving my character.
I don't think that was anyone's intent. I suspect you were thinking of lines like:
That syntax is never going to fly. If you have to ask why, you're just not cut out to be a language designer.
These don't mean you're bad person; they just mean that you don't yet know how to answer those two questions the same way Guido (for example) would.
In conclusion, I guess I'm warranted to take this to mean "we can dream up no appropriate syntax".
Yes, but there is also a question about whether to do it at all. Remember that x = f(x) is one step of reduce -- and reduce is something Guido wants to take back out of the language because, in practice, it is too confusing. (a) Is this operation frequent enough to be worth a syntactic shortcut? Would it actually make the code easier to read? (b) Is the sort of code that uses this operation something that should be encouraged? Or is making it hard a *good* thing that steers people towards other idioms?
PS,FYI : a notation borne from letting parens live independent lives, and indeed could fly http://en.wikipedia.org/wiki/Bra-ket_notation
The question isn't whether it is possible, but whether it is worth the cost. The costs are different for physics and for a generic programming language -- and different still for Python in particular. -jJ

Jim Jewett wrote:
Ah, thanks for caring, Jim. And for your nice explanations. Stephen J. Turnbull wrote: [...]
It's like a judge silencing a advocate by saying "It's no, and if you can't plead the other side's view now that it's over, this means you don't have what it takes to be judge". Now the competent advocate is deferential to the judge and in general won't dream he could replace the judge any more than he would ignore any judge's simple demand for silence. But he will nevertheless recognize that the test the judge proposes is one by which to recognize a competent advocate foremost, and a competent judge only subsidiarily if ever. IOW, deciding given pros and cons isn't the same as listing them. And if courts tend to distribute the role of listing the pros, that of listing the cons, and that of deciding, to three distinct persons or parties, it's not without good reasons, imo. And... I've a "good" enough personal history of driving myself into undecidable dilemmas, thanks. The above is what I was first tempted to reply in short to Guido, but felt it was rather OT, so I settled on a shortcut. 'nough said. [...]
I-always-wanted-to-be-a-language-designer-too-ly y'rs,
But-I-never-really-did-ly y'rs, Boris

Boris Borcic writes:
I must admit I wasn't expecting the discussion to rely so quickly on involving my character.
Some people have natural talent for a particular kind of design, some don't. If one doesn't, it's no big deal, s/he still can contribute, even to design---but coming up with original ideas is likely to waste her/his time and that of others. (I don't say it's impossible to develop it as a skill, but it would take real work.) Why not take Guido's comment literally, "*if* you don't have it," and think about the "litmus test" he described? (Ie, think about why this proposal is unattractive.) Of course, there is an implication that you *don't* have it, but it will be better all around if you ignore that implication, and leave it an open question as long as you want to contribute in this way.
In conclusion, I guess I'm warranted to take this to mean "we can dream up no appropriate syntax".
I wouldn't say "impossible". However, the senior developers who have spoken up clearly think that your proposal (a) is not an improvement over x = f(x) in most use cases (and IMO often would be worse, because x += y expresses accumulation of y, while x = y expresses replacement) and (b) seems to have very few, if any, appropriate use cases. So "why bother?" is the message.
PS,FYI : a notation borne from letting parens live independent lives, and indeed could fly http://en.wikipedia.org/wiki/Bra-ket_notation
As I understand it, the bra-ket notation arose in physics because both the bra part and the ket part make sense as operators, but only in the lefthand role for the bra, and righthand role for the ket. So they don't really live independent lives, any more than the dx and the dy do in conventional calculus. However, in your syntax you do (c) lose the kind of implied symmetry that the bra-ket and infinitesimal notations have. You could "fix" that by using the notation "apply-and-assign" x ()= f, but that syntax already has a meaning in python, and runs even more forcefully into STeVe's criticism that parens are a postfix operator, not infix. Note that I myself can come up with criticisms like (a), (b), and (c) but to the best of my knowledge I've never invented any useful syntax.<wink> I-always-wanted-to-be-a-language-designer-too-ly y'rs,

"Boris Borcic" <bborcic@gmail.com> wrote in message news:fh1rhm$ui$1@ger.gmane.org... | | Title says it all. Got used to += et al. My mind often expects augmented | assignment syntax to exist uniformly for whatever transform. I the analogy can be improved. x += y # abbreviates x = x + y # which could have been defined to have been written x = +(x,y) # and which usually *is* equivalent to x = type(x).__add__(x,y) Hence by analogy, I would rewrite x = f(x,y) # as x f= y # ;-) Making the obvious generalization to n params, and specializing to one, gives x f= tjr

Terry Reedy schrieb:
Hah, I have the solution! x λ= f unicode-ly yours, Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.

Georg Brandl wrote:
Georg has even written a Python enhancement proposals about the topic: http://www.python.org/dev/peps/pep-3117/ It should be hard to get the idea into it ... *just kidding* Christian
participants (14)
-
Adam Atlas
-
Blake Winton
-
Boris Borcic
-
Christian Heimes
-
Eduardo O. Padoan
-
Fredrik Johansson
-
Georg Brandl
-
George Sakkis
-
Guido van Rossum
-
Jim Jewett
-
Luke Stebbing
-
Stephen J. Turnbull
-
Steven Bethard
-
Terry Reedy