On Sat, 2011-09-03 at 13:38 +0900, Stephen J. Turnbull wrote:
> Guido van Rossum writes:
> > On Fri, Sep 2, 2011 at 12:28 AM, Stephen J. Turnbull
> wrote:
>
> > > Sure, but IIRC one design principle of Python is that the keyword that
> > > denotes the syntax should be the first thing on the l
ith such a use
case in mind.
>
>From: MRAB
>To: python-list@python.org
>Sent: Sunday, September 4, 2011 10:04 AM
>Subject: Re: [Python-ideas] allow line break at operators
>
>On 04/09/2011 00:22, Yingjie Lan wrote:
>>> Every language with blocks needs some mechanis
m:* Terry Reedy
*To:* python-list@python.org
*Cc:* python-id...@python.org
*Sent:* Sunday, September 4, 2011 3:01 AM
*Subject:* Re: [Python-ideas] allow line break at operators
On 9/3/2011 3:51 AM, Yingjie Lan wrote:
> I agree that long lines of code are not very common
t;available.
I believe the other two ways are not as good as this new way. As the proposal
is fully backward compatible, people may choose whatever way they prefer.
>
>From: Terry Reedy
>To: python-list@python.org
>Cc: python-id...@python.org
>Sent:
On 9/3/2011 3:51 AM, Yingjie Lan wrote:
I agree that long lines of code are not very common in many projects,
though it might be the case with some heavily involved in math. For some
reason, when the feature of free line breaking came about in computer
languages, it is welcomed and generally well
In article ,
Matt Joiner wrote:
> I guess the issue here is that you can't tell if an expression is
> complete without checking the indent of the following line. This is
> likely not desirable.
I wrote a weird bug the other day. I had a function that returned a
4-tuple and wanted to unpack it
On 9/3/11 3:33 AM, Yingjie Lan wrote:
> but at least we can have such 'freedom' :)
Freedom is not and never has been, IMHO, a virtue or goal or even desire
in Python. Where it occurs, it is at best a happy coincidence, and even
if that happy coincidence happens often, it is not a design feature, I
.
>
>From: Yingjie Lan
>To: Stephen J. Turnbull
>Cc: python list ; Gabriel AHTUNE ;
>python-ideas ; Matt Joiner
>Sent: Saturday, September 3, 2011 6:33 PM
>Subject: Re: [Python-ideas] allow line break at operators
>
>
>Ambiguity: yes, when the last line of a suite
we can have such 'freedom' :)
>
>From: Stephen J. Turnbull
>To: Yingjie Lan
>Cc: Gabriel AHTUNE ; Matt Joiner ;
>python-ideas
>Sent: Saturday, September 3, 2011 5:29 PM
>Subject: Re: [Python-ideas] allow line break at operators
>
>Yingjie Lan writes:
>
>&
M
>Subject: Re: [Python-ideas] allow line break at operators
>
>Yingjie Lan writes:
>
>> Have you considered line continuation by indentation? It seems to
>> meet the design principle. I think it is the most natural way to
>> allow free line breaking in Python.
>
Yingjie Lan writes:
> Have you considered line continuation by indentation? It seems to
> meet the design principle. I think it is the most natural way to
> allow free line breaking in Python.
Briefly, yes, and I think it would need a lot of tuning and probably
complex rules. Unlike statement
Guido van Rossum writes:
> On Fri, Sep 2, 2011 at 12:28 AM, Stephen J. Turnbull
> wrote:
> > Sure, but IIRC one design principle of Python is that the keyword that
> > denotes the syntax should be the first thing on the line,
[...]
> That's true for *statements* (except assignments and call
below.)
>
>From: Stephen J. Turnbull
>To: Gabriel AHTUNE
>Cc: Matt Joiner ; "python-list@python.org"
>; python-ideas ; Yingjie Lan
>
>Sent: Friday, September 2, 2011 3:28 PM
>Subject: Re: [Python-ideas] allow line break at operat
On Fri, Sep 2, 2011 at 12:28 AM, Stephen J. Turnbull wrote:
> Gabriel AHTUNE writes:
> > So can be done with this syntax:
> >
> > > x = firstpart * secondpart + #line breaks here
> > > anotherpart + #continue
> > > stillanother #continue on.
> >
> > after a "+" operator the line is clearl
Gabriel AHTUNE writes:
> So can be done with this syntax:
>
> > x = firstpart * secondpart + #line breaks here
> > anotherpart + #continue
> > stillanother #continue on.
>
> after a "+" operator the line is clearly not finished yet.
Sure, but IIRC one design principle of Python is that
Joiner
To: Yingjie Lan
Cc: "python-list@python.org" ; python-ideas
Sent: Friday, September 2, 2011 1:33 PM
Subject: Re: [Python-ideas] allow line break at operators
I guess the issue here is that you can't tell if an expression is
complete without checking the indent of the followin
Hi Gabriel,
==
From: Gabriel AHTUNE
Subject: Re: [Python-ideas] allow line break at operators
So can be done with this syntax:
> x = firstpart * secondpart + #line breaks here
> anotherpart + #continue
> stillanother #continue on.
So can be done with this syntax:
> x = firstpart * secondpart + #line breaks here
> anotherpart + #continue
> stillanother #continue on.
after a "+" operator the line is clearly not finished yet.
Gabriel AHTUNE
2011/9/2 Matt Joiner
> I guess the issue here is that you can't tell if an expr
I guess the issue here is that you can't tell if an expression is
complete without checking the indent of the following line. This is
likely not desirable.
On Thu, Sep 1, 2011 at 11:43 PM, Yingjie Lan wrote:
> Hi Matt,
> ===
> From: Matt Joiner
Hi Matt,
===
From: Matt Joiner
The "trailing \" workaround is nonobvious. Wrapping in () is noisy and
already heavily used by other syntactical structures.
===
How about only require inden
Matt Joiner wrote:
> +0.5
>
> The "trailing \" workaround is nonobvious. Wrapping in () is noisy and
> already heavily used by other syntactical structures.
"Noisy"? Compare:
# Best viewed with a fixed-width font
if a if (a
and b and b
or c:
Well the tabs&spaces issue is no longer an issue as far as I
understand it (such a change to indent semantics could only go into
3.x), and cutting and pasting to the interpreter is obvious anyway
just visually, regardless of the specific error message.
The other issue sounds reasonable. Code that
On Thu, Aug 11, 2011 at 5:29 PM, Devin Jeanpierre
wrote:
> Howeverm indentation errors have been extremely rare in my experience,
> so I'm not really compelled to think it's harmful. Especially since
> 3.x outlaws mixing tabs and spaces.
I normally get them when starting with code from somewhere
a = b,
c = d
is a pair of such statements.
Howeverm indentation errors have been extremely rare in my experience,
so I'm not really compelled to think it's harmful. Especially since
3.x outlaws mixing tabs and spaces.
I don't love it, but I guess I prefer it to throwing parentheses and
e
On Thu, Aug 11, 2011 at 2:06 PM, Devin Jeanpierre wrote:
>
> Eek no. If I was suggesting anything, it would have been a third form
> of continuation: collapsing subsequent extra-indented lines. This is
> never ambiguous. (This could be done in such a way as to permit
> comments, namely, by doing i
> Right now you do not need to indent continuation lines. So in order to
> disambiguate you would need to enforce indentation for continuations, but for
> backward compatibility that would only be required when not using parentheses
> or backslashes. Ick. Can blank lines or comment lines appear
On Thu, Aug 11, 2011 at 12:24 PM, Devin Jeanpierre
wrote:
> Javascript also lets you break lines. For example, this does what you want:
>
> return 1
> + 5
>
> Whereas this does not
>
> return
> 1 + 5
>
> Of course, Python would have no such problem, because you could make b
Javascript also lets you break lines. For example, this does what you want:
return 1
+ 5
Whereas this does not
return
1 + 5
Of course, Python would have no such problem, because you could make both
cases unambiguous due to the indent.
Devin
On Thu, Aug 11, 2011 at 3:17
Hi Matt,
On Thu, Aug 11, 2011 at 5:28 PM, Matt Joiner 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
> and b
> or c:
> d
Something like this already exists:
a = 0
b = 1
if (True == True
and False == False
and a + 1 == b
and b - 1 == 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,
-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 wrote:
> +0.5
>
> The "trailing \" workaround is nonobvious. Wrapping in () is noisy and
> already heavily used by o
+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
and b
or c:
do stuff()
On Thu, Aug 11, 2011 at 11:02 PM, MRAB wrote:
> On 11/08/2011 05:16
32 matches
Mail list logo
