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


Groups > comp.lang.python > #88184

Re: Proposal for new minor syntax

References <CAPauRLMMAT-OffHTYW6GPybAZzouc7H9BjrmvVQiSig0X3x+ig@mail.gmail.com>
From Ian Kelly <ian.g.kelly@gmail.com>
Date 2015-03-27 14:48 -0600
Subject Re: Proposal for new minor syntax
Newsgroups comp.lang.python
Message-ID <mailman.278.1427489337.10327.python-list@python.org> (permalink)

Show all headers | View raw


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.

Back to comp.lang.python | Previous | NextNext in thread | Find similar | Unroll thread


Thread

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

csiph-web