Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #88184 > unrolled thread

Re: Proposal for new minor syntax

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Proposal for new minor syntax Ian Kelly <ian.g.kelly@gmail.com> - 2015-03-27 14:48 -0600
    Re: Proposal for new minor syntax BartC <bc@freeuk.com> - 2015-03-27 23:08 +0000
      Re: Proposal for new minor syntax Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-03-28 20:53 +1100
        Re: Proposal for new minor syntax Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-03-28 21:43 +1100
          Re: Proposal for new minor syntax Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-04-09 09:32 +0200
        Re: Proposal for new minor syntax BartC <bc@freeuk.com> - 2015-03-28 13:38 +0000
          Re: Proposal for new minor syntax Mario Figueiredo <marfig@gmail.com> - 2015-03-28 16:05 +0100
            Re: Proposal for new minor syntax Ian Kelly <ian.g.kelly@gmail.com> - 2015-03-28 22:15 -0600
              Re: Proposal for new minor syntax Rustom Mody <rustompmody@gmail.com> - 2015-03-28 21:50 -0700
    Re: Proposal for new minor syntax Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-03-28 21:01 +1100

#88184 — Re: Proposal for new minor syntax

On Fri, Mar 27, 2015 at 2:24 PM, Jamie Willis
<jw14896.2014@my.bristol.ac.uk> wrote:
> I would like to propose a new piece of syntax for the python language; .=
>
> In short, the operator is form of syntactic sugar, for instance consider the
> following code:
>
> hello = "hello world              "
> hello = hello.strip()
>
> This could be written as:
>
> hello = "hello world              "
> hello .= strip()
>
> In this slightly contrived example, the programmer saved (a small amount of)
> time when writing the code. With code with longer variable names, or lots of
> similar statements all in a row, this helps to keep code more concise.
>
> The operator would be constricted to one method or field on the right-hand
> side, which must belong to the object on the left hand side.

Do you mean that this would not be legal?

hello .= strip().upper().encode('utf-8')

Is there a reason you want to disallow that?

> Another example could be when using Linked Lists, instead of writing
> something like:
>
> loop_node = loop_node.next
>
> you could write:
>
> loop_node .= next

I realize this is just an example, but does anybody actually use
linked lists in Python outside of class assignments? It seems hard to
justify performance-wise since list is written in C, and if you need
to beat it, then you probably shouldn't be doing so in Python.

> Does this idea have any chance of acceptance if submitted as a PEP? What are
> the potential concerns I could consider with the syntax?

On the plus side it doesn't add any new keywords or conflict with any
existing syntax.

On the minus side it seems marginal in utility to me, as all it does
is save a bit of typing. The +=, etc. operators are backed by special
methods named __iadd__ etc. which allows the class author to provide
for the operation to be performed in-place, or to change the meaning
entirely use the operator as part of a DSL. This proposal doesn't have
any room that I can see for that sort of benefit.

[toc] | [next] | [standalone]

#88187

On 27/03/2015 20:48, Ian Kelly wrote:
> On Fri, Mar 27, 2015 at 2:24 PM, Jamie Willis
> <jw14896.2014@my.bristol.ac.uk> wrote:
>> I would like to propose a new piece of syntax for the python language; .=
>>
>> In short, the operator is form of syntactic sugar, for instance consider the
>> following code:
>>
>> hello = "hello world              "
>> hello = hello.strip()
>>
>> This could be written as:
>>
>> hello = "hello world              "
>> hello .= strip()
>>
>> In this slightly contrived example, the programmer saved (a small amount of)
>> time when writing the code. With code with longer variable names, or lots of
>> similar statements all in a row, this helps to keep code more concise.
>>
>> The operator would be constricted to one method or field on the right-hand
>> side, which must belong to the object on the left hand side.

>> Another example could be when using Linked Lists, instead of writing
>> something like:
>>
>> loop_node = loop_node.next
>>
>> you could write:
>>
>> loop_node .= next

An alternate syntax might be:

  hello = .string()
  loop_node =. next

With flexible white space either side of "." unless it is important that 
".=" or "=." is a single token.

I'm assuming that an isolated "." is not a valid starter symbol for 
anything else, other than a floating point constant such as hello =.3

> On the minus side it seems marginal in utility to me, as all it does
> is save a bit of typing. The +=, etc. operators are backed by special
> methods named __iadd__ etc. which allows the class author to provide
> for the operation to be performed in-place, or to change the meaning
> entirely use the operator as part of a DSL. This proposal doesn't have
> any room that I can see for that sort of benefit.

It needn't require that sort of support. It does just save typing in the 
same way that A += B does, and makes it a little clearer what is being 
expressed. Except that with A = .B, A will be evaluated twice.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#88216

On Sat, 28 Mar 2015 10:08 am, BartC wrote:

> An alternate syntax might be:
> 
>   hello = .string()
>   loop_node =. next

Why propose that?

