Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!weretis.net!feeder1.news.weretis.net!feeder.erje.net!newsfeed.xs4all.nl!newsfeed5.news.xs4all.nl!newsgate.cistron.nl!newsgate.news.xs4all.nl!194.109.133.85.MISMATCH!newsfeed.xs4all.nl!newsfeed6.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
MIME-Version: 1.0
In-Reply-To: <CAA+RL7Fpaa0+S2Nu_0Mb7xA-Bto6HeAobwdt3PWrbNLFGpKuvw@mail.gmail.com>
References: <1312951356.77394.YahooMailNeo@web121518.mail.ne1.yahoo.com> <CAMZYqRRh-kSoSjywrQH=jkeysPRwms6O376dPOyTqkZtdgG_jQ@mail.gmail.com> <mailman.2085.1312956463.1164.python-list@python.org> <4e424208$0$29965$c3e8da3$5496439d@news.astraweb.com> <pan.2011.08.10.09.56.19@tombstonezero.net> <mailman.2096.1312971973.1164.python-list@python.org> <Xns9F3D8883BD21Aduncanbooth@127.0.0.1> <1312981104.89312.YahooMailNeo@web121520.mail.ne1.yahoo.com> <1312982377.95657.YahooMailNeo@web121508.mail.ne1.yahoo.com> <CAPTjJmq6bBPpMHFM7DufWnD2Mo-NWinb-d6iTeSGtRW4D1fOiw@mail.gmail.com> <1313031175.38817.YahooMailNeo@web121515.mail.ne1.yahoo.com> <CAMZYqRQ+2_trqdffnGJjv=NdB1ZutD69=ZifDa_GqH5zvWuzQw@mail.gmail.com> <4E43D2F2.1090004@mrabarnett.plus.com> <CAB4yi1NDXbROzgf6SGY7P=LWC1pb3DDOZVF6B-fWs_-O3jr8qw@mail.gmail.com> <CAA+RL7Fpaa0+S2Nu_0Mb7xA-Bto6HeAobwdt3PWrbNLFGpKuvw@mail.gmail.com>
Date: Thu, 11 Aug 2011 10:04:24 -0700
Subject: Re: [Python-ideas] allow line break at operators
From: Daniel Greenfeld <pydanny@gmail.com>
To: Jakob Bowyer <jkbbwr@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: python-list@python.org, python-ideas <python-ideas@python.org>, Matt Joiner <anacrolix@gmail.com>
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.2185.1313082268.1164.python-list@python.org>
Lines: 91
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: x330-a1.tempe.blueboxinc.net comp.lang.python:11223

Something like this already exists:

a =3D 0
b =3D 1
if (True =3D=3D True
        and False =3D=3D False
        and a + 1 =3D=3D b
        and b - 1 =3D=3D a):
        print 'meh'

So I've got no idea what this proposal is about except for the
dropping of readability of Python.

-1

Daniel Greenfeld

On Thu, Aug 11, 2011 at 8:42 AM, Jakob Bowyer <jkbbwr@gmail.com> wrote:
> -1 This idea seems like it would remove the true readability of
> python. Personally it would create more confusion than it would
> remove.
>
> On Thu, Aug 11, 2011 at 3:28 PM, Matt Joiner <anacrolix@gmail.com> wrote:
>> +0.5
>>
>> The "trailing \" workaround is nonobvious. Wrapping in () is noisy and
>> already heavily used by other syntactical structures. Since a final
>> ':' is needed anyway, i think this would be great.
>>
>> if a
>> =A0and b
>> =A0or c:
>> =A0do stuff()
>>
>> On Thu, Aug 11, 2011 at 11:02 PM, MRAB <python@mrabarnett.plus.com> wrot=
e:
>>> On 11/08/2011 05:16, Chris Rebert wrote:
>>>>
>>>> On Wed, Aug 10, 2011 at 7:52 PM, Yingjie Lan<lanyjie@yahoo.com> =A0wro=
te:
>>>>>
>>>>> :And if we require {} then truly free indentation should be OK too! B=
ut
>>>>>
>>>>> :it wouldn't be Python any more.
>>>>>
>>>>> Of course, but not the case with ';'. Currently ';' is optional in
>>>>> Python,
>>>>
>>>> I think of it more as that Python deigns to permit semicolons.
>>>>
>>>>> But '{' is used for dicts. Clearly, ';' and '{' are different in
>>>>> magnitude.
>>>>>
>>>>> So the decision is: shall we change ';' from optional to mandatory
>>>>> to allow free line splitting?
>>>>
>>>> Hell no, considering that the sizable majority of lines *aren't*
>>>> split, which makes those semicolons completely redundant to their
>>>> accompanying newlines. We'd be practicing poor Huffman coding by
>>>> optimizing for the *un*common case. It would also add punctuational
>>>> noise to what is otherwise an amazingly clean and readable syntax.
>>>> Accidental semicolon omission is (IMO) the most irritating source of
>>>> syntax (and, inadvertently, sometimes other more serious) errors in
>>>> curly-braced programming languages.
>>>>
>>> +1
>>>>
>>>> Such a core syntax feature is not going to be changed lightly (or like=
ly
>>>> ever).
>>>>
>>> I'm glad to hear that. :-)
>>>
>>> Although Python's use of indentation has its downside, we gain much
>>> more then we lose, IMHO.
>>> _______________________________________________
>>> Python-ideas mailing list
>>> Python-ideas@python.org
>>> http://mail.python.org/mailman/listinfo/python-ideas
>>>
>> _______________________________________________
>> Python-ideas mailing list
>> Python-ideas@python.org
>> http://mail.python.org/mailman/listinfo/python-ideas
>>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas@python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>