Re: [Python-ideas] allow line break at operators
Thanks, I think that's the rule described in its full glory. Currently I am not
quite sure of the use case for continuation nested in continuation -- it seems
to be still a single continuation, but it allows for some additional freedom in
formatting the continued line. Do you have other use cases for that?
For the case of mis-indentation, as demonstrated in your scenario, I think it
is better that the rule is not applied to a comment continued onto the next
line. The effect of a '#' only carries to the end of a line, if one would like
the next line to be a comment, just use another '#'. It remains to consider a
mis-indentation that only involves code lines. However, that is not a new
problem, so we should not worry (it is like a sunken cost).
Sorry for top posting. It seems yahoo web email is not designed with such a use
case in mind.
From: MRAB pyt...@mrabarnett.plus.com
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 mechanism to indicate the
beginning and ending of blocks and of statements within blocks. If
visible fences ('begin/end' or '{}') and statement terminators (';') are
used, then '\n' can be treated as merely a space, as it is in C, for
instance.
and it uses unescaped '\n' (with two escapement options) to terminate
statements. This is fundamental to Python's design and goes along with
significant indents.
Agreed. Currently indentation in Python starts a new block, but if you
view it from the perspective of line breaking, it also functions as if
the line is continued. The line of code below
if condition: do_a(); do_b()
can be written as:
if condition: #line breaks
do_a(); # ';' is optional here
do_b() # continue
That indentation can be also employed for line breaking is quite evident
to me. During the open email correspondence with Stephen, it seems to be
a tenable point.
There would then be three ways to escape newline, with one doing
double duty. And for what? Merely to avoid using either of the two
methods already 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.
I think that the rules would be:
If a line ends with a colon and the next line is indented, then it's
the start of a block, and the following lines which belong to that
block have the same indent.
If a line doesn't end with a colon but the next line is indented, then
it's the start of a continuation, and the following lines which belong
to that continuation have the same indent.
In both cases there could be blocks nested in blocks and possibly
continuations nested in continuations, as well as blocks nested in
continuations and continuations nested in blocks.
I'm not sure what the effect would be if you had mis-indented lines.
For example, if a line was accidentally indented after a comment, then
it would be treated as part of the comment. It's in cases like those
that syntax colouring would be helpful. It would be a good idea to use
an editor which could indicate in some way when a line is a
continuation.
*From:* Terry Reedy tjre...@udel.edu
*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 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 accepted.
Every language with blocks needs some mechanism to indicate the
beginning and ending of blocks and of statements within blocks. If
visible fences ('begin/end' or '{}') and statement terminators (';')
are used, then '\n' can be treated as merely a space, as it is in C,
for instance.
Python uses indentation for blocks,
and it uses unescaped '\n' (with two escapement options) to
terminate statements. This is fundamental to Python's design and
goes along with significant indents.
and by the same mechanism, line breaking can be
accommodated without requiring parenthesis or ending backslashes.
You need proof for your claim that indentation can be used for both
jobs in the form of a grammar that works with Python's parser. I am
dubious that you can do that with an indents *after* the newline.
Even if you could, it would be confusing for human readers. There
would then be three ways to escape newline, with one doing double
duty. And for what? Merely
Re: allow line break at operators
On Sep 3, 11:50 am, Stephen Hansen me+list/pyt...@ixokai.io wrote: Freedom is not and never has been, IMHO, a virtue or goal or even desire in Python. Exactly! Where it occurs, it is at best a happy coincidence, Exactly! and even if that happy coincidence happens often, it is not a design feature, IMHO. Exactly! Actually i believe Python allows TOO many freedoms and indulges TOO many excesses to the detriment of our code bases. Take the fact that both tabs AND spaces are legal in Python source. We should have choose one over the other! -- http://mail.python.org/mailman/listinfo/python-list
Re: [Python-ideas] allow line break at operators
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 step...@xemacs.org 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 calls). Analogously, if operators are going to denote continuation, they should come first on the line. That doesn't follow. Agreed, it's not a logical implication. The analogy is only an analogy, but my eyes do work that way. My conclusion is that we shouldn't try to encourage either style, because people see continuation differently. Legislating a style isn't going to change that, I think. I like to start continued lines with an operator as well. I also think it helps me keep it in my head a bit easier when I do that. I think this is one of those areas where computers and people differ, but it may also depend on the persons native language as to what works better for them. Ron -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On Sep 4, 10:22 am, ron3200 ron3...@gmail.com wrote: I think this is one of those areas where computers and people differ, but it may also depend on the persons native language as to what works better for them. Yes but what works better for them is not always a better way of doing things! People do foolish things all the time just from pure habit. A foolish consistency is a foolish consistency my friend. I mean, look at the folks who popped their cherry writing Basic code; talk about dysfunctional! -- http://mail.python.org/mailman/listinfo/python-list
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. Briefly, yes, and I think it would need a lot of tuning and probably complex rules. Unlike statements, where everybody (except the judges of the Obfuscated C Contest) agrees on a simple rule: In a control structure, the controlled suite should be uniformly indented one level, line breaking and indentation of long expressions is an art, and people have different opinions on readability and beauty. Achieving a compromise that is workable even for a few major styles is likely to be annoying and bug-prone. Pretty much every program I write seems to have a continued list of data or a multi-line dictionary display as data. It's not unusual for me to comment the formal arguments in a function definition, or the parent classes of a class definition. The exception for parenthesized objects is something I depend on for what I consider good style. Of course I could use explicit continuation, but in a long table that's ugly and error-prone. Long expressions that need to be broken across lines, on the other hand, often indication that I haven't thought carefully enough about that component of the program, and an extra pair of parentheses or a terminal backslash just isn't that heavy or ugly in the context of such long expressions. For me, they're also pretty rare; many programs I write have no explicit continuations in them at all. YMMV, of course, but I find the compromise that Python arrived at to be very useful, and I must suppose that it was substantially easier to implement than fully free line breaking (whatever that means to you). -- http://mail.python.org/mailman/listinfo/python-list
Re: [Python-ideas] allow line break at operators
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 accepted. Python uses indentation for blocks, and by the same mechanism, line breaking can be accommodated without requiring parenthesis or ending backslashes. For the tuning, yes, people would disagree on how to split expressions/code. The continue-by-indentation would allow people to break a line in whatever way that pleases their aesthetic taste, as long as there is an indentation. Most people seems to like an indentation on the continuing lines, probably for a visual indication of a continuation line. Some general guidelines may be provided, but there is no need for other hard rules on breaking lines, except that an identifier should never be split apart. For the implementation, I don't have much clue. At least on the parser, it needs to look beyond the linefeed to determine if a line is completed. If the indentation is defined as a single symbol, then it would only require a one-step look-ahead, and that should not be hard. Again, my apology for top posting. From: Stephen J. Turnbull step...@xemacs.org To: Yingjie Lan lany...@yahoo.com Cc: Gabriel AHTUNE gaht...@gmail.com; Matt Joiner anacro...@gmail.com; python-list@python.org python-list@python.org; python-ideas python-id...@python.org Sent: Saturday, September 3, 2011 2:10 PM 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. Briefly, yes, and I think it would need a lot of tuning and probably complex rules. Unlike statements, where everybody (except the judges of the Obfuscated C Contest) agrees on a simple rule: In a control structure, the controlled suite should be uniformly indented one level, line breaking and indentation of long expressions is an art, and people have different opinions on readability and beauty. Achieving a compromise that is workable even for a few major styles is likely to be annoying and bug-prone. Pretty much every program I write seems to have a continued list of data or a multi-line dictionary display as data. It's not unusual for me to comment the formal arguments in a function definition, or the parent classes of a class definition. The exception for parenthesized objects is something I depend on for what I consider good style. Of course I could use explicit continuation, but in a long table that's ugly and error-prone. Long expressions that need to be broken across lines, on the other hand, often indication that I haven't thought carefully enough about that component of the program, and an extra pair of parentheses or a terminal backslash just isn't that heavy or ugly in the context of such long expressions. For me, they're also pretty rare; many programs I write have no explicit continuations in them at all. YMMV, of course, but I find the compromise that Python arrived at to be very useful, and I must suppose that it was substantially easier to implement than fully free line breaking (whatever that means to you). -- http://mail.python.org/mailman/listinfo/python-list
Re: [Python-ideas] allow line break at operators
Ambiguity: yes, when the last line of a suite is a continued line, it would
require double dedentations to end the line and the suite. I noticed a similar
case in current Python language as well:
==
#BEGIN CODE 1
if condition:
for i in range(5):
triangulate(i)
else: #double dedentations
for body in space:
triangulate(body)
#double dedentations again
log('triangulation done')
#END CODE 1
==
If lines can be continued by indentation, similar situation would rise:
==
#BEGIN CODE 2
if condition:
result = [sin(i) for i in range(5)]
+ [cos(i) for i in range(5)]
else:
result = [cos(i) for i in range(5)]
+ [sin(i) for i in range(5)]
log('triangulation done')
#END CODE 2
==
Generating text example: right, this is a case that can't be handled by
standard indentation, unless we only consider full dedentation (dedentation to
the exact level of the initial indentation) as the signal of ending the line.
Whether to accommodate for such a case might be an issue of debate, but at
least we can have such 'freedom' :)
From: Stephen J. Turnbull step...@xemacs.org
To: Yingjie Lan lany...@yahoo.com
Cc: Gabriel AHTUNE gaht...@gmail.com; Matt Joiner anacro...@gmail.com;
python-ideas python-id...@python.org
Sent: Saturday, September 3, 2011 5:29 PM
Subject: Re: [Python-ideas] allow line break at operators
Yingjie Lan writes:
Python uses indentation for blocks, and by the same mechanism, line
breaking can be accommodated without requiring parenthesis or
ending backslashes.
Possibly, but now you have a problem that a dedent has ambiguous
meaning. It might mean that you're ending a suite, or it might mean
you're ending a continued expression. This probably can be
disambiguated, but I don't know how easy that will be to do perfectly,
including in reporting ill-formed programs.
Most people seems to like an indentation on the continuing lines,
Most of the time, yes, but sometimes not. For example, in generating
text, it's often useful to dedent substantially so you can have a
nearly normal length line in the literal strings being concatenated.
Or you might have a pattern like this:
x = long_named_variable_a
- long_named_variable_a_base
+ long_named_variable_b
- long_named_variable_b_base
which your parser would raise an error on, I presume. That's not
freedom!wink /
--
http://mail.python.org/mailman/listinfo/python-list
Re: [Python-ideas] allow line break at operators
Oops, the generating text part of my reply is referring to your last code
example. For literal texts, it is is not governed by this proposal, nor are
expressions within brackets and backslash continued lines. In a word, this
proposal is fully backward compatible.
From: Yingjie Lan lany...@yahoo.com
To: Stephen J. Turnbull step...@xemacs.org
Cc: python list python-list@python.org; Gabriel AHTUNE gaht...@gmail.com;
python-ideas python-id...@python.org; Matt Joiner anacro...@gmail.com
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 is a continued line, it would
require double dedentations to end the line and the suite. I noticed a similar
case in current Python language as well:
==
#BEGIN CODE 1
if condition:
for i in range(5):
triangulate(i)
else: #double dedentations
for body in space:
triangulate(body)
#double dedentations again
log('triangulation done')
#END CODE 1
==
If lines can be continued by indentation, similar situation would rise:
==
#BEGIN CODE 2
if condition:
result = [sin(i) for i in range(5)]
+ [cos(i) for i in range(5)]
else:
result = [cos(i) for i in range(5)]
+ [sin(i) for i in range(5)]
log('triangulation done')
#END CODE 2
==
Generating text example: right, this is a case that can't be handled by
standard indentation, unless we only consider full dedentation (dedentation to
the exact level of the initial indentation) as the signal of ending the line.
Whether to accommodate for such a case might be an issue of debate, but at
least we can have such 'freedom' :)
From: Stephen J. Turnbull step...@xemacs.org
To: Yingjie Lan lany...@yahoo.com
Cc: Gabriel AHTUNE gaht...@gmail.com; Matt Joiner anacro...@gmail.com;
python-ideas python-id...@python.org
Sent: Saturday, September 3, 2011 5:29 PM
Subject: Re: [Python-ideas] allow line break at operators
Yingjie Lan writes:
Python uses indentation for blocks, and by the same mechanism, line
breaking can be accommodated without requiring parenthesis or
ending backslashes.
Possibly, but now you have a problem that a dedent has ambiguous
meaning. It might mean that you're ending a suite, or it might mean
you're ending a continued expression. This probably can be
disambiguated, but I don't know how easy that will be to do
perfectly,
including in reporting ill-formed programs.
Most people seems to like an indentation on the continuing lines,
Most of the time, yes, but sometimes not. For example, in generating
text, it's often useful to dedent substantially so you can have a
nearly normal length line in the literal strings being concatenated.
Or you might have a pattern like this:
x = long_named_variable_a
- long_named_variable_a_base
+ long_named_variable_b
- long_named_variable_b_base
which your parser would raise an error on, I presume. That's not
freedom!wink /
--
http://mail.python.org/mailman/listinfo/python-list
--
http://mail.python.org/mailman/listinfo/python-list
Re: [Python-ideas] allow line break at operators
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, IMHO. Simplicity and readability are virtues in Python. Freedom is even declared a vice to be avoided by the Zen, that holy document which defines all things Pythonic in clear and unambiguously absolute terms*. Looking over this whole thread at the various examples -- they add complication (a vice!). Complication to the parser, complication to the language itself and worse, understanding of code (as your head has to parse things too), all for what? So you don't have to use parens, which quite explicitly (another virtue!) do the job, to wrap around a long expression? Escaping newlines is arguably a bit on the ugly side (a vice!), so maybe the proposal has a little weight there, but since you can just avoid that by using parens, that's pretty much nullified. (Since it is also a virtue to offer only the Dutch way of doing things -- at least without hiding the alternatives in modules with a little bit of shame -- and this is clearly a case of the Dutch liking limited use of grouping parens). There just isn't even vaguely enough justification based on Python-virtues (readability, simplicity, explicitness, things like that) to even kind of make it worth the complication. -- Stephen Hansen ... Also: Ixokai ... Mail: me+list/python (AT) ixokai (DOT) io ... Blog: http://meh.ixokai.io/ * Obvious exaggeration :P signature.asc Description: OpenPGP digital signature -- http://mail.python.org/mailman/listinfo/python-list
Re: [Python-ideas] allow line break at operators
In article mailman.688.1314941609.27778.python-l...@python.org, Matt Joiner anacro...@gmail.com 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, so I wrote: var1, var2, var3, var4 = my_function() which isn't a syntax error, but also isn't what I meant. Depending on whether var[123] have pre-existing values, this doesn't even produce a run-time error. Emacs encouraged me in this crime by merrily auto-indenting the code the way I expected :-) -- http://mail.python.org/mailman/listinfo/python-list
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 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 accepted.
Every language with blocks needs some mechanism to indicate the
beginning and ending of blocks and of statements within blocks. If
visible fences ('begin/end' or '{}') and statement terminators (';') are
used, then '\n' can be treated as merely a space, as it is in C, for
instance.
Python uses indentation for blocks,
and it uses unescaped '\n' (with two escapement options) to terminate
statements. This is fundamental to Python's design and goes along with
significant indents.
and by the same mechanism, line breaking can be
accommodated without requiring parenthesis or ending backslashes.
You need proof for your claim that indentation can be used for both jobs
in the form of a grammar that works with Python's parser. I am dubious
that you can do that with an indents *after* the newline.
Even if you could, it would be confusing for human readers. There would
then be three ways to escape newline, with one doing double duty. And
for what? Merely to avoid using either of the two methods already available.
--
Terry Jan Reedy
--
http://mail.python.org/mailman/listinfo/python-list
Re: [Python-ideas] allow line break at operators
Every language with blocks needs some mechanism to indicate the beginning and
ending of blocks and of statements within blocks. If visible fences
('begin/end' or '{}') and statement terminators (';') are used, then '\n' can
be treated as merely a space, as it is in C, for instance.
and it uses unescaped '\n' (with two escapement options) to terminate
statements. This is fundamental to Python's design and goes along with
significant indents.
Agreed. Currently indentation in Python starts a new block, but if you view it
from the perspective of line breaking, it also functions as if the line is
continued. The line of code below
if condition: do_a(); do_b()
can be written as:
if condition: #line breaks
do_a(); # ';' is optional here
do_b() # continue
That indentation can be also employed for line breaking is quite evident to me.
During the open email correspondence with Stephen, it seems to be a tenable
point.
There would then be three ways to escape newline, with one doing double duty.
And for what? Merely to avoid using either of the two methods already
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 tjre...@udel.edu
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 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 accepted.
Every language with blocks needs some mechanism to indicate the beginning and
ending of blocks and of statements within blocks. If visible fences
('begin/end' or '{}') and statement terminators (';') are used, then '\n' can
be treated as merely a space, as it is in C, for instance.
Python uses indentation for blocks,
and it uses unescaped '\n' (with two escapement options) to terminate
statements. This is fundamental to Python's design and goes along with
significant indents.
and by the same mechanism, line breaking can be
accommodated without requiring parenthesis or ending backslashes.
You need proof for your claim that indentation can be used for both jobs in
the form of a grammar that works with Python's parser. I am dubious that you
can do that with an indents *after* the newline.
Even if you could, it would be confusing for human readers. There would then
be three ways to escape newline, with one doing double duty. And for what?
Merely to avoid using either of the two methods already available.
-- Terry Jan Reedy
-- http://mail.python.org/mailman/listinfo/python-list
--
http://mail.python.org/mailman/listinfo/python-list
Re: [Python-ideas] allow line break at operators
On 04/09/2011 00:22, Yingjie Lan wrote:
Every language with blocks needs some mechanism to indicate the
beginning and ending of blocks and of statements within blocks. If
visible fences ('begin/end' or '{}') and statement terminators (';') are
used, then '\n' can be treated as merely a space, as it is in C, for
instance.
and it uses unescaped '\n' (with two escapement options) to terminate
statements. This is fundamental to Python's design and goes along with
significant indents.
Agreed. Currently indentation in Python starts a new block, but if you
view it from the perspective of line breaking, it also functions as if
the line is continued. The line of code below
if condition: do_a(); do_b()
can be written as:
if condition: #line breaks
do_a(); # ';' is optional here
do_b() # continue
That indentation can be also employed for line breaking is quite evident
to me. During the open email correspondence with Stephen, it seems to be
a tenable point.
There would then be three ways to escape newline, with one doing
double duty. And for what? Merely to avoid using either of the two
methods already 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.
I think that the rules would be:
If a line ends with a colon and the next line is indented, then it's
the start of a block, and the following lines which belong to that
block have the same indent.
If a line doesn't end with a colon but the next line is indented, then
it's the start of a continuation, and the following lines which belong
to that continuation have the same indent.
In both cases there could be blocks nested in blocks and possibly
continuations nested in continuations, as well as blocks nested in
continuations and continuations nested in blocks.
I'm not sure what the effect would be if you had mis-indented lines.
For example, if a line was accidentally indented after a comment, then
it would be treated as part of the comment. It's in cases like those
that syntax colouring would be helpful. It would be a good idea to use
an editor which could indicate in some way when a line is a
continuation.
*From:* Terry Reedy tjre...@udel.edu
*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 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 accepted.
Every language with blocks needs some mechanism to indicate the
beginning and ending of blocks and of statements within blocks. If
visible fences ('begin/end' or '{}') and statement terminators (';')
are used, then '\n' can be treated as merely a space, as it is in C,
for instance.
Python uses indentation for blocks,
and it uses unescaped '\n' (with two escapement options) to
terminate statements. This is fundamental to Python's design and
goes along with significant indents.
and by the same mechanism, line breaking can be
accommodated without requiring parenthesis or ending backslashes.
You need proof for your claim that indentation can be used for both
jobs in the form of a grammar that works with Python's parser. I am
dubious that you can do that with an indents *after* the newline.
Even if you could, it would be confusing for human readers. There
would then be three ways to escape newline, with one doing double
duty. And for what? Merely to avoid using either of the two methods
already available.
--
http://mail.python.org/mailman/listinfo/python-list
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. after a + operator the line is clearly not finished yet. Gabriel AHTUNE 2011/9/2 Matt Joiner anacro...@gmail.com 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 lany...@yahoo.com wrote: Hi Matt, === From: Matt Joiner anacro...@gmail.com The trailing \ workaround is nonobvious. Wrapping in () is noisy and already heavily used by other syntactical structures. === How about only require indentation to freely break lines? Here is an example: x = firstpart * secondpart #line breaks here + anotherpart #continue by indentation + stillanother #continue on. #until here, another line starts by dedentation y = some_expression - another_one All this would be completely compatible with former code, while having almost free line breaking! Plus, indentation makes it pretty. Really hope Python can have freedom in breaking lines. Yingjie ___ Python-ideas mailing list python-id...@python.org http://mail.python.org/mailman/listinfo/python-ideas -- http://mail.python.org/mailman/listinfo/python-list
Re: [Python-ideas] allow line break at operators
Hi Gabriel, == From: Gabriel AHTUNE gaht...@gmail.com 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. after a + operator the line is clearly not finished yet. Gabriel AHTUNE == That's good to me too, which I proposed early in this thread. Then somebody would like to have the operator in the beginning of the next line so that it would stand out.Then still another one said that indentation is good here. So I finally proposed line continuation with indentation. Since this is Python, we will live with indentation. Currently indentation in Python starts a new block, but if you view it from the perspective of line breaking, it also function as if the line is continued. The line if condition: do_a(); do_b() can be written as: if condition: #line breaks do_a(); # ';' is optional here do_b() # continue Sounds a pretty natural way to allow free line breaking. Yingjie-- http://mail.python.org/mailman/listinfo/python-list
Re: [Python-ideas] allow line break at operators
Yeah, that might be a challenge for the Python interpreter, for it has to check if the next line is indented or not. But it might be worthwhile to take this trouble, so that the coder has more freedom, and the code is hopefully better to read. From: Matt Joiner anacro...@gmail.com To: Yingjie Lan lany...@yahoo.com Cc: python-list@python.org python-list@python.org; python-ideas python-id...@python.org 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 following line. This is likely not desirable. On Thu, Sep 1, 2011 at 11:43 PM, Yingjie Lan lany...@yahoo.com wrote: Hi Matt, === From: Matt Joiner anacro...@gmail.com The trailing \ workaround is nonobvious. Wrapping in () is noisy and already heavily used by other syntactical structures. === How about only require indentation to freely break lines? Here is an example: x = firstpart * secondpart #line breaks here + anotherpart #continue by indentation + stillanother #continue on. #until here, another line starts by dedentation y = some_expression - another_one All this would be completely compatible with former code, while having almost free line breaking! Plus, indentation makes it pretty. Really hope Python can have freedom in breaking lines. Yingjie-- http://mail.python.org/mailman/listinfo/python-list
Re: [Python-ideas] allow line break at operators
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 the keyword that denotes the syntax should be the first thing on the line, making it easy to scan down the left side of the code to see the syntactic structure. The required indentation of the controlled suite also helps emphasize that keyword. Analogously, if operators are going to denote continuation, they should come first on the line. I just don't think this idea is going anywhere. Explicit continuation with backslash or implicit continuation of parenthesized expressions is just not that heavy a price to pay. Perhaps historically some of these ideas could have been implemented, but now they're just going to confuse a host of editors and code analysis tools. -- http://mail.python.org/mailman/listinfo/python-list
Re: [Python-ideas] allow line break at operators
On Fri, Sep 2, 2011 at 12:28 AM, Stephen J. Turnbull step...@xemacs.org 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 clearly not finished yet. Sure, but IIRC one design principle of Python is that the keyword that denotes the syntax should be the first thing on the line, making it easy to scan down the left side of the code to see the syntactic structure. The required indentation of the controlled suite also helps emphasize that keyword. That's true for *statements* (except assignments and calls). Analogously, if operators are going to denote continuation, they should come first on the line. That doesn't follow. My preferred style is actually to put the binary operator at the end of the line. This also matches the prevailing style for breaking lines after commas (a comma can be seen as a kind of binary operator). I just don't think this idea is going anywhere. Explicit continuation with backslash or implicit continuation of parenthesized expressions is just not that heavy a price to pay. Perhaps historically some of these ideas could have been implemented, but now they're just going to confuse a host of editors and code analysis tools. Totally agreed that this isn't going to happen. -- --Guido van Rossum (python.org/~guido) -- http://mail.python.org/mailman/listinfo/python-list
Re: [Python-ideas] allow line break at operators
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. (Sorry, the yahoo web email interface is so weird that I don't know how to format comments between the quoted message below.) From: Stephen J. Turnbull step...@xemacs.org To: Gabriel AHTUNE gaht...@gmail.com Cc: Matt Joiner anacro...@gmail.com; python-list@python.org python-list@python.org; python-ideas python-id...@python.org; Yingjie Lan lany...@yahoo.com Sent: Friday, September 2, 2011 3:28 PM Subject: Re: [Python-ideas] allow line break at operators 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 the keyword that denotes the syntax should be the first thing on the line, making it easy to scan down the left side of the code to see the syntactic structure. The required indentation of the controlled suite also helps emphasize that keyword. Analogously, if operators are going to denote continuation, they should come first on the line. I just don't think this idea is going anywhere. Explicit continuation with backslash or implicit continuation of parenthesized expressions is just not that heavy a price to pay. Perhaps historically some of these ideas could have been implemented, but now they're just going to confuse a host of editors and code analysis tools. -- http://mail.python.org/mailman/listinfo/python-list
Re: [Python-ideas] allow line break at operators
Guido van Rossum writes: On Fri, Sep 2, 2011 at 12:28 AM, Stephen J. Turnbull step...@xemacs.org 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 calls). Analogously, if operators are going to denote continuation, they should come first on the line. That doesn't follow. Agreed, it's not a logical implication. The analogy is only an analogy, but my eyes do work that way. My conclusion is that we shouldn't try to encourage either style, because people see continuation differently. Legislating a style isn't going to change that, I think. -- http://mail.python.org/mailman/listinfo/python-list
Re: [Python-ideas] allow line break at operators
Hi Matt, === From: Matt Joiner anacro...@gmail.com The trailing \ workaround is nonobvious. Wrapping in () is noisy and already heavily used by other syntactical structures. === How about only require indentation to freely break lines? Here is an example: x = firstpart * secondpart #line breaks here + anotherpart #continue by indentation + stillanother #continue on. #until here, another line starts by dedentation y = some_expression - another_one All this would be completely compatible with former code, while having almost free line breaking! Plus, indentation makes it pretty. Really hope Python can have freedom in breaking lines. Yingjie-- http://mail.python.org/mailman/listinfo/python-list
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 following line. This is likely not desirable. On Thu, Sep 1, 2011 at 11:43 PM, Yingjie Lan lany...@yahoo.com wrote: Hi Matt, === From: Matt Joiner anacro...@gmail.com The trailing \ workaround is nonobvious. Wrapping in () is noisy and already heavily used by other syntactical structures. === How about only require indentation to freely break lines? Here is an example: x = firstpart * secondpart #line breaks here + anotherpart #continue by indentation + stillanother #continue on. #until here, another line starts by dedentation y = some_expression - another_one All this would be completely compatible with former code, while having almost free line breaking! Plus, indentation makes it pretty. Really hope Python can have freedom in breaking lines. Yingjie -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On Aug 16, 2:37 pm, rantingrick rantingr...@gmail.com wrote: The reading proceeds naturally from right to left. Well, naturally if you're coding in Hebrew or Japanese perhaps :) -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On Aug 16, 1:49 am, alex23 wuwe...@gmail.com wrote:
On Aug 16, 2:37 pm, rantingrick rantingr...@gmail.com wrote:
The reading proceeds naturally from right to left.
Well, naturally if you're coding in Hebrew or Japanese perhaps :)
Yes :). I typo-ed that one. It was getting late when i sent that
reply. I did consider posting an edit however i decided not to and
instead, wait and see who would notice.
The map feels much better too as a consequence:
rb [3,100,-20].map{|x| x.to_f}
[3.0, 100.0, -20.0]
And you can can induce some logic without a clunky lambda.
rb[3,100,-20].map{|x| if x 99 then x.to_f else x end}
[3.0, 100.0, -20.0]
in Python you'd have to create a def for that (i know bad specific
example but the need is there)
It feels just like a Python list comprehension though:
py [float(x) for x in [3,100,-20]]
Even though it reads in a non-linear way, you could argue that the
most important part (float(x)). is front-and-center. Of course i like
the compactness of python's map function:
py map(float, [3,100,-20])
But all too often the map function is insufficient AND you cannot use
map in a chain! If only we could find a happy medium between Python
and Ruby oh what a bliss that would be. We could cut off all of
Pythons warts and destroy all of Rubys multiplicity and singular
paridigm-ness.
* Forced indention (exactly one tab, and one tab only!)
* No multiplicity!
* Nice linear expressions!
* Name spaces!
* Implicit modules!
* Only truly heterogeneous built-in functions allowed!
* Enough freedom to be expressive, but not enough to allow sloppy-
ness.
--
http://mail.python.org/mailman/listinfo/python-list
RE: allow line break at operators
1. Indentation as flow control was a bad idea. 2. People are subconsciously aware of this. 3. There is a HUGE degree of emotional investment in defending it. The responses I have seen on this issue are highly emotional, full of insults, full of blame-throwing, and utterly contrary to the basic engineering spirit I usually see in programming communities. In other languages, and even in Python on any issue but this one, I regularly see people acknowledge shortcomings and explain either why they think the tradeoffs are good, or why they are willing to put up with it anyway. The characteristic vehemence and hostility this issue produces are the surest sign of people who have a desperate need not to acknowledge the elephant in the room. What exactly is the downside to indentation as flow control? I am a fairly new programmer to Python, but the more I use it, the more I think it has the Right idea (for me at least). I find braces in Java/c[#,++] to be less than helpful in comparison to how people rave over. It allows for free form code sure, but half the time I was using indentation to figure out where conditional branching/loops started and stopped anyway! I will admit it was super useful in helping Eclipse to reformat with a more readable indentation. The only difference is that now it forces me to make more readable code instead of allowing me the freedom to make hard to read code. I suppose as an American I should be insulted at the lack of freedom. Hell, I own Apple products; I must be getting indoctrinated into a lack of freedom. :-P I am not being vehement or hostile. At least I am attempting to be neither. I do not really feel emotionally invested in either because honestly, I will do whatever I have to for what I am trying to get done. If that requires me coding while only wearing hot pink or using braces I will do it. I am far more concerned with ease of coding, ability to do what I want, and occasionally (fairly rarely) if the running code will be fast enough. I am not sure why people are so stuck on braces. I figured other people would be like me and tired of having to do things like figuring out where I missed an end brace. Ramit Ramit Prasad | JPMorgan Chase Investment Bank | Currencies Technology 712 Main Street | Houston, TX 77002 work phone: 713 - 216 - 5423 This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email. -- http://mail.python.org/mailman/listinfo/python-list
RE: allow line break at operators
PS: I will admit that a few of our community members can be rather acerbic at times. Yeah. And the thing is... This can't possibly lead to convincing people of your position, so presumably the purpose is that you don't want anyone who didn't start out agreeing with you to ever come to agree with you? Why's that? Rantingrick: Do answer his question, please. Ramit Ramit Prasad | JPMorgan Chase Investment Bank | Currencies Technology 712 Main Street | Houston, TX 77002 work phone: 713 - 216 - 5423 This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email. -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On Tue, Aug 16, 2011 at 8:26 PM, Prasad, Ramit
ramit.pra...@jpmorgan.com wrote:
I am not sure why people are so stuck on braces. I figured other people would
be like me and tired of having to do things like figuring out where I missed
an end brace.
I'm one of the fans of braces, but search the list archives and you'll
find plenty of arguments on both sides. I like braces because they
allow me to separate the syntax from the layout; I can choose to
indent things based on logical structure, even when that doesn't
correspond to the compiler's notion of the structure. Here's an
example from C++:
struct _blah
{
int x;
int y;
char **z;
//etc etc etc
}; struct blah: public _blah {
char padding[1024-sizeof(_blah)];
};
The inheritance isn't significant to the overall concept of the object
(the idea was that it should have a size of exactly 1024, as this had
to interface with some lower-level systems), but it's significant to
the compiler's understanding of the object. The braces, therefore,
follow the compiler's requirements, but the indentation follows the
programmer's. (And yes, there were comments explaining things, and
much better element names.)
Another idiom I often use in C or C++ is the conditional for loop:
for (x=getfirst();x;x=getnext()) if (x%3)
{
blah
blah
}
The equivalent in Python:
for x in blah: if x%3:
blah
blah
is not legal, and must be written with an extra indentation:
for x in blah:
if x%3:
blah
blah
I'm sure I could sort something out with a filtering generator, but it
seems ridiculous to write:
def condition(gen,func):
for elem in gen:
if func(elem): yield elem
for x in condition(blah,lambda x: x%3):
blah
blah
There are very good reasons for Python's system, and I don't object to
it *in Python*. But I do not see indentation-as-structure as the
ultimate and perfect system, and I desire and intend to preserve the
freedom to choose languages with different systems.
Chris Angelico
--
http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On 2011-08-16, Prasad, Ramit ramit.pra...@jpmorgan.com wrote: What exactly is the downside to indentation as flow control? I think a lot of it is personal taste or differences in how peoples' brains work. I don't want free form code, I don't want to write stuff that isn't correctly indented. I want a visual cue I can match up with the start of a loop so I know for sure what I meant, and a way to recover code in the event of Something Going Wrong. I am not sure why people are so stuck on braces. I figured other people would be like me and tired of having to do things like figuring out where I missed an end brace. For me, if I've made an error of that category, the options are: 1. In C, finding out where I missed an end brace, because the compiler warned me, so I go look for an outdent without a brace. 2. In Python, having no clue at all what's wrong or why the program isn't running, and having no cue I can look to to see where the error occurred. Basically, it's parity bits. I love me some parity bits. :) I also recognize that this is a matter of taste; there are sound reasons for other people to have different preferences. -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On 8/15/2011 12:28 AM, Seebs wrote: To repeat again: you are free to put in explicit dedent markers that will let you re-indent code should all indents be removed. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On Mon, Aug 15, 2011 at 5:28 AM, Seebs usenet-nos...@seebs.net wrote:
Character stream: tab tab tab foo newline tab bar. This is, as you
say, *usually* two dedents, but it could be one.
I see your point, though I cannot imagine anyone who would use tab
tab as an indent level. But if you go from 16 spaces down to 8, it's
possible that the script uses eight space indents, or four.
On Mon, Aug 15, 2011 at 8:31 AM, Terry Reedy tjre...@udel.edu wrote:
To repeat again: you are free to put in explicit dedent markers that will
let you re-indent code should all indents be removed.
This would be a solution to the above, but it has the feeling of
syntactic salt. (I don't believe that braces are, because they afford
a different form of flexibility.) But sure, if you configure your
editor to do it for you.
I type: if (blah):
It puts:
if (blah):
|
# if
with the cursor at the | marker. I never really got used to editors
doing this for me, though. It didn't feel right. I prefer an editor
that deals with my indentation but lets me do the rest; when I hit
enter, it autoindents to either the current indent level or one
greater, depending on whether it looks like there ought to be an
indent (which mainly happens when I put a loose { on a line).
Similarly, when I put a } into the file, it removes an indent level
automatically.
Still, it wouldn't be hard to make an editor put those dedent comments
in, if you want them.
ChrisA
--
http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On Aug 14, 2011 3:24 PM, Seebs usenet-nos...@seebs.net wrote: ... I'm not impressed by arguments based on but if I do something stupid, like select text with my eyes closed and reindent it without looking, I expect the compiler to save my bacon. In my opinion, it's not the compiler's job to protect you from errors caused by sheer carelessness at the keyboard. I don't know about sheer carelessness. Typos happen. Typos are not something you can prevent from happening just by wanting it very much. If you have valid code caused by improper indentation, shouldn't that be caught by a good set of unit tests? -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On 08/14/2011 11:28 PM, Seebs wrote:
I tend to write stuff like
foo.array_of_things.sort.map { block }.join(, )
I like this a lot more than
array = foo.array_of_things
sorted_array = array.sort()
mapped_array = [block(x) for x in sorted_array]
, .join(mapped_array)
If you like the one-liner, this is readily written as
, .join(block(x) for x in sorted(foo.array_of_things))
Modulo your gripes about string.join(), this is about as succinct
(and more readable, IMHO) as your initial example. I've got
piles of these sorts of things in my ETL code.
-tkc
--
http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
Chris Angelico ros...@gmail.com writes: Why is left-to-right inherently more logical than multiplication-before-addition? Why is it more logical than right-to-left? And why is changing people's expectations more logical than fulfilling them? Python uses the + and - symbols to mean addition and subtraction for good reason. Let's not alienate the mathematical mind by violating this rule. It would be far safer to go the other way and demand parentheses on everything. I'm a clearly a fool for allowing myself to be drawn into this thread, but I've been playing a lot recently with the APL-derivative language J, which uses a right-to-left operator precendence rule. Pragmatically, this is because J defines roughly a bajillion operators, and it would be impossible to remember the precendence of them all, but it makes sense in its own way. If you read 3 * 10 + 7, using right-to-left, you get three times something. Then you read more and you get three times (ten plus something). And finally, you get 3*(10+7). The prefix gives the continuation for the rest of the calculation; no matter what you substitute for X in 3*X, you will always just evaluate X, then multply it by 3. Likewise, for 3*10+X, no matter what X is, you know you'll add 10 and multiply by 3. This took me a while to get used to, but it's definitely a nice property. Not much to do with python, but I do like the syntax enough that I've implemented my own toy evaluator for J-like expressions in python, to get around the verbosity of some bits of numpy. Regards, Johann -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
Seebs wrote:
I tend to write stuff like
foo.array_of_things.sort.map { block }.join(, )
I like this a lot more than
array = foo.array_of_things
sorted_array = array.sort()
mapped_array = [block(x) for x in sorted_array]
, .join(mapped_array)
If you insist on a one-liner for four separate operations, what's wrong with
this?
, .join([block(x) for x in sorted(foo.array_of_things)])
Or if you prefer map:
, .join(map(block, sorted(foo.array_of_things))
I think I would be less skeptical about fluent interfaces if they were
written more like Unix shell script pipelines instead of using attribute
access notation:
foo.array_of_things | sort | map block | join ,
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
In article mailman.2233.1313179799.1164.python-l...@python.org,
Chris Angelico ros...@gmail.com wrote:
Python uses the + and - symbols to mean addition
and subtraction for good reason. Let's not alienate the mathematical
mind by violating this rule.
Computer programming languages follow math conventions only in the most
vague ways. For example, standard math usage dictates that addition is
commutative. While this is true for adding integers, it's certainly not
true for adding strings (in any language which supports string addition).
Where to draw the line between math and programming languages is not an
easy question.
It would be far safer to go the other way
and demand parentheses on everything.
Demand, no, but sometimes it's a good idea. I've been writing computer
programs for close to 40 years, and I still have no clue what most of
the order of operations is. It's just not worth investing the brain
cells to remember such trivia (especially since the details change from
language to language). Beyond remembering the (apparently) universal
rule that {*, /} bind tighter than {+, -}, I pretty much just punt on
everything else and put in extra parens everywhere.
It's not the most efficient way to write code, and probably doesn't even
result in the prettiest code. But it sure does eliminate those
face-palm moments at the end of a long debugging session when you
realize that somebody got it wrong.
--
http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On Mon, Aug 15, 2011 at 2:41 PM, Roy Smith r...@panix.com wrote:
Demand, no, but sometimes it's a good idea. I've been writing computer
programs for close to 40 years, and I still have no clue what most of
the order of operations is. It's just not worth investing the brain
cells to remember such trivia (especially since the details change from
language to language). Beyond remembering the (apparently) universal
rule that {*, /} bind tighter than {+, -}, I pretty much just punt on
everything else and put in extra parens everywhere.
Understandable. I go the other way, though, and keep an operator
precedence table for each language handy; often, what I'm after is not
which one binds more tightly, but what's the symbol for modulo,
which is also (usually) on that same table. Or: Blasted PHP, which
operators have precedence between || and or? which is easy to forget.
And you're right about the details changing from language to language,
hence the operators table *for each language*. But most languages
follow fairly sane rules, and tend to come up with pretty much the
same ordering.
ChrisA
--
http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
Roy Smith wrote: Computer programming languages follow math conventions only in the most vague ways. For example, standard math usage dictates that addition is commutative. While this is true for adding integers, it's certainly not true for adding strings (in any language which supports string addition). Not quite true for maths either, at least in principle. I'm not aware of any number types where addition is non-commutative, but subtraction is noncommutative even for integers, and noncommutative multiplication is quite common (e.g. matrix multiplication). And of course, once you start using floating point numbers, you can't assume commutativity: 0.1 + 0.7 + 0.3 == 0.3 + 0.7 + 0.1 False I'm reminded of this quote from John Baez: The real numbers are the dependable breadwinner of the family, the complete ordered field we all rely on. The complex numbers are a slightly flashier but still respectable younger brother: not ordered, but algebraically complete. The quaternions, being noncommutative, are the eccentric cousin who is shunned at important family gatherings. But the octonions are the crazy old uncle nobody lets out of the attic: they are nonassociative. (And don't even ask about the sedenions...) -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On Mon, Aug 15, 2011 at 3:28 PM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
And of course, once you start using floating point numbers, you can't assume
commutativity:
0.1 + 0.7 + 0.3 == 0.3 + 0.7 + 0.1
False
This isn't because programming languages fail to follow mathematics;
it's because floating point numbers do not represent real numbers.
Python doesn't support substring removal using the subtraction
operator, but I'd have to say that floats more closely parallel
strings and other high level objects than they do mathematical reals.
If Python treated __sub__(str,str) as str.replace(str,) then:
hello world + asdfqwer - d
hello worlasfqwer
hello world - d + asdfqwer
hello worlasdfqwer
Nobody would expect strings to behave mathematically with subtraction,
because negatives don't make sense. Even sets don't quite work,
although they're closer:
set(asdf)-set(test)
{'a', 'd', 'f'}
There's no way, in a set, to show a negative reference to 't' and 'e'.
In theory you could do this with dictionaries or collections.Counter,
but subtracting a Counter from a Counter doesn't produce negative
numbers either. No, these constructs do not subtract algebraically,
and I do not think it would be any improvement to the language if they
did.
ChrisA
--
http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On 2011-08-15, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote:
Seebs wrote:
I tend to write stuff like
foo.array_of_things.sort.map { block }.join(, )
I like this a lot more than
array = foo.array_of_things
sorted_array = array.sort()
mapped_array = [block(x) for x in sorted_array]
, .join(mapped_array)
If you insist on a one-liner for four separate operations, what's wrong with
this?
, .join([block(x) for x in sorted(foo.array_of_things)])
Nothing in particular; I was just contrasting two styles, not asserting
that Python couldn't do that.
In general, I don't like to do things that either involve making a lot of
variables that are assigned to once and then read from once, or making a
whole lot of x = foo(x) type assignments to one variable. It feels cluttered
to me.
I think I would be less skeptical about fluent interfaces if they were
written more like Unix shell script pipelines instead of using attribute
access notation:
foo.array_of_things | sort | map block | join ,
Interesting! I think that's probably why I find them so comfortable;
shell was one of the first languages I got serious about.
-s
--
Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
--
http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On 2011-08-15, Roy Smith r...@panix.com wrote:
Demand, no, but sometimes it's a good idea. I've been writing computer
programs for close to 40 years, and I still have no clue what most of
the order of operations is. It's just not worth investing the brain
cells to remember such trivia (especially since the details change from
language to language). Beyond remembering the (apparently) universal
rule that {*, /} bind tighter than {+, -}, I pretty much just punt on
everything else and put in extra parens everywhere.
It's not the most efficient way to write code, and probably doesn't even
result in the prettiest code. But it sure does eliminate those
face-palm moments at the end of a long debugging session when you
realize that somebody got it wrong.
Wholehearted agreement. It is conceivable for me to misremember precedence.
I am pretty reliable at recognizing which things are in which parens.
So I use them even in obvious cases:
foo + (3 * 4)
Never regretted that. Yes, it's extra typing, a little, but it prevents a
whole category of bugs.
-s
--
Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
--
http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On Aug 15, 2:31 am, Terry Reedy tjre...@udel.edu wrote: On 8/15/2011 12:28 AM, Seebs wrote: To repeat again: you are free to put in explicit dedent markers that will let you re-indent code should all indents be removed. As Terry has been trying to say for a while now, use the following methods to quell your eye pain. Use pass statement: if foo: if bar: baz else: pass else: quux Use comments: if foo: if bar: baz #else bar (or endif or whatever you like) else: quux Use road signs: :-) # [Warning: Curves Ahead: Eyeball Parse limit 35 WPM!] if foo: # [Exit 266: foo] -- # [Right Curve Ahead: slow eyeball parsing to 15 WPM!] if bar: baz else: pass # -- [Warning: Do not litter!] else: # [Exit 267: Not Foo] -- # [Right Curve Ahead: slow eyeball parsing to 15 WPM!] quux ... # [Eyeball Parse limit 55 WPM!] ... # [PSA: Friends don't let friends write asinine code] ... # [Next Rest Stop: NEVER!] Now you have the nice triangular shape that your eyes have been trained to recognize! I would suggest to use comments whenever possible. Of course there will be times when you cannot use a comment and must use an else clause. Now you have nothing to complain about :). -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
In article mailman.10.1313417818.27778.python-l...@python.org, Chris Angelico ros...@gmail.com wrote: Or: Blasted PHP, which operators have precedence between || and or? which is easy to forget. And you're right about the details changing from language to language, hence the operators table *for each language*. But most languages follow fairly sane rules How dare you use the words PHP and sane in two adjoining paragraphs! -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
In article 4e492d08$0$30003$c3e8da3$54964...@news.astraweb.com, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: I'm reminded of this quote from John Baez: The real numbers are the dependable breadwinner of the family, the complete ordered field we all rely on. The complex numbers are a slightly flashier but still respectable younger brother: not ordered, but algebraically complete. The quaternions, being noncommutative, are the eccentric cousin who is shunned at important family gatherings. But the octonions are the crazy old uncle nobody lets out of the attic: they are nonassociative. Wow, at first glance, I mis-parsed that name as Joan Baez. Had me really confused for a moment. -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On Tue, Aug 16, 2011 at 1:34 AM, Roy Smith r...@panix.com wrote: In article mailman.10.1313417818.27778.python-l...@python.org, Chris Angelico ros...@gmail.com wrote: Or: Blasted PHP, which operators have precedence between || and or? which is easy to forget. And you're right about the details changing from language to language, hence the operators table *for each language*. But most languages follow fairly sane rules How dare you use the words PHP and sane in two adjoining paragraphs! By separating them with the word most. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
Steven D'Aprano wrote: I'm reminded of this quote from John Baez: ...But the octonions are the crazy old uncle nobody lets out of the attic: they are nonassociative. (And don't even ask about the sedenions...) Aren't they the ones that mutilate cattle and abduct people? -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On 2011-08-16, Roy Smith r...@panix.com wrote: In article 4e492d08$0$30003$c3e8da3$54964...@news.astraweb.com, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: I'm reminded of this quote from John Baez: The real numbers are the dependable breadwinner of the family, the complete ordered field we all rely on. The complex numbers are a slightly flashier but still respectable younger brother: not ordered, but algebraically complete. The quaternions, being noncommutative, are the eccentric cousin who is shunned at important family gatherings. But the octonions are the crazy old uncle nobody lets out of the attic: they are nonassociative. Wow, at first glance, I mis-parsed that name as Joan Baez. Had me really confused for a moment. Would it have been that much weirder than Hedy Lamarr? -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
* 2011-08-14T01:44:05-07:00 * Chris Rebert wrote: I've heard that Dylan is supposedly Lisp, sans parens. http://en.wikipedia.org/wiki/Dylan_(programming_language) It has copied/derived many features from Lisps but it's not a dialect of Lisp because of the syntax and its consequences. -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On Aug 15, 11:13 pm, alex23 wuwe...@gmail.com wrote:
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote:
I think I would be less skeptical about fluent interfaces if they were
written more like Unix shell script pipelines instead of using attribute
access notation:
foo.array_of_things | sort | map block | join ,
I've seen at least one attempt to provide this in Python:
If you want 100% OOP then use Ruby:
rb [3,100,-20].sort.join('#')
-20#3#100
Ruby is great from this angle! The reading proceeds naturally from
right to left. I have become accustomed to reading Python's nested
function calls however it does feel much more natural in Ruby. Of
course, there are architectural reasons why Python cannot do this
linear syntactical processing which lends some paradigm-al niceties to
the python programmer that are not available to the Ruby folks.
--
http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
Seebs wrote: I guess... The parser is explicitly pushing those tokens, but I can't *SEE* those tokens. If I am looking at the end of a really long thing, and I see: blah blah I only know what's happening if I have absolute confidence that the indentation is always by the same amount, etectera. I believe this is a dubious argument. With only two lines of code in isolation, understanding the indentation changes is the least of your worries. Adding block delimiters doesn't give you any significant help -- ESPECIALLY if the block delimiters don't align with the indentation! blah } blah } In isolation, you don't even know whether the above is syntactically valid, since you have no way of knowing that either end brace is closing an open brace or not. Who would write such a horrible mis-aligned piece of code? Good question. If you're going to have style-guides that prohibit writing code like the above, then what exactly do the braces give you? Yes, yes, if you paste the code into a web forum the indentation may disappear, and if your hard drive controller is faulty it may randomly overwrite blocks with data belonging to other files. We all agree that environments that destroy data are Bad. Yet another reason to consider brace languages harmful: they spoil the user's intuitive grasp of intuition as grouping. I assume you mean indentation as grouping. Yes, sorry about that. I'm... not sold on this. It's not that I don't see indentation as a kind of grouping. It's just that I really, really, want groups to have ends. Consider the hypothetical array syntax: a = [ 1, 2 b = [ 3, 4 This *bugs* me. It's perfectly legible, and if you define it that way, it's unambiguous and everything, but... It bugs me. I want beginnings to have an actual corresponding end. Do you get worried by books if the last page doesn't include the phrase The End? These days, many movies include an extra clip following the credits. When the clip finishes, and the screen goes dark, how long do you sit waiting before you accept that the movie is over? *wink* The above example bugs me too, because it is too close to what I'm used to in Python. I see an open bracket, I wait for a close bracket. Perhaps this would be better: a = array 1, 2, b = array 3, 4, Not so bad now, I betcha. And you can nest arrays: c = array 5, 6, array 7, 8, 9, Now, I wouldn't actually recommend such a syntax for a programming language. (Maybe for a config file format?) It's too big and awkward for array literals in an expression. You can partly fix that by making the whitespace optional, allowing an array to be written on one line: a = array 1, 2 b = array 3, 4 but that screws up the ability to nest arrays. Also, what happens here? spam(a, b, array 5, 6) That's ambiguous -- does spam have three arguments or four? Again, easy enough to fix: spam(a; b; array 5; 6) # four args but you still can't nest arrays. This potential syntax doesn't feel like a unified whole, but like a bunch of unrelated fixes for problems. Sometimes a literal START and END delimiter is the right answer. Python's use of indentation to delimit blocks doesn't feel like that. Unlike arrays, you can't use blocks in an expression, and I think that's the factor which makes all the difference. Ruby folks may call the lack of block expressions a problem with Python, but even if they're right, I don't think it's a *big* problem. Either way, given the restriction that blocks are statements, not expressions, the lack of an overt block markers is not a problem for code (with the proviso that a rogue editor doesn't go making arbitrary changes to your source code). -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On 2011-08-14, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Seebs wrote: I guess... The parser is explicitly pushing those tokens, but I can't *SEE* those tokens. If I am looking at the end of a really long thing, and I see: blah blah I only know what's happening if I have absolute confidence that the indentation is always by the same amount, etectera. I believe this is a dubious argument. With only two lines of code in isolation, understanding the indentation changes is the least of your worries. Adding block delimiters doesn't give you any significant help -- ESPECIALLY if the block delimiters don't align with the indentation! blah } blah } Interesting. I am sort of getting to an insight into this, which I am not sure I can articulate. FWIW, I've had to debug C (well, C++) much worse than that (... long story, but rest assured, the lulz justified the effort of reading the transcendantly awful code). I could still do it. :) In isolation, you don't even know whether the above is syntactically valid, since you have no way of knowing that either end brace is closing an open brace or not. Ahh, but the computer can tell me that. I don't have to see it. Who would write such a horrible mis-aligned piece of code? Good question. If you're going to have style-guides that prohibit writing code like the above, then what exactly do the braces give you? I think what they give me is... basically a parity bit. It's easy for people to screw up code, such that the code written does not reflect intent. Braces give me a likely red flag -- if they are screwed up, I know that this is a good palce to start looking. If they're not, then all they're costing me is a little vertical space. Yes, yes, if you paste the code into a web forum the indentation may disappear, and if your hard drive controller is faulty it may randomly overwrite blocks with data belonging to other files. We all agree that environments that destroy data are Bad. Destroy data is a sort of fungible concept. I was reading a comic book recently and it contained a URL for a poem which had been parodied. The URL had been hand-lettered... in block capitals. The actual URL had exactly one upper case letter in it. Whoops. In general, I don't think all data-loss is identical in severity. Outside of Python and Makefiles, I don't use anything where whitespace damage of the sort of losing or changing leading spaces is usually significant, so I *normally* regard it as a trivial change. Do you get worried by books if the last page doesn't include the phrase The End? These days, many movies include an extra clip following the credits. When the clip finishes, and the screen goes dark, how long do you sit waiting before you accept that the movie is over? *wink* It's an actual thing I have been bitten by, especially because I often really enjoy those clips, and I've seen a movie that had two. The above example bugs me too, because it is too close to what I'm used to in Python. I see an open bracket, I wait for a close bracket. Perhaps this would be better: a = array 1, 2, b = array 3, 4, Not so bad now, I betcha. Interesting! For me this triggers the same WHERE IS THE END MARKER??? reflex. These bug me like unmatched brackets. but you still can't nest arrays. This potential syntax doesn't feel like a unified whole, but like a bunch of unrelated fixes for problems. Sometimes a literal START and END delimiter is the right answer. I think so. Python's use of indentation to delimit blocks doesn't feel like that. Unlike arrays, you can't use blocks in an expression, and I think that's the factor which makes all the difference. Ruby folks may call the lack of block expressions a problem with Python, but even if they're right, I don't think it's a *big* problem. I actually really *like* that Ruby and Lua let pretty much everything just be an expression. I was utterly dumbfounded when I found out that print in Python is a kind of statement, not a function or something comparable. (This seems to have changed recentlyish.) Either way, given the restriction that blocks are statements, not expressions, the lack of an overt block markers is not a problem for code (with the proviso that a rogue editor doesn't go making arbitrary changes to your source code). Yeah. I suspect that if I'd never used something with braces, I might not mind as much, but the kinds of errors I've had would probably still be issues. Say I try to indent or outdent something and I grab the wrong set of lines. It's certainly possible for this to result in valid code... And I have no cue as to what happened. Even if I get a warning, I can't necessarily tell what happened. To some extent, I think I like braces for the same reason I like to use ECC memory whenever hardware supports it, and
Re: allow line break at operators
On Sun, Aug 14, 2011 at 8:10 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Do you get worried by books if the last page doesn't include the phrase The End? These days, many movies include an extra clip following the credits. When the clip finishes, and the screen goes dark, how long do you sit waiting before you accept that the movie is over? *wink* You wait for the house lights to come up. That's your ending signal. As is often said in live theatre: House lights, warmers, thank you gentlemen, going off cans! It still has an end marker. On Sun, Aug 14, 2011 at 9:07 AM, Seebs usenet-nos...@seebs.net wrote: I actually really *like* that Ruby and Lua let pretty much everything just be an expression. I was utterly dumbfounded when I found out that print in Python is a kind of statement, not a function or something comparable. (This seems to have changed recentlyish.) Yes. Not everything's an expression; a block of code is not an expression that returns a code object, and variable assignment is a statement. Some day, I'd like to play around with a language where everything's an expression and yet it doesn't look like LISP - just for the fun of it. It probably won't be any more useful for real world coding, but it'd be fun to tinker with. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On Sun, Aug 14, 2011 at 1:34 AM, Chris Angelico ros...@gmail.com wrote: snip Yes. Not everything's an expression; a block of code is not an expression that returns a code object, and variable assignment is a statement. Some day, I'd like to play around with a language where everything's an expression and yet it doesn't look like LISP - just for the fun of it. It probably won't be any more useful for real world coding, but it'd be fun to tinker with. I've heard that Dylan is supposedly Lisp, sans parens. http://en.wikipedia.org/wiki/Dylan_(programming_language) Cheers, Chris -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
Seebs usenet-nos...@seebs.net writes: I was utterly dumbfounded when I found out that print in Python is a kind of statement, not a function or something comparable. (This seems to have changed recentlyish.) It has long been recognised as a wart, but it required waiting for an opportunity for breaking backward compatibility (the Python 2 → 3 transition) to fix it. If you can't yet switch to Python 3, you can explicitly ask for ‘print’ as a function in Python 2.6 or later. More at URL:http://wiki.python.org/moin/PrintAsFunction. -- \ “The generation of random numbers is too important to be left | `\to chance.” —Robert R. Coveyou | _o__) | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
Chris Angelico ros...@gmail.com writes: On Sun, Aug 14, 2011 at 8:10 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Do you get worried by books if the last page doesn't include the phrase The End? These days, many movies include an extra clip following the credits. When the clip finishes, and the screen goes dark, how long do you sit waiting before you accept that the movie is over? You wait for the house lights to come up. That's your ending signal. You mean people still watch movies in theatres? The house lights need to be controlled by someone who knows when the movie's end signal should be sent. What is our ending signal if we're watching it from media in our home, and no-one in the house knows when the movie ends? -- \ “The best way to get information on Usenet is not to ask a | `\ question, but to post the wrong information.” —Aahz | _o__) | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
* 2011-08-14T09:34:26+01:00 * Chris Angelico wrote: Some day, I'd like to play around with a language where everything's an expression and yet it doesn't look like LISP - just for the fun of it. It probably won't be any more useful for real world coding, but it'd be fun to tinker with. Of course it's a useful feature. Basically you can put any Lisp code in the world in the place of a Lisp expression. (setf variable (handler-case (some-code) (foo-error () value 1) (bar-error () value 2))) is something like variable = try: return some_code() except FooError: return value 1 except BarError: return value 2 Sure, it's not a necessary feature. All we need is the machine language, but other than that there are differences in how languages let programmers express themselves. The above example emphasizes that 'variable' is being assigned. The how part gets less weight. If we put the assignment inside the handler-case or try-except forms we get the same result technically but the variable assignment becomes more hidden and is repeated, possibly several times. I understand that Python philosophy does not value freedom of expression that much. It values a general Pythonic rule which must obeyed and is called readability. Other languages give too little or too much freedom. :-) -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
Ben Finney wrote: Chris Angelico ros...@gmail.com writes: On Sun, Aug 14, 2011 at 8:10 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Do you get worried by books if the last page doesn't include the phrase The End? These days, many movies include an extra clip following the credits. When the clip finishes, and the screen goes dark, how long do you sit waiting before you accept that the movie is over? You wait for the house lights to come up. That's your ending signal. You mean people still watch movies in theatres? Yup! Not often, but it's fun once in a while. The house lights need to be controlled by someone who knows when the movie's end signal should be sent. What is our ending signal if we're watching it from media in our home, and no-one in the house knows when the movie ends? If it's a tape, it'll stop, or start rewinding; if it's a DVD it'll go back to the open page. :) ~Ethan~ -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
Seebs wrote:
Destroy data is a sort of fungible concept. I was reading a comic book
recently and it contained a URL for a poem which had been parodied. The
URL had been hand-lettered... in block capitals. The actual URL had
exactly one upper case letter in it.
Whoops.
Er, most URLs are case insensitive, at least the most common ones, including
HTTP and HTTPS. So I don't quite see why you think this was a Whoops.
In general, I don't think all data-loss is identical in severity. Outside
of Python and Makefiles, I don't use anything where whitespace damage of
the sort of losing or changing leading spaces is usually significant,
so I *normally* regard it as a trivial change.
Ys, nd n rdnry nglsh txt, th lss ar chng af vwls cn olsu b e trvl chng.
But try that with your source code :)
I actually really *like* that Ruby and Lua let pretty much everything just
be an expression. I was utterly dumbfounded when I found out that print
in Python is a kind of statement, not a function or something comparable.
(This seems to have changed recentlyish.)
Yes, print as a statement was a mistake. But assignment as a statement, not
so much. Assignment as an expression in languages that have it tends to be
associated with frequent errors.
The way I see it, if something operates by side-effect, then it has no
business being treated as an expression. I'm not even happy with the usual
convention of Python functions that return None, such as list.sort() -- in
my opinion, languages should have procedures which don't return anything,
and can only be used as a statement, similar to Pascal procedures.
(I'm prepared to make an exception for purely functional languages.)
Say I try to indent or outdent something and I grab the wrong set of
lines. It's certainly possible for this to result in valid code... And I
have no
cue as to what happened. Even if I get a warning, I can't necessarily
tell what happened.
Then don't do that.
I'm not impressed by arguments based on but if I do something stupid, like
select text with my eyes closed and reindent it without looking, I expect
the compiler to save my bacon. In my opinion, it's not the compiler's job
to protect you from errors caused by sheer carelessness at the keyboard.
In any case, while reindenting an arbitrary set of lines may *possibly*
result in valid code that runs but does the wrong thing, the likelihood of
that happening is remote enough that I'm not going to lose any sleep over
it. There are real-world scenarios involving such semantic errors involving
indentation, but they're pretty rare. I think that six weeks of not having
to type { } or BEGIN END around code blocks has saved far more time and
effort than such errors have cost me in my entire history of Python
programming.
Refactoring C or Ruby is easy for me. Refactoring Python is hard for me.
I really do rely on visible markers to sanity-check the boundaries of what
I'm indenting or outdenting. If I do something in my editor and end up
with:
foo.each do |bar|
bar.do_a_thing
do_something_with(bar)
end
next_thing
something else
I know immediately that it's wrong.
How? What makes you so certain that next_thing and something else are
supposed to be inside the loop? They don't even refer to bar. Even if they
did, it's not a foolproof sign, although it is a good hint.
Unless I understand the intent of the code, how can I tell whether the END
token is in the right place or not? And if I understand the intent of the
code, then the END token is redundant.
If I do something in my editor and end up with:
if foo:
bar.do_a_thing
do_something_with(bar)
next_thing
something else
I can't immediately see that I hit the wrong number key when telling
the editor how many lines to adjust.
Typos happen. I rely heavily on things that let me catch them in as many
ways as possible.
I call that a poor user interface design. If you have to count the number of
lines before applying an edit, instead of selecting a range of text, then
you should stop using a tool that is stuck with a UI from the early 1980s.
Please don't take this as an insult, because it is not meant as one, but it
seems to me from this discussion that you're a more careless coder than I
am[1], and you want more insurance to protect you from your own mistakes.
Braces give you that insurance.
I'm not saying I've never mis-indented a block of code, surely I must have.
But if I did, it was so trivial to fix, and done so rarely, I've forgotten
all about it. Consequently I don't want to pay the cost of that insurance,
as little as it is, because I don't get the benefit of it -- for me, it's
just redundant information that I have to type and read that provides no
real benefit.
And that's why I love Python, because it doesn't make my pay for insurance I
don't need.
[1] For some definition of careless.
--
Steven
--
Re: allow line break at operators
On Sun, Aug 14, 2011 at 3:26 PM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
Yes, print as a statement was a mistake. But assignment as a statement, not
so much. Assignment as an expression in languages that have it tends to be
associated with frequent errors.
The way I see it, if something operates by side-effect, then it has no
business being treated as an expression.
Wikipedia (that well-known authority) lists among examples of side
effects both write data to a display or file and modify one of its
arguments.
This strongly implies that print() is a function that operates by
side-effect, just as the assignment operator (in languages in which it
is one) does. Treating a=5 as an expression with the value 5 is no
more relying on side effects than having print('asdf') an expression
with the value None.
I believe that print-as-a-function is a Good Thing, mainly because it
can be used as an argument to such as map. Somewhat silly/trivial
example:
msgs=[Hello,World]
list(map(print,msgs))
I'm aware that assignment-as-an-expression has plenty of risks
associated with it (the main one being the classic C issue of
assignment inside a conditional - a feature that I use frequently
myself, but which trips plenty of people up), which is a strong
argument for its remaining a statement, but side effects isn't on its
own.
ChrisA
--
http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
In article 4e47db26$0$30002$c3e8da3$54964...@news.astraweb.com, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Er, most URLs are case insensitive, at least the most common ones, including HTTP and HTTPS. So I don't quite see why you think this was a Whoops. URLs are most certainly not case insensitive. Parts of them may be (i.e. the scheme and host parts), but not the stuff after the hostname. -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
Chris Angelico wrote: On Sun, Aug 14, 2011 at 3:26 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Yes, print as a statement was a mistake. But assignment as a statement, not so much. Assignment as an expression in languages that have it tends to be associated with frequent errors. The way I see it, if something operates by side-effect, then it has no business being treated as an expression. Wikipedia (that well-known authority) lists among examples of side effects both write data to a display or file and modify one of its arguments. [...] Good point. I withdraw my statement about things that operate about side-effects. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On 2011-08-14, Chris Angelico ros...@gmail.com wrote: Yes. Not everything's an expression; a block of code is not an expression that returns a code object, and variable assignment is a statement. Some day, I'd like to play around with a language where everything's an expression and yet it doesn't look like LISP - just for the fun of it. It probably won't be any more useful for real world coding, but it'd be fun to tinker with. Ruby and Lua are both pretty close. I'm not an expert in either, but I can't think of anything I can write in Ruby which isn't an expression. -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On 2011-08-14, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Seebs wrote: Destroy data is a sort of fungible concept. I was reading a comic book recently and it contained a URL for a poem which had been parodied. The URL had been hand-lettered... in block capitals. The actual URL had exactly one upper case letter in it. Er, most URLs are case insensitive, at least the most common ones, including HTTP and HTTPS. So I don't quite see why you think this was a Whoops. Sort of. Host names are case insensitive, so far as I can tell always. Paths past that are distinctly NOT always case insensitive, and since the server in question happened to be doing what appear to be straight path lookups, it mattered a great deal that you had to downcase all but one of the letters. (The obvious technique of downcasing them all failed.) Ys, nd n rdnry nglsh txt, th lss ar chng af vwls cn olsu b e trvl chng. But try that with your source code :) Eh, I'm a C programmer, what makes you think I had any vowels to begin with? Yes, print as a statement was a mistake. But assignment as a statement, not so much. Assignment as an expression in languages that have it tends to be associated with frequent errors. It does. I'm not sure whether the errors are compensated for by the expressiveness. I *think* on the whole they are, but I am honestly not sure. I do like gcc's warning for assignment used as a truth value. The way I see it, if something operates by side-effect, then it has no business being treated as an expression. Interesting! I tend to really like the ability to chain methods, depending on context. I find the side-effect/expression mix pretty normal, so I'm used to it. Say I try to indent or outdent something and I grab the wrong set of lines. It's certainly possible for this to result in valid code... And I have no cue as to what happened. Even if I get a warning, I can't necessarily tell what happened. Then don't do that. If not doing that were a realistic option for me, I'm guessing I'd have stopped making typos thirty years ago. I'm not impressed by arguments based on but if I do something stupid, like select text with my eyes closed and reindent it without looking, I expect the compiler to save my bacon. In my opinion, it's not the compiler's job to protect you from errors caused by sheer carelessness at the keyboard. I don't know about sheer carelessness. Typos happen. Typos are not something you can prevent from happening just by wanting it very much. In any case, while reindenting an arbitrary set of lines may *possibly* result in valid code that runs but does the wrong thing, the likelihood of that happening is remote enough that I'm not going to lose any sleep over it. Ahh, but what about the case where it results in invalid code? It's not necessarily obvious which lines need to be moved after that. foo.each do |bar| bar.do_a_thing do_something_with(bar) end next_thing something else I know immediately that it's wrong. How? The end is misaligned. Therefore SOMETHING is wrong. I don't know what, but I can be confident that something went wrong. Unless I understand the intent of the code, how can I tell whether the END token is in the right place or not? And if I understand the intent of the code, then the END token is redundant. The question is not whether it's on the right line. No amount of indenting or outdenting can ever break that. The question is whether I've gotten the indentation screwed up. If I do something in my editor and end up with: if foo: bar.do_a_thing do_something_with(bar) next_thing something else I can't immediately see that I hit the wrong number key when telling the editor how many lines to adjust. Typos happen. I rely heavily on things that let me catch them in as many ways as possible. I call that a poor user interface design. If you have to count the number of lines before applying an edit, instead of selecting a range of text, then you should stop using a tool that is stuck with a UI from the early 1980s. You keep telling me to stop using this editor. I have not seen a suggested improvement. (Hint: GUI editors are not an improvement for my purposes, as I do about 99.5% of my editing on machines that aren't in the same state that I am. No, the GUI editor cannot offer enough improvement in anything to justify the cost of copying files back and forth constantly.) Please don't take this as an insult, because it is not meant as one, but it seems to me from this discussion that you're a more careless coder than I am[1], and you want more insurance to protect you from your own mistakes. Braces give you that insurance. I have really, really, bad ADHD. When I was a kid a firecracker blew up in my hand because I *forgot* I was holding it. I'm not exactly careless in the pejorative sense (I don't accept the
Re: allow line break at operators
On 2011-08-14, Teemu Likonen tliko...@iki.fi wrote:
I understand that Python philosophy does not value freedom of expression
that much. It values a general Pythonic rule which must obeyed and is
called readability. Other languages give too little or too much
freedom. :-)
There is an interesting tradeoff, there, because I tend to find stuff
like variable = {fancy if expression} to be much *more* readable, since
I immediately get the top-level information (we're assigning variable)
and then I can look for details if I care.
-s
--
Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
--
http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On Sun, Aug 14, 2011 at 10:27 AM, Ben Finney ben+pyt...@benfinney.id.au wrote: The house lights need to be controlled by someone who knows when the movie's end signal should be sent. What is our ending signal if we're watching it from media in our home, and no-one in the house knows when the movie ends? If you're watching it from your own media, you'll come to the end of the file/DVD/whatever and VLC will know. End-of-file is a well-known condition with well-defined semantics. :) And in the theatre, there's a definition of the end based on the origin of the material (the stage manager's script/music score, or something). Yep, there's always an end marker somewhere. But we are now hopelessly off topic, I think! ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Re: allow line break at operators
On 01/-10/-28163 02:59 PM, Roy Smith wrote: In article4e47db26$0$30002$c3e8da3$54964...@news.astraweb.com, Steven D'Apranosteve+comp.lang.pyt...@pearwood.info wrote: Er, most URLs are case insensitive, at least the most common ones, including HTTP and HTTPS. So I don't quite see why you think this was a Whoops. URLs are most certainly not case insensitive. Parts of them may be (i.e. the scheme and host parts), but not the stuff after the hostname. The thing that confuses people is that not only is the part up to and through the domain name is case-insensitive, but that simple pages on Windows become case-insensitive for the remainder simply because Windows is such. And the same page hosted on Linux would be case sensitive, per specification. The thing I find annoying is a host that decides that if a URL is close to an existing URL, it'll fix one or two typos. To me, it's either right, or it's not. Don't change www.mydomain.com/page105.html to www/mydomain.com/page102.html and pretend it's close enough. DaveA -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
In article mailman.2285.1313358379.1164.python-l...@python.org, Dave Angel da...@ieee.org wrote: URLs are most certainly not case insensitive. Parts of them may be (i.e. the scheme and host parts), but not the stuff after the hostname. The thing that confuses people is that not only is the part up to and through the domain name is case-insensitive, but that simple pages on Windows become case-insensitive for the remainder simply because Windows is such. Sure. But it's only in the most trivial of situations that URLs map in any trivial way to file names. And the same page hosted on Linux would be case sensitive, per specification. Well, I certainly could write an HTTP server on Linux which treated routes in a case-insensitive way. For example, if I do a GET on http://en.wikipedia.org/wiki/hypertext, I get redirected to http://en.wikipedia.org/wiki/Hypertext. On the other hand, http://en.wikipedia.org/WIKI/Hypertext gets me a 404. It's entirely up to the server to do whatever makes sense for that application. The thing I find annoying is a host that decides that if a URL is close to an existing URL, it'll fix one or two typos. To me, it's either right, or it's not. Don't change www.mydomain.com/page105.html to www/mydomain.com/page102.html and pretend it's close enough. Hosts don't decide anything. Applications running on those hosts decide things. Without knowing the application, it's impossible to say if this is the right thing to do or not. For example, it's good practice that if a URL ever worked in the past, you should keep that URL working, even if it becomes obsolete. You might want to silently return some other page, or redirect the user to some other URL. This keeps bookmarks, existing links, cached search results, etc, from going stale. To use the wikipedia example again, there are lots of redirect entries, for other (perhaps incorrect) spellings, and so forth. For example, http://en.wikipedia.org/w/index.php?title=Tabouleredirect=no -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On Sun, Aug 14, 2011 at 11:46 PM, Roy Smith r...@panix.com wrote: In article mailman.2285.1313358379.1164.python-l...@python.org, Dave Angel da...@ieee.org wrote: The thing that confuses people is that not only is the part up to and through the domain name is case-insensitive, but that simple pages on Windows become case-insensitive for the remainder simply because Windows is such. Sure. But it's only in the most trivial of situations that URLs map in any trivial way to file names. And even then, it plays havoc with caches (both browser and proxy), which have no way of knowing that http://blah.com/Foo.html and http://blah.com/foo.html are the same document. (It's not hard to set up a Windows system to be case sensitive with URLs, or (even easier - at least with Apache) to have any request with uppercase letters to instantly redirect to the lower-cased version.) URLs are definitely case sensitive; any server that ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
Seebs wrote: On 2011-08-14, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: The way I see it, if something operates by side-effect, then it has no business being treated as an expression. Which I later withdrew. Interesting! I tend to really like the ability to chain methods, depending on context. I find the side-effect/expression mix pretty normal, so I'm used to it. As a rule, chaining method calls risks violating the Law of Demeter. Just sayin'. Say I try to indent or outdent something and I grab the wrong set of lines. It's certainly possible for this to result in valid code... And I have no cue as to what happened. Even if I get a warning, I can't necessarily tell what happened. Then don't do that. If not doing that were a realistic option for me, I'm guessing I'd have stopped making typos thirty years ago. I feel your pain. But not all typos are equivalent. There are typos in the content of the document you are editing, and command typos. There's nothing an editor can do to prevent the first -- how is the editor supposed to know that you meant referrer rather than referer? And because it didn't, now we're stuck with a %*$%@! spelling error forever. But a good editor can minimise command typos. User interfaces matter. If your car required you to reach over your left shoulder and pull a lever in order to slow down, it would be a really bad design. It would join these interfaces: http://www.asktog.com/columns/027InterfacesThatKill.html http://www.useit.com/alertbox/20050411.html If your editor doesn't help you minimise bad commands, then your editor doesn't work for you, it works against you. I'm not impressed by arguments based on but if I do something stupid, like select text with my eyes closed and reindent it without looking, I expect the compiler to save my bacon. In my opinion, it's not the compiler's job to protect you from errors caused by sheer carelessness at the keyboard. I don't know about sheer carelessness. Typos happen. Typos are not something you can prevent from happening just by wanting it very much. I sympathise, but don't care. That's your problem man, not Python's. Python has a design philosophy that doesn't match your needs precisely. Oh well, no language can be all things to all people. If you try, you get Perl, and you still fail, because your language doesn't meet the needs of people looking for something that isn't Perl *wink* I hope you can still be productive in Python, and it's not like anyone *wants* you to stop using Python and use another language, but you have to understand that Python wasn't designed for *your* needs precisely. That doesn't make indentation as syntax a bad choice. In any case, while reindenting an arbitrary set of lines may *possibly* result in valid code that runs but does the wrong thing, the likelihood of that happening is remote enough that I'm not going to lose any sleep over it. Ahh, but what about the case where it results in invalid code? It's not necessarily obvious which lines need to be moved after that. Are you talking about code you've moved from somewhere else and need to reindent? Then if the code was working before, it will keep working if you have the same relative indentation. (At least indentation-wise. It may break due to other factors.) Revert your bad reindent and try again, more carefully this time. If you're making semantic changes to the code, not just a simple move, then surely you understand what changes you're making and not just randomly indenting and dedenting until it complies? Read the code and decide how to fix it. I get it that sometimes there will be code which is hard to follow and hard to edit. But if that's the case, you've got more maintenance problems than indentation, and indents are the least of your problems. foo.each do |bar| bar.do_a_thing do_something_with(bar) end next_thing something else I know immediately that it's wrong. How? The end is misaligned. Therefore SOMETHING is wrong. I don't know what, but I can be confident that something went wrong. Okay, now I'm confused... if indentation doesn't matter, how is the end misaligned? You could write this, and it would still work the same, yes? foo.each do |bar| bar.do_a_thing do_something_with(bar) end next_thing something else Unless I understand the intent of the code, how can I tell whether the END token is in the right place or not? And if I understand the intent of the code, then the END token is redundant. The question is not whether it's on the right line. No amount of indenting or outdenting can ever break that. The question is whether I've gotten the indentation screwed up. But if indentation doesn't matter, you can't screw it up. Isn't that the whole point of this discussion? [...] You keep telling me to stop using this editor. I have not seen a
Re: allow line break at operators
On Sun, Aug 14, 2011 at 6:54 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Seebs wrote: snip Interesting! I tend to really like the ability to chain methods, depending on context. I find the side-effect/expression mix pretty normal, so I'm used to it. As a rule, chaining method calls risks violating the Law of Demeter. Just sayin'. Not in the specific case of fluent interfaces[1] though, which could have been what Seebach had in mind. Whether fluent interfaces are a good idea... Cheers, Chris -- [1] http://en.wikipedia.org/wiki/Fluent_interface -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On 2011-08-15, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Interesting! I tend to really like the ability to chain methods, depending on context. I find the side-effect/expression mix pretty normal, so I'm used to it. As a rule, chaining method calls risks violating the Law of Demeter. Just sayin'. Risks violating isn't the same thing as violates. But a good editor can minimise command typos. User interfaces matter. If your car required you to reach over your left shoulder and pull a lever in order to slow down, it would be a really bad design. It would join these interfaces: Yeah. If your editor doesn't help you minimise bad commands, then your editor doesn't work for you, it works against you. Life is full of tradeoffs. The editor does a lot of things which very much improve my performance, with costs which are usually pretty easily mitigated. I don't know about sheer carelessness. Typos happen. Typos are not something you can prevent from happening just by wanting it very much. I sympathise, but don't care. That's your problem man, not Python's. Debatable. There's a sort of fuzzy boundary between clearly this is a defect in the product (see interfaces that kill), and clearly this is a defect in the user. In fact, one of the major areas of interesting UI research involves interfaces that accommodate things which are generally regarded as defects in the user. Think about colorblindness. Obviously, it's the user's problem, not the editor's, but an editor which picks colors which most colorblind people can't distinguish for something important is going to get castigated for it. I hope you can still be productive in Python, and it's not like anyone *wants* you to stop using Python and use another language, but you have to understand that Python wasn't designed for *your* needs precisely. That doesn't make indentation as syntax a bad choice. I think it depends a lot on the goals. So far as I can tell, the primary goal of the policy was to eliminate a class of errors. It... well, it does this in a strictly technical sense, in that every error which occurs is no longer of that class. It does not seem to me that it's done very much to turn the kinds of things which used to result in that class of errors into non-errors; rather, it's turned them into different errors. Are you talking about code you've moved from somewhere else and need to reindent? Then if the code was working before, it will keep working if you have the same relative indentation. (At least indentation-wise. It may break due to other factors.) Revert your bad reindent and try again, more carefully this time. The point is... I can't *TELL* what the boundaries of the bad-reindent are. Because there's no unambiguous point at which I can say oh, look, here is the line where the indentation starts being wrong, unless there's a syntax error... and even then, the syntax error might be before or after the actual bounds of the bad indent. With properly-braced code in a brace language, any mis-indent you do can be unambiguously identified -- you have a 100% guarantee that you know what the first and last misindented lines are. In Python, you can usually guess within a couple of the lines, more easily if you're familiar with the code. If you're making semantic changes to the code, not just a simple move, then surely you understand what changes you're making and not just randomly indenting and dedenting until it complies? Read the code and decide how to fix it. The case that has historically bitten me is that I move N lines of code, and then I try to adjust the indentation of those N lines, and... SOMETHING happens. Maybe someone somewhere introduced tabs and adding four leading spaces doesn't do anything. Maybe I mis-counted N. I get it that sometimes there will be code which is hard to follow and hard to edit. But if that's the case, you've got more maintenance problems than indentation, and indents are the least of your problems. Not if the only reason that it's hard to follow is that the indentation is screwed up. The end is misaligned. Therefore SOMETHING is wrong. I don't know what, but I can be confident that something went wrong. Okay, now I'm confused... if indentation doesn't matter, how is the end misaligned? Indentation doesn't affect the *compiler*, but we know the rules for indentation. It's a parity bit. If the indentation and the begin/end don't agree, then I *know something is wrong*. And I know on exactly which line it becomes wrong. That turns out to save me a fair bit of time if I have to look at code and try to figure out what's wrong. The question is not whether it's on the right line. No amount of indenting or outdenting can ever break that. The question is whether I've gotten the indentation screwed up. But if indentation doesn't matter, you can't screw it up. Isn't that the whole point of this discussion? I think there is some
Re: allow line break at operators
On 2011-08-15, Chris Rebert c...@rebertia.com wrote:
On Sun, Aug 14, 2011 at 6:54 PM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
As a rule, chaining method calls risks violating the Law of Demeter. Just
sayin'.
Not in the specific case of fluent interfaces[1] though, which could
have been what Seebach had in mind.
They're the most obvious example, from my point of view.
I tend to write stuff like
foo.array_of_things.sort.map { block }.join(, )
I like this a lot more than
array = foo.array_of_things
sorted_array = array.sort()
mapped_array = [block(x) for x in sorted_array]
, .join(mapped_array)
(I am still not used to Python's attachment of join to strings rather
than to arrays. I don't really object to it, it's just not how I think
about join operations.)
-s
--
Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
--
http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: The only exception I can think of is *very* early Fortran, and that rightly is considered a mistake. Fortran 77 used to treat whitespace as always optional, so that in Python terms this: forxinrange(42) would be parsed as this: for x in range(42) Absolutely true, and that led to one of the more famous computing screw-ups in the early space program. The author intended to write this: DO 10 I=1,8 which, in Fortran, begins a loop that will run 8 times ending at the statement labeled 10. In this case, the author mistakenly typed a period instead of a comma: DO 10 I=1.8 That, unfortunately, is a perfectly valid statement that assigns the value 1.8 to the floating point variable DO10I, supposedly resulting in the loss of an unmanned launch vehicle... -- Tim Roberts, t...@probo.com Providenza Boekelheide, Inc. -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On Aug 12, 5:03 pm, Steven D'Aprano steve
+comp.lang.pyt...@pearwood.info wrote:
Responding to Rick's standard {EDIT} posts
is like wrestling with a {EDIT}
[...]
Save yourself a lot of aggravation and kill-file him now.
Kindly allow Walter E. Kurtz to shine some light on this situation:
Pig after pig, cow after cow, village after village, army after
army. And they call me an assassin. What do you call it when the
assassins accuse the assassin? They lie.. they lie and we have to be
merciful for those who lie. Those nabobs. I hate them. How I hate
them...
--
http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On Aug 12, 7:39 pm, Seebs usenet-nos...@seebs.net wrote: Well, that's the thing. In a case like: if foo: if bar: blah blah I notice that *NOTHING* lines up with if bar:. And that affects me about the way unmatched brackets do. For me, i believe it was a grave mistake to allow user defined indention within a python module. Not only that, but allowing indentation to be inconsistent (within the same module) not only worse, it's insane! I could have slightly understood giving people a choice of how many indents to use however i cannot fathom the idiocy of allowing inconsistent indentation within the same module! Although GvR is no doubt a brilliant mind he keeps making the same mistakes over and over again in the name of muti-stylism. ¡Ay, caramba! Not that i find it *impossible* to read inconsistent indentation mind you, but that i find it blasphemous to the name of consistency. Programming languages MUST be consistent. Python should allow one and only one obvious way to indent a block; whether it be by a single tab char or by four spaces i don't care! But for crikey's sake pick one of them and stick with it!!! -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On Aug 12, 7:39 pm, Seebs usenet-nos...@seebs.net wrote: I was overjoyed when I saw that Ruby would let me write 1_048_576. I'll have to admit that Ruby has a few very interesting ideas, this being one of them. We all know how impossible it can be to eyeball parse a very long number like this. Having the interpretor ignore underscores in a number was very wise indeed! However i really hate the fact that Ruby FORCES you to use OOP. I LOVE OOP, however there are times when you just don't need that level of machinery to solve a problem. A good example is when scripting an API. Most times all you need is a few module level procedures and some simple logic. Try that with Ruby, then try that with Python, you'll be switching to Python in no time! PS: And before any Matz lovers start complaining: Yes, i know you can do procedural programming with ruby HOWEVER it suffers many pitfall due to (1) Ruby's scoping issues and (2) Ruby's explicit module declaration (which is more indirect than the first). -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On Aug 12, 7:39 pm, Seebs usenet-nos...@seebs.net wrote: Consider the hypothetical array syntax: a = [ 1, 2 b = [ 3, 4 This *bugs* me. It's perfectly legible, and if you define it that way, it's unambiguous and everything, but... It bugs me. I want beginnings to have an actual corresponding end. It almost seems as if you have a valid point here until you consider that conditionals and blocks are ridged structures that must be defined under a strict set of syntactical rules with keywords and indentation. Whereas the list, dict, set, and tuple absolutely MUST have an explicit beginning AND an explicit end due to their free-form nature. You could create some strict rules for defining X-literals and remove any need for start and end tags however i see no need to do so. -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On Aug 12, 4:06 pm, Seebs usenet-nos...@seebs.net wrote: On 2011-08-12, Chris Angelico ros...@gmail.com wrote: Why is left-to-right inherently more logical than multiplication-before-addition? I'd say it's certainly more Pythonic in a vacuum. Multiplication-before-addition, and all the related rules, require you to know a lot of special rules which are not visible in the code, and many of which have no real logical basis. Left-to-right is, if nothing else, the way the majority of us read. The problem is that since everyone's used precedence before, not using it violates the principle of least astonishment. And repeatedly propagating a foolish consistency is well, FOOLISH! This problem invades every aspect of technology. Who was the idiot that decided it was okay to close SOME html tag and NOT close others? Since HTML is made to be read by machines why the hell would someone knowingly induce disorder? Which then leads to needing more logic to parse? But even more insane is why HTML has been allowed to be so disorderly for so long. Where is the need to be consistent? I tell you how to solve this, you solve it with plagues. Plagues of syntax errors will teach the unrighteous the err of their ways. -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
Before I get to the rest of this: Thinking it through, I've been unreasonable and grumpy here, and I'm trying to figure this out a bit more. A general observation: There's no real data here, so far as I can tell. There is no pair of languages which are exactly identical except for whether they use whitespace or some kind of brace/bracket/thing to indicate blocks, such that we can compare results between them. Humans are *notoriously* unreliable at evaluating the ease with which they do things, how long it takes them, how many mistakes they're making, and so on... So really, this is probably in large part a matter of taste or preference. On 2011-08-11, Ethan Furman et...@stoneleaf.us wrote: The times that whitespace indentation has bitten me, it was still not difficult to fix -- I just had to look and see which line(s) should/should not be where they were. I've been thinking about this, and I just plain can't understand how this could, in general, be done. Given a bunch of lines of code with no indication of where the blocks were supposed to be, I can't figure how this could be fixed in a way that is not-difficult, at least in general. Not so. If the braces do not match /intent/ (which is the problem I care most about) then it cannot be fixed by machine. Question for y'all: Has anyone here ever ACTUALLY encountered a case where braces -- not indentation -- did not match intent in a C-like language? I'm talking only about cases where braces are *actually present*. I haven't. Now, I've only been using C for maybe 20-25 years, but in all that time, I have never, ever, not *once*, seen braces not match intent. I've seen indentation errors galore. I've seen nutjobs writing }}} on a line all by itself. I've seen people forget to add braces and do stuff like: else a(); b(); ... but I've never, ever, seen braces not match intent. It just hasn't ever happened in code I've seen. people who'd picked Python for some stuff I have to work for, point out the hostility of the Python community to newcomers whose workflows don't happen to have been preemptively built entirely around Python's design decisions, and suggest that maybe we use another language. Heck, since I've been encouraged so much to do so, I think I will. Your choice, obviously -- seems a shame to me, though, to give up on Python because of one or two ouchy areas on c.l.py. By and large it's a very helpful and courteous community. I was thinking about this more, and I think the issue that's historically bugged me is this: Most of the people I know and talk to about programming languages regard preferences as a matter of personal taste. I've seen people say that they prefer the significant-indentation thing, and I've seen people say they dislike it. The Python community, as a whole, seems particularly dogmatic about the indentation thing. And coming here as someone who doesn't much like it, and has been bitten by it a few times... Imagine that I were taking care of a cat for the first time, and I came to a cat-owners newsgroup, and found the following: 1. Nearly everyone there hated dogs, utterly. 2. The people who hated dogs were snide and insulting about people who didn't hate dogs. ... oookay, then. So I post my question, about a cat peeing on a bed, and I get the following responses: 1. What kind of idiot are you to continue using a broken non-waterproof matress? You should be using a solid vinyl cover over your mattress to prevent it from geting cat pee. 2. Once you've had a cat for a while you'll find that overall cat pee is superior to a dry mattress. ... At this point, I'm not exactly going to feel like a welcome member of the community. :) Now, that analogy is a little extreme, perhaps, but... Programmers get attached to their editors. And having a bunch of people insist that it's crazy of me to use an editor which has worked perfectly for me in the other ten programming languages I use, with settings that are not merely tolerable but *mandatory* for at least one of them, is... well, it doesn't create the impression that people who don't happen to already have fallen in love with an editor that coexists well with the whitespace thing are welcome. And part of this really is personal taste. I *LIKE* having a matching outdent for everything. I like to look at code and see blah blah blah blah blah because then I know it's balanced. If one of them is missing, *something is wrong*. And I have to keep that instinct to stay functional in most of the other languages I know. I don't have the option of ceasing to use C, but if I used C and didn't watch for missing close-braces, I'd be pretty badly hosed. So I have this strong incentive to prefer an explicit thing that I can see. And in any event, I *do* prefer it. In other language communities, when I find things about the language
Re: allow line break at operators
On Fri, Aug 12, 2011 at 2:40 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Please be careful about conflating significant indentation with significant whitespace. Many languages have significant whitespace: foo bar is rarely the same thing as foobar but is the same as foo bar Python is no different. Of course. But most languages derived from C have a single lexer token whitespace. That one token is significant, but these are all the same: foo bar foo bar foo bar foo/* this one wasn't originally the same*/bar Python handles differently source files that differ only in whitespace. It's not only indentation; newlines are whitespace too, and they're significant. In C-derived languages, it's only presence-or-absence. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On Fri, Aug 12, 2011 at 7:34 AM, Seebs usenet-nos...@seebs.net wrote: If Python with braces wouldn't be Python at all, why on earth does the language even exist? Every language has its philosophy. Python, as conceived by Guido van Rossum, is a language which (guys, correct me where I'm wrong please!): * Eschews unnecessary syntactic salt * Has batteries included * Has a clean and readable syntax To achieve this, Python: * Uses indentation and other whitespace as structural elements (rather than semicolons, braces, etc) * Has a large standard library and an enormous PyPI collection * Uses keywords (and, or, not, if/else) rather than symbols (, |, !, ?:) for common tasks Etcetera. These are the philosophical decisions made by GvR and the Python community, and these define Python's syntax. If you go against these, you could make something that compiles down to Python's byte code; in fact, I'd say you could make something that produces a .pyc file and then hands it to the regular Python interpreter for execution. Is it Python? No, no more than NetREXX is Java just because it can make a .class file. It's a different language. Pike is very similar to Python in underlying structure. You can pass lists and dictionaries (called arrays and mappings) around as first-class objects, you can reference objects in multiple places, you can work with huge integers comfortably. But they're different in philosophy. Pike's purpose is primarily zero-downtime servers; I can (and do on a daily basis) update parts of the code of a running program, without disconnecting clients. Python doesn't do this, and to make Python do this would violate a lot of its simplicities and underlying referencings. It can be done without modifying the interpreter, but it's never been designed in. If you want that feature, you go to Pike; if you want Python's syntax, you go to Python. I hope I make myself clear, Josephine? ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
Seebs usenet-nos...@seebs.net writes: On 2011-08-11, Ben Finney ben+pyt...@benfinney.id.au wrote: You're welcome to attempt to demonstrate the superiority of some other Python-with-braces, but it will (a) be un-Pythonic, and (b) be unlikely to gain the efforts of people who don't think what you're addressing is a problem. I am pretty sure Python is a pretty nice language. However, the indentation thing has screwed me a few times. Furthermore, I know people who like Python a great deal and acknowledge, without much difficulty, that the indentation thing has caused problems or incompatibilities for them. Yes. It's caused problems for me too, so I'm not going to deny that. This is different from saying “indentation as block structure” is a problem; that statement is what I disagree with, and what I think most respondents who disagree with you are objecting to. So when I see people deny that it is at all a problem, or that there are any possible shortcomings to it, I infer that they have some compelling reason to deny the existence of a thing which is reliably and easily observed. I don't see anyone making the denials you're referring to there. If I did, you would have my support in considering those denials mistaken. Likewise, “end of line as end of statement” has caused me and many others problems. I'd go so far as to say that any Python programmer for whom that's not true has not done any significant Python programming. That doesn't make “end of line as end of statement” a problem. If a language feature is beneficial in far greater proportion to the inconveniences of that feature, I'd say that feature *is not a problem* for users of that language. In Python, I maintain that's the case for “end of line as end of statement”, and for “indentation as block structure”. -- \ “A computer once beat me at chess, but it was no match for me | `\ at kick boxing.” —Emo Philips | _o__) | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
:The trouble of dealing with long lines can be avoided by a smart :editor. It's called line wrap. Yeah, usually they just wrap it pretty arbitrarily, and you don't have any control, isn't it? :umm... besides notepad pretty much any other serious programmer editor :program try to do its best to deal with line wrap: the minimal I found is :the wrapped line is indented at the same level of the flow, but I found :editors where you can specify what to do (generally something like indent :the wrapped part 2 levels or something like that) Thanks for sharing that, which I am not quite aware of . BTW, do you think things like eclipse, emacs and vim also has such kind of functionality? Best of all, would certainly like to have IDLE have it, as I am teaching Python and would like to get them to start with a simple environment. Yingjie -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
From: Vito 'ZeD' De Tullio zak.mc.kra...@libero.it :umm... besides notepad pretty much any other serious programmer editor :program try to do its best to deal with line wrap: the minimal I found is :the wrapped line is indented at the same level of the flow, but I found :editors where you can specify what to do (generally something like indent :the wrapped part 2 levels or something like that) Well, even if one editor can do perfect line wrapping, breaking the line at places perfectly pleasing to the eye (put aside the fact that sometimes the line breaking could be based on the meaning of the code), it is unlikely to be cross-editor consistent. Yingjie -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
Seebs usenet-nos...@seebs.net writes: Question for y'all: Has anyone here ever ACTUALLY encountered a case where braces -- not indentation -- did not match intent in a C-like language? I'm talking only about cases where braces are *actually present*. What a strange limitation. Why are you not comparing apples with apples? The correct comparison would be “getting the braces to match the intended structure” compared with “getting the indentation to match the intended structure”. The Python community, as a whole, seems particularly dogmatic about the indentation thing. And coming here as someone who doesn't much like it, and has been bitten by it a few times... As you say, the data is thin on the ground for this issue. Would you accept the charge that you're being just as dogmatic about the superiority of braces-as-block-syntax? If so, good for you; we're all equally dogmatic by your definition. Let's move on. If not, what makes your position less dogmatic than ours? -- \ “We jealously reserve the right to be mistaken in our view of | `\ what exists, given that theories often change under pressure | _o__) from further investigation.” —Thomas W. Clark, 2009 | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
Ben Finney wrote: Likewise, “end of line as end of statement” has caused me and many others problems. I don't understand this. Can you give an example? Do you mean, Sometimes I want more code in a single statement than will comfortably fit in a single line? -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info writes: Ben Finney wrote: Likewise, “end of line as end of statement” has caused me and many others problems. I don't understand this. Can you give an example? Many times I have split a line expecting that some bracketing syntax will cause the statement to continue across the split. I've been wrong, and the code either gave a SyntaxError or, worse, did something functional but unintended. That is a problem only because end-of-line (outside some bracketing syntax) ends a statement. My point is that I consider that problem to be at least on par in the severity of the problems caused by indentation-as-block-syntax. That is, very small compared with the great benefit of the clean and readable syntax that results. -- \ “Not to be absolutely certain is, I think, one of the essential | `\ things in rationality.” —Bertrand Russell | _o__) | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On 2011-08-12, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Chris Angelico wrote: Incidentally, I will happily argue the benefits of Python's significant whitespace, even though I disagree with it; there are quite a few. Please be careful about conflating significant indentation with significant whitespace. Many languages have significant whitespace: foo bar is rarely the same thing as foobar but is the same as foo bar Python is no different. The only exception I can think of is *very* early Fortran, and that rightly is considered a mistake. Early versions of Basic were like this, too. It was common to compress large C64 Basic programs by removing the spaces and substituting the command synonyms. -- Neil Cerutti -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
Am 12.08.2011 03:40 schrieb Steven D'Aprano: The only exception I can think of is *very* early Fortran, and that rightly is considered a mistake. ATARI 800XL. Built-in BASIC, acknowledging every command with READY. Going over it with the cursor results in ERROR- 6, meaning no READ without DATA... same as READ Y. Thomas, it was a long time ago... -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On Aug 12, 1:34 am, Seebs usenet-nos...@seebs.net wrote: And part of this really is personal taste. I *LIKE* having a matching outdent for everything. I like to look at code and see blah blah blah blah blah because then I know it's balanced. If one of them is missing, *something is wrong*. What is with you guys and this need to have your hand held to read code. Out-dents are noise and nothing more. When you're driving on a two lane highway that becomes one lane, would you forget to merge (OUTDENT) simply because the merge sign was missing? If you did then i would say you need to keep your eyes on the road (CODE) instead of looking for signs on the side of the road. In other words; you need to start acting like an intelligent agent instead of a zombie. In other language communities, when I find things about the language troublesome, I usually find people offering suggestions for ways to improve things, or workarounds, or acknowledging that, yes, that can be annoying. But for some reason, in this one, that's apparently against a local taboo. So instead of acknowledging that it is conceivably possible for people to prefer different things, people say things like oh, once you've done it a bit you'll realize how much better it is and then you'll love it. Condescending, smug, and, at least so far, *totally untrue* for me. Well for indention there is no alternatives. There is either indent/ dendent, or suffer the syntax error. I am also weirded out by the claim that a Python which used braces would no longer be Python in any way, shape, or form. If you were to make a C derivative which used indentation instead of braces (this should be trivial to do with a preprocessor), I can't imagine C programmers claiming it's not C. Of course it's C; it has the C type system, the C operators, the C promotion rules, C linkage and scope and so on... That's C. It's just a C variant which tweaks the punctuation. Hmm, Python's exclusive use of indent/dedent for denoting blocks is rather unique in a world of braces (barring a few other less known languages). Removing that feature and replacing it with braces (or tags or whatever) would change the language significantly! Likewise allowing a directive like use braces = True would also be detrimental to our code bases. A language must always strive to remove ambiguities and multiplicity. Having more than one way to mark blocks is insanity. You never want to induce more overhead than necessary because such things are detrimental to work flow and language evolution. If Python with braces wouldn't be Python at all, why on earth does the language even exist? If all you want is indentation-which-matters, it's super easy to write a preprocessor for ANY language to do that, and you could have every last positive feature, benefit, or valuable trait of Python by doing that to any other language. This statement leads me to believe you have very little experience with the Python language. Python has many wonderful attributes and design philosophies. Significant indentation is just ONE of many. Unless, of course, there are *other* things that are significant about Python. In which case, a language which preserved all of those, but used braces, would still be a kind of Python after all. I don't understand this need for braces. You yearn so badly to be dominated by them. Is this a psychological disorder, a Helsinki syndrome that you cannot shake? There is life after braces my friend, and the future is bright! Long story short: I think the dismissiveness and hostility I've seen from people in the Python community towards people who, for *whatever* reason, find the indentation-flow-control thing annoying, is not really helping the Python community win converts. As much as we love people getting on board we are not about to sacrifice our strong beliefs in clean source code just so you and other hardwired C programmers will come along. Indentation is at the very heart of Pythons philosophy. A philosophy that breaks free from decades old language design build on the detrimental ideals of multi- stylism. Good languages do not care about your singularly instinctual emotion needs for bondage, no, they care about productivity and readability from a community perspective. PS: I will admit that a few of our community members can be rather acerbic at times. -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On Aug 12, 2:20 am, Chris Angelico ros...@gmail.com wrote: Pike is very [snip] Pike's purpose is [snip] you go to Pike[snip] I hope I make myself clear, Josephine? The only thing that is clear to me is that you have a hidden agenda to incorporate pike's functionality into Python -- and this is not the first time! Chris, this incessant babbling about pike this and pike that is starting to get on my nerves. Why don't you go over to comp.lang.pike and gush to them about how wonderful the language is. PS: Although i give you brownie point for sucking up to GvR and the community at large before hinting about Esox lucius greatness. Nice! -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On Fri, Aug 12, 2011 at 3:39 AM, Ben Finney ben+pyt...@benfinney.id.au wrote: Seebs usenet-nos...@seebs.net writes: Question for y'all: Has anyone here ever ACTUALLY encountered a case where braces -- not indentation -- did not match intent in a C-like language? I'm talking only about cases where braces are *actually present*. What a strange limitation. Why are you not comparing apples with apples? The correct comparison would be “getting the braces to match the intended structure” compared with “getting the indentation to match the intended structure”. One argument I've heard from braces fans is that sometimes they want their own structure, which does not match the actual block structure. Example: FILE* f = fopen(...); // do stuff with f // at this indent level fclose(f); // back to normal But really this is just working around other limitations in the language (i.e. lack of a with-statement equivalent). Cheers, Chris -- http://rebertia.com -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On 2011-08-12, Ben Finney ben+pyt...@benfinney.id.au wrote: Seebs usenet-nos...@seebs.net writes: I am pretty sure Python is a pretty nice language. However, the indentation thing has screwed me a few times. Furthermore, I know people who like Python a great deal and acknowledge, without much difficulty, that the indentation thing has caused problems or incompatibilities for them. Yes. It's caused problems for me too, so I'm not going to deny that. This is different from saying ???indentation as block structure??? is a problem; that statement is what I disagree with, and what I think most respondents who disagree with you are objecting to. See below; I think I agree with what I meant by it, and disagree with what you seem to interpret it as. Your interpretation makes as much sense as mine, so far as I can tell. I don't see anyone making the denials you're referring to there. If I did, you would have my support in considering those denials mistaken. I suspect, thinking about it more, that it's a communications problem. Likewise, ???end of line as end of statement??? has caused me and many others problems. I'd go so far as to say that any Python programmer for whom that's not true has not done any significant Python programming. That doesn't make ???end of line as end of statement??? a problem. True, although it does make it a thing which *has* at least one problem. If a language feature is beneficial in far greater proportion to the inconveniences of that feature, I'd say that feature *is not a problem* for users of that language. I wouldn't. Lemme give a concrete example, from C, since that's the language I know best. There are sound technical reasons for which C lets you manipulate pointers. If you couldn't, it wouldn't be C, and you couldn't do the bulk of the stuff that makes C useful. But... Pointer manipulation leads to crashes. LOTS of crashes. I have never met a C programmer with over a day or two of experience who has not had a program crash due to some mishap involving a pointer. When people say that a language like, say, Java, is trying to solve the problems of C's pointer system, I think that's a reasonable thing to try to do. There are tradeoffs. But it would be, IMHO, silly to claim that there are no problems with pointers; there are just benefits which outweigh them *for the things the language is trying to do*. -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On 2011-08-12, Ben Finney ben+pyt...@benfinney.id.au wrote: Seebs usenet-nos...@seebs.net writes: Question for y'all: Has anyone here ever ACTUALLY encountered a case where braces -- not indentation -- did not match intent in a C-like language? I'm talking only about cases where braces are *actually present*. What a strange limitation. Why are you not comparing apples with apples? I am trying to. I'm trying to compare C-like languages, with braces, to Python, with indentation. The correct comparison would be ???getting the braces to match the intended structure??? compared with ???getting the indentation to match the intended structure???. Right. I have seen Python programs in which indentation, while it obviously matched what actually happened, did not match intent. It is (at least in principle) easier to debug because you can see that, but... I've seen people in C do stuff like: for (i = 0; i N; ++i); a[i] = 0; This is clearly a case where indentation matches intent, but doesn't match functionality, because C allows indentation to not-match functionality; this is the famous problem Python is solving. However, I've never, ever, seen a problem like that *when people were using braces*. An apples-to-apples comparison between indentation and braces should be a comparison *to braces*, not to people who cleverly omit braces. (If you are looking for a debate on whether C's optional-braces are a good idea, I'm afraid you will have to look elsewhere; if it were up to me, I would totally approve a language change making them mandatory.) As you say, the data is thin on the ground for this issue. Would you accept the charge that you're being just as dogmatic about the superiority of braces-as-block-syntax? I don't think so. If not, what makes your position less dogmatic than ours? A couple of things. 1. I do assert that people who are happy with an editor and have been using it for twenty years ought to change their editor to accommodate a language which uses braces. 2. I will happily grant that braces, written legibly, cost you an extra line per block, and that this space cost can make it harder to see all the code at once. 3. I don't have a problem agreeing that there certainly appear to be people for whom the Python syntax is easier to read. I think #1 is the real point at which I think there's a dogmatism problem. Maybe editors shouldn't helpfully convert spaces to tabs, but that feature has been nearly entirely beneficial to me in everything else I've edited for a long time, and I don't *want* to learn a new editor just for one language. -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On 2011-08-12, Chris Angelico ros...@gmail.com wrote: On Fri, Aug 12, 2011 at 7:34 AM, Seebs usenet-nos...@seebs.net wrote: If Python with braces wouldn't be Python at all, why on earth does the language even exist? Every language has its philosophy. Yes. Etcetera. These are the philosophical decisions made by GvR and the Python community, and these define Python's syntax. If you go against these, you could make something that compiles down to Python's byte code; in fact, I'd say you could make something that produces a .pyc file and then hands it to the regular Python interpreter for execution. Is it Python? No, no more than NetREXX is Java just because it can make a .class file. It's a different language. I would argue that any pure syntactic-sugar change which can be done entirely by a naive preprocessor does not constitute a significant shift in the language itself. -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On 2011-08-12, rantingrick rantingr...@gmail.com wrote: What is with you guys and this need to have your hand held to read code. Good question! Great to see that the helpful and welcoming community is living up to its reputation. My brain has quirks. Some people call them defects, some don't, but it really doesn't matter; there are things about which my brain is just plain unreliable and I rely moderately heavily on extra visual cues to reduce the frequency with which I get things wrong when skimming. Out-dents are noise and nothing more. Not for me. When you're driving on a two lane highway that becomes one lane, would you forget to merge (OUTDENT) simply because the merge sign was missing? No, because the *LANE BOUNDARIES* would move. If you did then i would say you need to keep your eyes on the road (CODE) instead of looking for signs on the side of the road. In other words; you need to start acting like an intelligent agent instead of a zombie. Interesting theory. I propose we extend it to expression processing in general. Instead of writing a = (x + y) * z let's just write a = (x + y * z It's obvious that no one would have needed to introduce parentheses here unless they wanted to bind the + more closely than the *, so the ) is just noise and not needed. Hmm, Python's exclusive use of indent/dedent for denoting blocks is rather unique in a world of braces (barring a few other less known languages). Removing that feature and replacing it with braces (or tags or whatever) would change the language significantly! It would, but unless that's the only distinctive trait of the language, I don't think it would make the language cease to be Python. Likewise allowing a directive like use braces = True would also be detrimental to our code bases. A language must always strive to remove ambiguities and multiplicity. Having more than one way to mark blocks is insanity. You never want to induce more overhead than necessary because such things are detrimental to work flow and language evolution. Agreed. This statement leads me to believe you have very little experience with the Python language. Python has many wonderful attributes and design philosophies. Significant indentation is just ONE of many. It was a reductio-ad-absurdum. I don't understand this need for braces. You yearn so badly to be dominated by them. Is this a psychological disorder, a Helsinki syndrome that you cannot shake? There is life after braces my friend, and the future is bright! Man, you really love pushing them buttons, don't you? You don't understand a thing. Therefore... there is no such thing, anyone who experiences life differently from you needs to be insulted? As much as we love people getting on board we are not about to sacrifice our strong beliefs in clean source code just so you and other hardwired C programmers will come along. But you will happily insult people and call them names in order to keep them from having anything to listen to? PS: I will admit that a few of our community members can be rather acerbic at times. Yeah. And the thing is... This can't possibly lead to convincing people of your position, so presumably the purpose is that you don't want anyone who didn't start out agreeing with you to ever come to agree with you? Why's that? -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On Aug 12, 11:33 am, Seebs usenet-nos...@seebs.net wrote: My brain has quirks. Some people call them defects, some don't, but it really doesn't matter; there are things about which my brain is just plain unreliable and I rely moderately heavily on extra visual cues to reduce the frequency with which I get things wrong when skimming. I think that really boils down to you refusing to open your eyes up to new ways of doing things. You are clutching the past and it is taking you down with it. Pry your lips from Ritchie's left teet and stop slurping that brace milk; because it is polluting your mind! When you're driving on a two lane highway that becomes one lane, would you forget to merge (OUTDENT) simply because the merge sign was missing? No, because the *LANE BOUNDARIES* would move. The lane boundaries will also move whilst reading code that uses the indent/dedent paradigm. Are you honestly telling me that you will skip over a four spaced dedent without seeing it however you can easily spot a single closing brace and instantly know which corresponding opener brace to which it referrers without looking, and counting, and wasting time? Sorry, i just don't believe you. I propose we extend it to expression processing in general. Instead of writing a = (x + y) * z let's just write a = (x + y * z I'm glad you brought this up! How about this instead: a = x + y * z ...where the calculation is NOT subject to operator precedence? I always hated using parenthesis in mathematical calculations. All math should resolve in a linear fashion. 3+3*2 should always be 12 and NOT 9! It's obvious that no one would have needed to introduce parentheses here unless they wanted to bind the + more closely than the *, so the ) is just noise and not needed. I would even go as far to use a special set of brackets for linear calculations before using only one, or playing the precedence game. As much as we love people getting on board we are not about to sacrifice our strong beliefs in clean source code just so you and other hardwired C programmers will come along. But you will happily insult people and call them names in order to keep them from having anything to listen to? I am not trying to discredit you simply by disagreeing with you. I have offered facts as to why significant indention is far superior to braces and yet you continue to use the same emotionally charged babble in your defense. When you offer some real facts then i will give then just consideration, until then i will try to enlighten you of the merits of significant indentation. -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On 2011-08-12, Chris Rebert c...@rebertia.com wrote:
One argument I've heard from braces fans is that sometimes they want
their own structure, which does not match the actual block structure.
EWW!
Example:
FILE* f = fopen(...);
// do stuff with f
// at this indent level
fclose(f);
// back to normal
But really this is just working around other limitations in the
language (i.e. lack of a with-statement equivalent).
That's horrid.
FWIW, the C idiom is:
{
FILE *f = ...
...
fclose(f);
}
It isn't used all that widely, but it is a lot less horrible than
random indenting would be.
-s
--
Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
--
http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On Fri, Aug 12, 2011 at 4:33 PM, rantingrick rantingr...@gmail.com wrote: On Aug 12, 2:20 am, Chris Angelico ros...@gmail.com wrote: Pike is very [snip] Pike's purpose is [snip] you go to Pike[snip] I hope I make myself clear, Josephine? The only thing that is clear to me is that you have a hidden agenda to incorporate pike's functionality into Python -- and this is not the first time! Chris, this incessant babbling about pike this and pike that is starting to get on my nerves. Why don't you go over to comp.lang.pike and gush to them about how wonderful the language is. Yeah, it's something I've mentioned a few times. I think people have mentioned C on this list a few times, too; also lisp. Of course, since this is the Python mailing list (or newsgroup, depending where you read it), we aren't allowed to mention any other languages at all. Mea culpa. I'm not seeking to add Pike's functionality into Python. I want the two languages to be different, and I want the world to have different languages. Diversity and choice promote quality in ways that you don't seem to understand. Chris Angelico -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On Fri, Aug 12, 2011 at 5:33 PM, Seebs usenet-nos...@seebs.net wrote: I've seen people in C do stuff like: for (i = 0; i N; ++i); a[i] = 0; This is clearly a case where indentation matches intent, but doesn't match functionality, because C allows indentation to not-match functionality; this is the famous problem Python is solving. There's several solutions to this. One is linting utilities that detect unexpectedly-indented code, which is the concept that Python took to the logical extent of syntactic errors. Another is (again linting) to disallow a direct trailing semicolon; if you want an empty body, you put whitespace before the semicolon. But that wasn't your point, I realise :) ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On Fri, Aug 12, 2011 at 6:57 PM, rantingrick rantingr...@gmail.com wrote: I'm glad you brought this up! How about this instead: a = x + y * z ...where the calculation is NOT subject to operator precedence? I always hated using parenthesis in mathematical calculations. All math should resolve in a linear fashion. 3+3*2 should always be 12 and NOT 9! Why is left-to-right inherently more logical than multiplication-before-addition? Why is it more logical than right-to-left? And why is changing people's expectations more logical than fulfilling them? Python uses the + and - symbols to mean addition and subtraction for good reason. Let's not alienate the mathematical mind by violating this rule. It would be far safer to go the other way and demand parentheses on everything. Incidentally, in the original expression, it would be slightly more sane to write it as: a = x + y) * z borrowing from the musical concept that a repeat sign with no corresponding begin-repeat means to repeat from the beginning. But both of these violate XKCD 859. -- http://mail.python.org/mailman/listinfo/python-list