Every other augmented assignment has the operator on the left hand side of
the equals. Greater-than, less-than, and not-equal all have the symbol on
the left hand side of the equals:

+= -= *= **= /= //= %= |= ^= &= <= >= != =.

All together now, let's sing: "One of these things is not like the other..."

[That song is from Sesame Street, for anyone who doesn't get the reference.]

It doesn't even solve the "grit on Tim's monitor" test, it just moves the
whitespace from one side to the other:

hello .= strip()
hello =. strip()

Moving the dot to the other side just makes it an arbitrary change for
people to get confused by.


> With flexible white space either side of "." unless it is important that
> ".=" or "=." is a single token.

py> x = 2
py> x + = 1
  File "<stdin>", line 1
    x + = 1
        ^
SyntaxError: invalid syntax


I think that being able to write:

x + = 1

adds complexity for no benefit. If we don't allow spaces between + = we
shouldn't allow them between . and = in this proposal.


> I'm assuming that an isolated "." is not a valid starter symbol for
> anything else, other than a floating point constant such as hello =.3
> 
>> On the minus side it seems marginal in utility to me, as all it does
>> is save a bit of typing. The +=, etc. operators are backed by special
>> methods named __iadd__ etc. which allows the class author to provide
>> for the operation to be performed in-place, or to change the meaning
>> entirely use the operator as part of a DSL. This proposal doesn't have
>> any room that I can see for that sort of benefit.
> 
> It needn't require that sort of support. It does just save typing in the
> same way that A += B does, and makes it a little clearer what is being
> expressed. Except that with A = .B, A will be evaluated twice.

It saves typing. It might even allow a micro-optimization in the generated
bytecode (see below). But I don't think it's clearer -- the opposite,
really, I think it's a bit unclear.

You can't be any clearer than the explicit:

greeting = greeting.strip()

This tells you explicitly what's being evaluated on the right hand side, and
explicitly what it's being bound to.

greeting .= strip()

requires you to learn yet another special piece of syntax, after which you
can fill in the implicit attribute lookup:

greeting .= strip()  # greeting.strip()

Personally, I'm not a huge fan of augmented assignment += etc. There is no
doubt that it has the advantage of saving typing, but it leads to more
complexity:

(1) `x += y` *is not* semantically equivalent to `x = x + y`

(2) augmented assignment involving tuples can be awkward:

t = ([1, 2, 3], None, "spam")
t[0] += [4]


The problem isn't that the second line raises an exception, but that the
second line raises an exception and yet the addition succeeded.

So I am fairly dubious about extending a mixed blessing like augmented
assignment even further.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#88220

On Sat, 28 Mar 2015 08:53 pm, Steven D'Aprano wrote:


> It saves typing. It might even allow a micro-optimization in the generated
> bytecode (see below). 

Oops, I forgot to include the "see below" bit.

Comparing 

a = a.spam()

a .= spam()


the Python compiler could perhaps optimize the second form and avoid needing
two references to "a" (once for the attribute lookup, once for the
binding). That's not very exciting when it comes to a simple expression
like the above, but consider:

a[b][c].d.e[f].g = a[b][c].d.e[f].g.spam()


*If* that could be optimized, and I'm not certain it can be, that would be
an argument in favour of the proposal.

Still, I'm not entirely convinced that augmented assignments += *= etc are a
good idea or entirely Pythonic, and I'm dubious about pretending that . is
an operator, so I think that overall the proposal would need more
justification than merely "save a bit of typing" and "allow a
micro-optimization".


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#88697

On 03/28/2015 11:43 AM, Steven D'Aprano wrote:
> On Sat, 28 Mar 2015 08:53 pm, Steven D'Aprano wrote:
>
>
>> It saves typing. It might even allow a micro-optimization in the generated
>> bytecode (see below). 
> Oops, I forgot to include the "see below" bit.
>
> Comparing 
>
> a = a.spam()
>
> a .= spam()
>
>
> the Python compiler could perhaps optimize the second form and avoid needing
> two references to "a" (once for the attribute lookup, once for the
> binding). That's not very exciting when it comes to a simple expression
> like the above, but consider:
>
> a[b][c].d.e[f].g = a[b][c].d.e[f].g.spam()
>
>
> *If* that could be optimized, and I'm not certain it can be, that would be
> an argument in favour of the proposal.

I don't understand why you should doubt this. The optimisation is just
the sames as with augmented operators.

tmp = a[b][c].d.e[f]
tmp.g = tmp.g.spam() 

[toc] | [prev] | [next] | [standalone]

#88225

On 28/03/2015 09:53, Steven D'Aprano wrote:
> On Sat, 28 Mar 2015 10:08 am, BartC wrote:
>
>> An alternate syntax might be:
>>
>>    hello = .string()

That should have been .strip()


>>    loop_node =. next
>
> Why propose that?
>
> Every other augmented assignment has the operator on the left hand side of
> the equals. Greater-than, less-than, and not-equal all have the symbol on
> the left hand side of the equals:
>
> += -= *= **= /= //= %= |= ^= &= <= >= != =.

 > ... and I'm dubious about pretending that . is an operator

I see where you're coming from now. You're thinking that it is "." that 
is the operator, but I'm looking at "strip()" as the operator that is 
being applied.

I see the "." as just a bit of necessary syntax that introduces this 
style of operator as a /unary/ operation, not a binary operation like 
all those examples.

Maybe that's just the way Python does it. However, take this example 
using negation:

  a = -a

which is clearly applying a unary operator, and imagine there existed a 
method (if that's the word) called "neg", that also returned the 
negative value of its operand:

  a = a.neg()

This does exactly the same thing. But suddenly you're now applying a 
binary operator "." instead of a unary one!

(I'm not sure how this all applies to the loop_node.next example, but 
even here I don't count the "." as an operator, but syntax. In the 
languages I'm used to, the right-hand-side cannot be a conventional 
operand.)

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#88229

On Sat, 28 Mar 2015 13:38:20 +0000, BartC <bc@freeuk.com> wrote:

>
>(I'm not sure how this all applies to the loop_node.next example, but 
>even here I don't count the "." as an operator, but syntax.

Neiter the language. The dot symbol is a delimiter in the python
grammar. Not an operator. And also defined as a delimiter in the
official documentation, right after operators.

Meanwhile augmented assignment is governed by the `augassign`
nonterminal. An addition to its list would result in a non backwards
compatible new syntactic sugar feature. This would mabe not be a big
issue between 3.X and 2.X, but would, I reckon, be against the
compatibility rules between 3.X versions.

[toc] | [prev] | [next] | [standalone]

#88245

On Sat, Mar 28, 2015 at 9:05 AM, Mario Figueiredo <marfig@gmail.com> wrote:
> Neiter the language. The dot symbol is a delimiter in the python
> grammar. Not an operator. And also defined as a delimiter in the
> official documentation, right after operators.

What does it matter? How '.' is lexed when it appears on its own
should make no difference to the lexing of '.='.

> Meanwhile augmented assignment is governed by the `augassign`
> nonterminal. An addition to its list would result in a non backwards
> compatible new syntactic sugar feature. This would mabe not be a big
> issue between 3.X and 2.X, but would, I reckon, be against the
> compatibility rules between 3.X versions.

How would it not be backwards compatible? I'm not able to come up with
any situation where the character sequence '.=' is currently legal
outside of string literals and comments.

The counter-proposed '=.' could be an issue, since this is currently
legal Python:

    x=.3

But I believe even that is still unambiguous since you couldn't
currently follow the =. with an identifier.

[toc] | [prev] | [next] | [standalone]

#88246

On Sunday, March 29, 2015 at 9:47:00 AM UTC+5:30, Ian wrote:
> On Sat, Mar 28, 2015 at 9:05 AM, Mario Figueiredo wrote:
> > Neiter the language. The dot symbol is a delimiter in the python
> > grammar. Not an operator. And also defined as a delimiter in the
> > official documentation, right after operators.
> 
> What does it matter? How '.' is lexed when it appears on its own
> should make no difference to the lexing of '.='.

Some circularity here:
"How sth is lexed"  "sth appears on its own"
[except for 1-char/1-token programs!!]

[toc] | [prev] | [next] | [standalone]

#88218

On Sat, 28 Mar 2015 07:48 am, Ian Kelly wrote:

> On Fri, Mar 27, 2015 at 2:24 PM, Jamie Willis
> <jw14896.2014@my.bristol.ac.uk> wrote:
>> I would like to propose a new piece of syntax for the python language; .=
>>
>> In short, the operator is form of syntactic sugar, for instance consider
>> the following code:
>>
>> hello = "hello world              "
>> hello = hello.strip()
>>
>> This could be written as:
>>
>> hello = "hello world              "
>> hello .= strip()
>>
>> In this slightly contrived example, the programmer saved (a small amount
>> of) time when writing the code. With code with longer variable names, or
>> lots of similar statements all in a row, this helps to keep code more
>> concise.
>>
>> The operator would be constricted to one method or field on the
>> right-hand side, which must belong to the object on the left hand side.
> 
> Do you mean that this would not be legal?
> 
> hello .= strip().upper().encode('utf-8')
> 
> Is there a reason you want to disallow that?
> 
>> Another example could be when using Linked Lists, instead of writing
>> something like:
>>
>> loop_node = loop_node.next
>>
>> you could write:
>>
>> loop_node .= next
> 
> I realize this is just an example, but does anybody actually use
> linked lists in Python outside of class assignments? It seems hard to
> justify performance-wise since list is written in C, and if you need
> to beat it, then you probably shouldn't be doing so in Python.


https://www.safaribooksonline.com/library/view/python-cookbook/0596001673/ch14s05.html


-- 
Steven

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web