allow line break at operators
Yingjie Lan
When writing a long expresion, one usually would like to break it into multiple lines. Currently, you may use a '\' to do so, but it looks a little awkward (more like machine-oriented thing). Therefore I start wondering why not allow line breaking at an operator, which is the standard way of breaking a long expression in publication? Here is an example:
#the old way
x = 1+2+3+4+\
1+2+3+4
#the new way
x = 1+2+3+4+ #line continues as it is clearly unfinished
1+2+3+4
Of course, the dot operator is also included, which may facilitate method chaining:
x = svg.append( 'circle' ).
r(2).cx(1).xy(1).
foreground('black').bkground('white')
Thoughts?
Yingjie
Chris Rebert
> Hi all,
>
> When writing a long expresion, one usually would like to break it into multiple lines. Currently, you may use a '\' to do so, but it looks a little awkward (more like machine-oriented thing). Therefore I start wondering why not allow line breaking at an operator, which is the standard way of breaking a long expression in publication? Here is an example:
>
> #the old way
>
> x = 1+2+3+4+\
> 1+2+3+4
>
> #the new way
> x = 1+2+3+4+ #line continues as it is clearly unfinished
>
> 1+2+3+4
# the currently allowed way
x = (1+2+3+4+
1+2+3+4)
# note the parentheses
I think this is sufficient.
> Of course, the dot operator is also included, which may facilitate method chaining:
>
> x = svg.append( 'circle' ).
> r(2).cx(1).xy(1).
> foreground('black').bkground('white')
Python does not particularly endorse method chaining; it's why
list.sort(), list.append(), and similar methods of built-in types
return None rather than self.
Also, I dislike this for the dot operator especially, as it can
obscure whether a method call or a function call is taking place.
Cheers,
Chris
--
http://rebertia.com
Yingjie Lan
> Hi all,
>
> When writing a long expresion, one usually would like to break it into multiple lines. Currently, you may use a '\' to do so, but it looks a little awkward (more like machine-oriented thing). Therefore I start wondering why not allow line breaking at an operator, which is the standard way of breaking a long expression in publication? Here is an example:
>
> #the old way
>
> x = 1+2+3+4+\
> 1+2+3+4
>
> #the new way
> x = 1+2+3+4+ #line continues as it is clearly unfinished
>
> 1+2+3+4
:# the currently allowed way
:x = (1+2+3+4+
: 1+2+3+4)
:# note the parentheses
:
:I think this is sufficient.
That works, but not in the most natural way--the way people are customed to...why require a pair of parenthis when we can do without them? Also, the new way does not affect the old ways of doing things at all, it is fully backward compatible. So this just offers a new choice.
> Of course, the dot operator is also included, which may facilitate method chaining:
>
> x = svg.append( 'circle' ).
> r(2).cx(1).xy(1).
> foreground('black').bkground('white')
:Also, I dislike this for the dot operator especially, as it can
:obscure whether a method call or a function call is taking place.
Again, this only offers a new choice, and does not force anybody to do it this way.
cheers,
Yingjie
Steven D'Aprano
> :# the currently allowed way
> :x = (1+2+3+4+
> :1+2+3+4)
> :# note the parentheses
> :
> :I think this is sufficient.
>
> That works, but not in the most natural way--the way people are customed
> to...why require a pair of parenthis when we can do without them?
Because it is better to be explicit that the line is still open. An opening
parenthesis or bracket that hasn't been closed is an explicit sign that the
line is still open. An operator is not.
> Also,
> the new way does not affect the old ways of doing things at all, it is
> fully backward compatible. So this just offers a new choice.
You say that as if having more choices is always good. It isn't. More
choices means more for people to learn, more complicated parser, more
options to consider, and more likelihood that errors will fail to raise
SyntaxError and instead go on to silently do the wrong thing. A new choice
should only be accepted when there is a clear and obvious benefit, not
merely because it will provide more choice.
Python is a programming language, not an ice cream shop.
>> Of course, the dot operator is also included, which may facilitate method
>> chaining:
>>
>> x = svg.append( 'circle' ).
>> r(2).cx(1).xy(1).
>> foreground('black').bkground('white')
If you are chaining six dots like that, you are in gross violation of the
Law Of Demeter. That is poor code, and should be discouraged, not
encouraged.
>
> :Also, I dislike this for the dot operator especially, as it can
> :obscure whether a method call or a function call is taking place.
>
> Again, this only offers a new choice, and does not force anybody to do it
> this way.
But it does force people to read it, because some people will use it, and so
others will have to suffer for their poor judgement.
--
Steven
Chris Angelico
<steve+comp....@pearwood.info> wrote:
>>> Of course, the dot operator is also included, which may facilitate method
>>> chaining:
>>>
>>> x = svg.append( 'circle' ).
>>> r(2).cx(1).xy(1).
>>> foreground('black').bkground('white')
>
> If you are chaining six dots like that, you are in gross violation of the
> Law Of Demeter. That is poor code, and should be discouraged, not
> encouraged.
I would only accept that this is poor code IF there is a viable
alternative, such as:
x = svg.append(circle(r=2,cx=1,xy=1,foreground='black',bkground='white'))
This would, imho, be a more Pythonic way to do it. But if this isn't
available, and if the methods already return self, then I see nothing
wrong with chaining. It's a handy way of getting additional mileage
out of lambdas and list comps when writing one-liners. :)
(Cue long thread about whether or not one-liners are Pythonic.)
Chris Angelico
Dan Sommers
> Python is a programming language, not an ice cream shop.
+1 QOTW
How about a cheese shop?
In terms of easier to read, I find code easier to read when the operators
are at the beginnings of the lines (PEP 8 notwithstanding):
x = (someobject.somemethod(object3, thing)
+ longfunctionname(object2)
+ otherfunction(value1, value2, value3))
I can see the "+" signs a lot easier there than at the end of some line,
where it might be buried between two longer lines:
x = (someobject.somemethod(object3, thing) +
longfunctionname(object2) +
otherfunction(value1, value2, value3))
--
Dan
Chris Angelico
> In terms of easier to read, I find code easier to read when the operators
> are at the beginnings of the lines (PEP 8 notwithstanding):
>
> x = (someobject.somemethod(object3, thing)
> + longfunctionname(object2)
> + otherfunction(value1, value2, value3))
>
Without the parentheses, this is legal but (probably) useless; it
applies the unary + operator to the return value of those functions.
Putting the + at the end of the previous line at least prevents that,
since most unary operators bind to the operand on the right; but
there's still the potential for ambiguity.
When line breaks are significant, they cannot be randomly inserted
inside expressions.
ChrisA
TheSaint
> #the new way
> x = 1+2+3+4+ #line continues as it is clearly unfinished
>
> 1+2+3+4
>
Genrally I prefer this way.
> Of course, the dot operator is also included, which may facilitate method
> chaining:
>
> x = svg.append( 'circle' ).
Dot-ended is to tiny thing that might cause oversights. *If* it'll be used
as a secondary option I think it doesn't matter, otherwise *if* use as a
compulsory writing mode I'd say it is pretty mistake prone.
Duncan Booth
> On Wed, Aug 10, 2011 at 10:56 AM, Dan Sommers <d...@tombstonezero.net>
> wrote:
>> In terms of easier to read, I find code easier to read when the
>> operators are at the beginnings of the lines (PEP 8 notwithstanding):
>>
>> x = (someobject.somemethod(object3, thing)
>> + longfunctionname(object2)
>> + otherfunction(value1, value2, value3))
>>
>
> Without the parentheses, this is legal but (probably) useless; it
> applies the unary + operator to the return value of those functions.
No, in some other languages it might be legal, but this is Python.
without the parentheses it is a syntax error.
--
Duncan Booth http://kupuguy.blogspot.com
Chris Angelico
It would be parsed as three separate statements. The only reason it
would be a syntax error would be because of the indentation, which is
not what I'd call reliable; it happens to catch this case, because
assignment doesn't allow subsequent lines to be indented, but nothing
forces continuation lines to be indented.
x = (5
+4)
x = 5
+4
What we have is a strangeness that can arise when a programmer ignores
something that is often insignificant; spare parentheses usually don't
matter.
Another potential danger is the similarity with tuple creation:
x = (someobject.somemethod(object3, thing)
+ longfunctionname(object2)
+ otherfunction(value1, value2, value3),)
This is a tuple with one element. Not too bad with the + operator, but
imagine if everything's done with method chaining on . which results
in the , being nearly indistinguishable. Not an insurmountable
problem, but a potential risk.
ChrisA
Yingjie Lan
> wrote:
>> In terms of easier to read, I find code easier to read when the
>> operators are at the beginnings of the lines (PEP 8 notwithstanding):
>>
>> x = (someobject.somemethod(object3, thing)
>> + longfunctionname(object2)
>> + otherfunction(value1, value2, value3))
>>
>
> Without the parentheses, this is legal but (probably) useless; it
> applies the unary + operator to the return value of those functions.
:No, in some other languages it might be legal, but this is Python.
:without the parentheses it is a syntax error.
This discussion leads me to this question:
Is it possible for python to allow free splitting of single-line statements
without the backslashes, if we impose that expressions can only be split
when it is not yet a finished expression? Note: splitting before closing
parenthis, brace, or bracket can be viewed as special case of this
more general rule.
Yingjie
Steven D'Aprano
> On Wed, Aug 10, 2011 at 10:56 AM, Dan Sommers <d...@tombstonezero.net>
> wrote:
>> In terms of easier to read, I find code easier to read when the operators
>> are at the beginnings of the lines (PEP 8 notwithstanding):
>>
>> x = (someobject.somemethod(object3, thing)
>> + longfunctionname(object2)
>> + otherfunction(value1, value2, value3))
>>
>
> Without the parentheses, this is legal but (probably) useless; it
> applies the unary + operator to the return value of those functions.
> Putting the + at the end of the previous line at least prevents that,
> since most unary operators bind to the operand on the right;
Not so:
>>> x = (42 + -
... 100)
>>>
>>> x
-58
--
Steven
Steven D'Aprano
> In terms of easier to read, I find code easier to read when the operators
> are at the beginnings of the lines (PEP 8 notwithstanding):
>
> x = (someobject.somemethod(object3, thing)
> + longfunctionname(object2)
> + otherfunction(value1, value2, value3))
Agreed.
--
Steven
Chris Angelico
> Is it possible for python to allow free splitting of single-line statements
> without the backslashes, if we impose that expressions can only be split
> when it is not yet a finished expression?
The trouble is that in a lot of cases, the next statement after an
unfinished expression could conceivably be a continuation of it. If
this were permitted, it would have to also require that the
continuation lines be indented, to avoid the problem described above.
It'd still have the potential to mis-diagnose errors, though.
ChrisA
Chris Angelico
<steve+comp....@pearwood.info> wrote:
>> Without the parentheses, this is legal but (probably) useless; it
>> applies the unary + operator to the return value of those functions.
>> Putting the + at the end of the previous line at least prevents that,
>> since most unary operators bind to the operand on the right;
>
> Not so:
>
>>>> x = (42 + -
> ... 100)
>>>>
>>>> x
> -58
Your unary - is binding to the operand to its right, in this case the
100. (I think I have left and right correct; being in theatre has a
tendency to make you forget which is which.) Your + is binary,
operating on 42 and the result of applying unary - to 100, which is
-100.
My point about binding can be illustrated by inventing an operator @.
Let's say that a@b is the atan2 of a and b, and x@ is x factorial (I
can't imagine what deranged mind would do something like this, apart
from my own).
y = 5 @ # 120, as per factorial
x = 5 @ 2 # 1.19 or so, as per atan2
foo(123) # Calls foo() and discards its return value
z = 5 @
foo(123)
Is that last example one statement or two?
But this situation shouldn't ever occur in Python, because all its
unary operators (not, -, +, ~) bind to the operand to their right (I
don't think there's any I've missed, are there?). It does mean,
however, that a leading operator is not unambiguous. Without the
surrounding parentheses and/or otherwise-unexpected indentation, an
expression beginning with a + could conceivably be applying the unary
plus operator to the rest of the expression, rather than implying that
it's continuing the previous line.
Chris Angelico
Ian Kelly
<steve+comp....@pearwood.info> wrote:
>> Without the parentheses, this is legal but (probably) useless; it
>> applies the unary + operator to the return value of those functions.
>> Putting the + at the end of the previous line at least prevents that,
>> since most unary operators bind to the operand on the right;
>
> Not so:
>
>>>> x = (42 + -
> ... 100)
>>>>
>>>> x
> -58
That is still binding to the operand on the "right" (i.e., the
sequentially later). And it still does not cause the problem that
Chris was talking about, since without the parentheses that would be a
syntax error. So I guess I'm not certain what exactly it is that
you're trying to demonstrate here.
Yingjie Lan
>> operators are at the beginnings of the lines (PEP 8 notwithstanding):
>>
>> x = (someobject.somemethod(object3, thing)
>> + longfunctionname(object2)
>> + otherfunction(value1, value2, value3))
>>
>
> Without the parentheses, this is legal but (probably) useless; it
> applies the unary + operator to the return value of those functions.
If ';' are employed (required), truely free line-splitting should be OK,
the operators may appear at the beginnings of the lines as you wish.
Yingjie
Chris Angelico
> If ';' are employed (required), truely free line-splitting should be OK,
>
And if we require {} then truly free indentation should be OK too! But
it wouldn't be Python any more.
ChrisA
Seebs
> And if we require {} then truly free indentation should be OK too! But
> it wouldn't be Python any more.
Would it really not be Python at all?
I've seen bits of code in preprocessing-based "Python with {}" type things,
and they still look like Python to me, only they favor explicit over
implicit a little more strongly.
-s
--
Copyright 2011, all wrongs reversed. Peter Seebach / usenet...@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.
Ben Finney
> On 2011-08-10, Chris Angelico <ros...@gmail.com> wrote:
> > And if we require {} then truly free indentation should be OK too!
> > But it wouldn't be Python any more.
>
> Would it really not be Python at all?
See the Python interpreter's response to ‘from __future__ import braces’.
> I've seen bits of code in preprocessing-based "Python with {}" type
> things, and they still look like Python to me, only they favor
> explicit over implicit a little more strongly.
They introduce unnecessary ambiguity: the indentation-as-structure and
braces-as-structure can then disagree.
In which case either the Python interpreter must guess the programmer's
intent (very un-Pythonic), or it throws an error and the programmer must
do busy-work to keep braces and indentation in agreement (also
un-Pythonic).
The ambiguity is resolved by having exactly one of indentation or braces
determining structure: Python uses indentation. In which case, braces
are pointless for indicating block structure.
--
\ “Without cultural sanction, most or all of our religious |
`\ beliefs and rituals would fall into the domain of mental |
_o__) disturbance.” —John F. Schumaker |
Ben Finney
Chris Angelico
> Seebs <usenet...@seebs.net> writes:
>> I've seen bits of code in preprocessing-based "Python with {}" type
>> things, and they still look like Python to me, only they favor
>> explicit over implicit a little more strongly.
>
> They introduce unnecessary ambiguity: the indentation-as-structure and
> braces-as-structure can then disagree.
>
> determining structure: Python uses indentation. In which case, braces
> are pointless for indicating block structure.
That's why it wouldn't be Python. It would have to use the braces and
not the indentation.
ChrisA
PS. I mistakenly sent this to a Gilbert & Sullivan group first. Oddly
enough, opera-goers are not used to discussing the relative merits of
braces vs indentation in code.
Tim Chase
> PS. I mistakenly sent this to a Gilbert& Sullivan group
> first. Oddly enough, opera-goers are not used to discussing
> the relative merits of braces vs indentation in code.
It's only fair turnabout:
http://coding.derkeiler.com/Archive/Python/comp.lang.python/2006-09/msg01783.html
-tkc
Steven D'Aprano
Chris stated that putting the unary + at the end of the line
prevents "that", that being applying the unary + operator to the value on
the right. But that is not the case -- unary prefix operators in Python can
be separated from their operands by whitespace, including newlines.
(Python doesn't have any unary postfix operators.)
--
Steven
Chris Angelico
Yes, I know about that one. My problem is that I snap off quick
responses to both lists, and sometimes type "sav" instead of "py" or
vice versa. Usually I catch it before hitting Send, though!!
On MUDs, we call that a mischannel. I've now mischanneled both directions. :|
ChrisA
Chris Angelico
Right, I forgot that. It certainly would not be normal to do it that
way, though.
ChrisA
Steven D'Aprano
> On 2011-08-10, Chris Angelico <ros...@gmail.com> wrote:
>> And if we require {} then truly free indentation should be OK too! But
>> it wouldn't be Python any more.
>
> Would it really not be Python at all?
Of course it wouldn't be. Every function, class, if, while, for,
try...except block etc. in existing Python code would be illegal if {} were
required. This would be an order of magnitude bigger change than going from
Python 2 to 3, where the biggest syntax change is that print is no longer a
statement.
Even more so if ; were to become required, as suggested by the Original
Poster.
> I've seen bits of code in preprocessing-based "Python with {}" type
> things, and they still look like Python to me, only they favor explicit
> over implicit a little more strongly.
"Looks like" Python does not equal "is Python". Cobra looks like Python, as
do Boo, Groovy and Ruby, or OCaml with "twt" turned on ("the whitespace
thing"). The similarities are especially strong for Boo and Cobra, but
there is no doubt that they are different languages.
In general, languages that aim to look like executable pseudo-code will
converge on a similar look, because executable pseudo-code tends to be
based on natural language (usually English) and mathematics syntax.
--
Steven
Chris Angelico
<steve+comp....@pearwood.info> wrote:
>> I've seen bits of code in preprocessing-based "Python with {}" type
>> things, and they still look like Python to me, only they favor explicit
>> over implicit a little more strongly.
>
> "Looks like" Python does not equal "is Python". Cobra looks like Python, as
> do Boo, Groovy and Ruby, or OCaml with "twt" turned on ("the whitespace
> thing"). The similarities are especially strong for Boo and Cobra, but
> there is no doubt that they are different languages.
>
> In general, languages that aim to look like executable pseudo-code will
> converge on a similar look, because executable pseudo-code tends to be
> based on natural language (usually English) and mathematics syntax.
"Looks like" is a poor indication of anything much; "feels like" is a
bit vague, but may be more useful. If you can manipulate objects and
references to objects, if you can use Python's rich object set and
standard library, if you can use Python-like features using reasonably
readable syntax, then it feels like Python. Little things don't matter
(eg whether 'print' is a keyword or a function). Big things do (eg
having to explicitly deallocate objects).
Lots of languages "look like" C. Some of them function like C (eg
C++), and most definitely "feel like" C. Others don't.
ChrisA
Ben Finney
Also of interest: Do a web search for “debian dueling banjos”.
Or read about the phenomenon at <URL:http://gumbaby.com/?p=64>.
--
\ “The restriction of knowledge to an elite group destroys the |
`\ spirit of society and leads to its intellectual |
_o__) impoverishment.” —Albert Einstein |
Ben Finney
Yingjie Lan
:it wouldn't be Python any more.
Of course, but not the case with ';'. Currently ';' is optional in Python,
But '{' is used for dicts. Clearly, ';' and '{' are different in magnitude.
So the decision is: shall we change ';' from optional to mandatory
to allow free line splitting?
Yingjie
Yingjie Lan
Indentation is a good idea to reduce the likelihood of such troubles.
and also produce code that is easier to read.
Yingjie
Chris Rebert
> :And if we require {} then truly free indentation should be OK too! But
>
> :it wouldn't be Python any more.
>
> Of course, but not the case with ';'. Currently ';' is optional in Python,
I think of it more as that Python deigns to permit semicolons.
> But '{' is used for dicts. Clearly, ';' and '{' are different in magnitude.
>
> So the decision is: shall we change ';' from optional to mandatory
> to allow free line splitting?
Hell no, considering that the sizable majority of lines *aren't*
split, which makes those semicolons completely redundant to their
accompanying newlines. We'd be practicing poor Huffman coding by
optimizing for the *un*common case. It would also add punctuational
noise to what is otherwise an amazingly clean and readable syntax.
Accidental semicolon omission is (IMO) the most irritating source of
syntax (and, inadvertently, sometimes other more serious) errors in
curly-braced programming languages.
Such a core syntax feature is not going to be changed lightly (or likely ever).
Cheers,
Chris
Steven D'Aprano
Why on earth would you want to break backwards compatibility of millions of
Python scripts and programs, and require extra, unnecessary line-noise on
every single line of Python code, just so that you can occasionally avoid a
writing a pair of parentheses?
This will never happen. Forget it. Python is more likely to get static types
than compulsory semi-colons.
--
Steven
Seebs
> Seebs wrote:
>> On 2011-08-10, Chris Angelico <ros...@gmail.com> wrote:
>>> And if we require {} then truly free indentation should be OK too! But
>>> it wouldn't be Python any more.
>> Would it really not be Python at all?
> Of course it wouldn't be. Every function, class, if, while, for,
> try...except block etc. in existing Python code would be illegal if {} were
> required.
So?
Since there has never been an indentation-related problem in the history
of human endeavors, automatically adding the braces would be completely
trivial.
How much of the language *specification* would change?
> In general, languages that aim to look like executable pseudo-code will
> converge on a similar look, because executable pseudo-code tends to be
> based on natural language (usually English) and mathematics syntax.
This is an interesting point. I guess I meant "look like" in a more abstract
sense; the basic idea of what it's like to read the code, and what you have
to keep in mind while doing so.
Chris Rebert
>> :And if we require {} then truly free indentation should be OK too! But
>>
>> :it wouldn't be Python any more.
>>
>> But '{' is used for dicts. Clearly, ';' and '{' are different in
>> magnitude.
>>
>> So the decision is: shall we change ';' from optional to mandatory
>> to allow free line splitting?
On Wed, Aug 10, 2011 at 9:51 PM, Michael Trausch <fd0...@gmail.com> wrote:
> Perhaps it could be made an optional thing to enable; for example, some
> languages by default do dynamic typing, but with an option contained as the
> first statement of the file can enforce static typing.
I am intrigued. What languages(s) have the feature you refer to?
Cheers,
Chris
Seebs
> Seebs <usenet...@seebs.net> writes:
>> On 2011-08-10, Chris Angelico <ros...@gmail.com> wrote:
>> > And if we require {} then truly free indentation should be OK too!
>> > But it wouldn't be Python any more.
>> Would it really not be Python at all?
> See the Python interpreter's response to ???from __future__ import braces???.
I'm aware of that. I have seen all the counterarguments, and what I've
mostly become convinced of is this:
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.
>> I've seen bits of code in preprocessing-based "Python with {}" type
>> things, and they still look like Python to me, only they favor
>> explicit over implicit a little more strongly.
> They introduce unnecessary ambiguity: the indentation-as-structure and
> braces-as-structure can then disagree.
Yes, they can.
> In which case either the Python interpreter must guess the programmer's
> intent (very un-Pythonic), or it throws an error and the programmer must
> do busy-work to keep braces and indentation in agreement (also
> un-Pythonic).
The obvious answer would be:
* Braces win because they are explicit rather than implicit.
* Everyone would use things configured to throw a warning or error.
The thing is... This whole argument rests on the assumption that if there
are no braces, there is only one set of things, but if you have braces,
there are two.
This is untrue.
If there are no braces, there are two things describing flow control;
indentation and programmer intent. With braces, there's three.
The most common misalignment is between the code as interpreted by the
computer and the programmer's intent. Neither system prevents this, but
that's where all the real hassle comes from.
My expectation would be that the only times braces and indentation
would be "ambiguous" would be cases where the indentation got screwed up.
In these cases, I would MUCH prefer to get a fatal error than to have
things run in a way entirely unrelated to the intent I had when I wrote
the code.
> The ambiguity is resolved by having exactly one of indentation or braces
> determining structure: Python uses indentation. In which case, braces
> are pointless for indicating block structure.
I don't think so, any more than I think parentheses which happen to align
with the existing precendence rules are pointless.
In the real world, we are confronted constantly with tools which work
perfectly with every programming language but Python or very old FORTRAN,
but which mangle Python code sporadically and inexplicably. Mail servers
chew up whitespace like there's no tomorrow. Web pages find innovative new
explanations for why those leading spaces don't need to be displayed.
I like Python a lot in some ways, but I am really sick of the insistance that
this godawful wart is the sublime epitome of all perfection, never to be
improved on. It was a really interesting experiment. As sometimes happens,
the experiment discovered things that no one could have reasonably anticipated
without running the experiment.
Ben Finney
> On 2011-08-10, Ben Finney <ben+p...@benfinney.id.au> wrote:
> > Seebs <usenet...@seebs.net> writes:
> >> On 2011-08-10, Chris Angelico <ros...@gmail.com> wrote:
> >> > And if we require {} then truly free indentation should be OK too!
> >> > But it wouldn't be Python any more.
>
> >> Would it really not be Python at all?
>
> > See the Python interpreter's response to ???from __future__ import braces???.
>
> I'm aware of that. I have seen all the counterarguments, and what I've
> mostly become convinced of is this:
>
> 1. Indentation as flow control was a bad idea.
> 2. People are subconsciously aware of this.
What evidence do you have of these? The latter, especially, seems to be
mere opinion unfounded in any measurement.
> 3. There is a HUGE degree of emotional investment in defending it.
That same observation is consistent with:
* Indentation as block syntax is an excellent idea.
* Python programmers are quite consciously aware of this.
So I don't see a reason to prefer your inference over mine.
> The responses I have seen on this issue are highly emotional, full of
> insults, full of blame-throwing
Again, I don't know where you've been observing that, but it's not what
I've seen.
> I like Python a lot in some ways, but I am really sick of the
> insistance that this godawful wart is the sublime epitome of all
> perfection, never to be improved on. It was a really interesting
> experiment. As sometimes happens, the experiment discovered things
> that no one could have reasonably anticipated without running the
> experiment.
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.
Since that latter set of people includes most Python programmers who
have reacted negatively to the proposal, you may want to re-think
whether your effort is worthwhile. Meanwhile, we'll continue being
productive with Python's indentation-as-structure.
--
\ “If nature has made any one thing less susceptible than all |
`\ others of exclusive property, it is the action of the thinking |
_o__) power called an idea” —Thomas Jefferson, 1813-08-13 |
Ben Finney
Chris Rebert
> From: Steven D'Aprano <steve+comp....@pearwood.info>
> On Thu, 11 Aug 2011 12:52 pm Yingjie Lan wrote:
>
>> :And if we require {} then truly free indentation should be OK too! But
>>
>> :it wouldn't be Python any more.
>>
>> Of course, but not the case with ';'. Currently ';' is optional in Python,
>> But '{' is used for dicts. Clearly, ';' and '{' are different in
>> magnitude.
>>
>> So the decision is: shall we change ';' from optional to mandatory
>> to allow free line splitting?
>
> :Why on earth would you want to break backwards compatibility of millions of
> :Python scripts and programs, and require extra, unnecessary line-noise on
> :every single line of Python code, just so that you can occasionally avoid a
> :writing a pair of parentheses?
>
> artifitial and
> requires the coder to serve the machine rather than the other way around)
> with proper indentation will produce truely ergonomic code layout (well,
> assuming you also like properly indented code).
>
> And this can be done almost hassle-free for the coder.
<snip>
> The trouble of adding a ';' to most of the lines can also be
> avoided by a smart editor (see my other reply).
The trouble of dealing with long lines can be avoided by a smart
editor. It's called line wrap.
Cheers,
Chris
Chris Angelico
> Somthing like an "option" keyword (which would only be a keyword until the
> first executable statement, e.g., would have to be before even imports)
> could enable things like "semicolon" or "explicit", or whatever really, and
> only affect those who opt in. If no code is ever seen using the option, it
> can even be removed. Wouldn't be a bad way to test changes that would impact
> the syntax of the language, actually...
Python already has a syntax like this:
from __future__ import statictyping
Although I'm not sure how you'd go about implementing it plausibly.
It'd be a fairly backward-incompatible change; what would happen to
the modules you import? Either you would have to have a duplicate set
(one that uses statictyping and one that doesn't), or you'd have to
have statictyping somehow work on a per-module basis. As far as I
know, most of the other future statements are per-module (with the
possible exception of barry_as_FLUFL, which until today I was not
aware of).
Would static typing then apply only to module-level variables and
function-local variables, with the values in
lists/tuples/dicts/objects/etc/etc/etc still being dynamically typed?
I think it'd be easier to fork Python and give it a new name.
ChrisA
Vito 'ZeD' De Tullio
> :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)
--
By ZeD
Steven D'Aprano
> I have seen all the counterarguments, and what I've
> mostly become convinced of is this:
>
> 1. Indentation as flow control was a bad idea.
I'm not aware of any language where indentation is used for flow control.
Python is not one of those languages: it uses for, while, if, etc. for flow
control, just like most other languages. It does however use indentation
for grouping code into blocks -- a different concept.
> 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
So you say.
You are free to hold whatever opinions you like, but have you considered
that the reason people get emotional and angry when others insist that
indentation as flow control should be discarded is because they actually
believe that the "off-side rule" (as it is called) makes for a better
language and a better coding experience? We're not defensive because we
subconsciously know you're right, we're defensive because we consciously
know you're wrong, have heard all the arguments a thousand times before,
and are sick and tired of them.
There are dozens, hundreds of brace languages, and 1-2 dozen using
indentation, including Python. If braces are so important to you, go use
one of those other languages, don't wreck the language we like by taking
away one of the best features of the language.
> 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.
We're fully aware of the tradeoffs of significant indentation. We believe
that brace languages get the trade-offs backwards: they optimise code for
environments which mangle source code. 99.999% of code will never pass
through a broken mail server that strips leading whitespace, or pasted into
broken web forum software that mangles indentation, or go through any other
broken tool that messes with indentation. Brace languages optimise for the
0.001% case, Python optimised the 99.999% case.
Because people simply don't like it when their code's indentation doesn't
match the actual semantics, people usually manually ensure that the two
match, braces or no braces. Editors still have commands to indent and
outdent blocks of code. There is no difference between (say) C or Pascal
and Python in that regard.
> * Braces win because they are explicit rather than implicit.
There is nothing implicit about indentation. This false dichotomy between
so-called explicit braces and allegedly implicit indentation gets thrown
around all the time, but it is simply *wrong*. Indentation is not implicit.
You (or your editor) has to add whitespace to the line, the parser has to
see the whitespace, and an INDENT token is created for it.
[...]
> In the real world, we are confronted constantly with tools which work
> perfectly with every programming language but Python or very old FORTRAN,
And ABC, Boo, BuddyScript, Cobra, CoffeeScript, Curry, F#, Genie, HAML,
Haskell, ISWIM, Miranda, Nemerle, Occam, PROMAL, Spin and XL, plus any
other languages with significant indentation.
> but which mangle Python code sporadically and inexplicably. Mail servers
> chew up whitespace like there's no tomorrow. Web pages find innovative
> new explanations for why those leading spaces don't need to be displayed.
No, most mail servers don't mangle whitespace in the body of the email, or
in attachments. Some mail clients do, usually because they default to using
HTML for text. So get a better mail client. Avoid pig-ignorant web forums
that think that source code can be reflowed or that remove leading
whitespace. Stop using Notepad, and use an editor that offers indent and
outdent commands.
If your mail server had a bug that deleted braces from emails, would you fix
the bug, or would you insist that braces were a failed experiment and that
C should stop using { } and start using BEGIN END like Pascal?
--
Steven
Steven D'Aprano
> indentation as flow control
Gah! Of course, I meant indentation for blocks... after making the earlier
point that indentation is *not* used for flow control, this was a
particularly egregious error.
How embarrassment.
--
Steven
MRAB
> On Wed, Aug 10, 2011 at 7:52 PM, Yingjie Lan<lan...@yahoo.com> wrote:
>> :And if we require {} then truly free indentation should be OK too! But
>>
>> :it wouldn't be Python any more.
>>
>> Of course, but not the case with ';'. Currently ';' is optional in Python,
>
>
>>
>> So the decision is: shall we change ';' from optional to mandatory
>> to allow free line splitting?
>
> split, which makes those semicolons completely redundant to their
> accompanying newlines. We'd be practicing poor Huffman coding by
> optimizing for the *un*common case. It would also add punctuational
> noise to what is otherwise an amazingly clean and readable syntax.
> Accidental semicolon omission is (IMO) the most irritating source of
> syntax (and, inadvertently, sometimes other more serious) errors in
> curly-braced programming languages.
>
> Such a core syntax feature is not going to be changed lightly (or likely ever).
>
Although Python's use of indentation has its downside, we gain much
more then we lose, IMHO.
Matt Joiner
The "trailing \" workaround is nonobvious. Wrapping in () is noisy and
already heavily used by other syntactical structures. Since a final
':' is needed anyway, i think this would be great.
if a
and b
or c:
do stuff()
> _______________________________________________
> Python-ideas mailing list
> Python...@python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>
Neil Cerutti
Had I not become a lover of semantic indentation,
Wisely wielding willing whitespace in a wondrous preparation,
I could buttress blocks with braces, a la Kernighan and Ritchie,
(Other styles, just as valid, make me terri-bul-ly twitchy),
What I noticed was the whitespace hasn't shifted one iota,
With the braces superfluous in my wc -m quota,
When delineating code-blocks, with my keys a-clitter-clatter,
I prefer semantic whitespace 'cause the braces shouldn't matter.
No, the braces shouldn't matter,
(Matter, matter, matter, matter)
No, the braces shouldn't matter,
(Matter, matter, matter, matter)
When delineating code-clocks, with my keys a-clitter-clatter,
I prefer semantic whitespace 'cause the braces shouldn't matter.
--
Neil Cerutti
Jakob Bowyer
python. Personally it would create more confusion than it would
remove.
Daniel Greenfeld
a = 0
b = 1
if (True == True
and False == False
and a + 1 == b
and b - 1 == a):
print 'meh'
So I've got no idea what this proposal is about except for the
dropping of readability of Python.
-1
Daniel Greenfeld
Paul Colomiets
On Thu, Aug 11, 2011 at 5:28 PM, Matt Joiner <anac...@gmail.com> wrote:
> +0.5
>
> The "trailing \" workaround is nonobvious. Wrapping in () is noisy and
> already heavily used by other syntactical structures. Since a final
> ':' is needed anyway, i think this would be great.
>
> if a
> and b
> or c:
> do stuff()
>
If you really think so, try writing some coffeescript (remember to
obey 79 chars limit). Coffeescript is amasing, but it lacks
strictness of python. So you really don't know how to break line,
and it really takes time to figure out right way each time you need
it.
--
Paul
Devin Jeanpierre
Eek no. If I was suggesting anything, it would have been a third form
of continuation: collapsing subsequent extra-indented lines. This is
never ambiguous. (This could be done in such a way as to permit
comments, namely, by doing it to the tokenstream rather than to the
actual text)
Devin
On Thu, Aug 11, 2011 at 4:45 PM, Bruce Leban <br...@leapyear.org> wrote:
>
> On Thu, Aug 11, 2011 at 12:24 PM, Devin Jeanpierre <jeanpi...@gmail.com> wrote:
>>
>> Javascript also lets you break lines. For example, this does what you want:
>>
>> return 1
>> + 5
>>
>> Whereas this does not
>>
>> return
>> 1 + 5
>>
>> Of course, Python would have no such problem, because you could make both cases unambiguous due to the indent.
>>
>> Devin
>>
> Note that this is already valid and is not a continuation line:
>
> return 1
> +5
>
> Right now you do not need to indent continuation lines. So in order to disambiguate you would need to enforce indentation for continuations, but for backward compatibility that would only be required when not using parentheses or backslashes. Ick. Can blank lines or comment lines appear between a line and its continuation? That's allowed now as well.
> Now allowing line breaks *after* operators would be unambiguous and would not require new indentation rules. When a line ends with an operator, it's clearly incomplete (so no fear the reader will think the statement has ended unlike the above case) and it's a syntax error today:
>
> return 1 +
> 5
> x = y > 0 and
> y < 10
>
> This code is not valid today without parens or \ regardless of indentation. I'm +0 on this. I'd use it but does it really add enough convenience?
> --- Bruce
> Follow me: http://www.twitter.com/Vroo http://www.vroospeak.com
Devin Jeanpierre
c = d
is a pair of such statements.
Howeverm indentation errors have been extremely rare in my experience,
so I'm not really compelled to think it's harmful. Especially since
3.x outlaws mixing tabs and spaces.
I don't love it, but I guess I prefer it to throwing parentheses and
especially \ everywhere. Parentheses can be awkward and don't quite
work everywhere the way one might want, and \ has that trailing space
ugliness.
Devin
On Thu, Aug 11, 2011 at 5:21 PM, Bruce Leban <br...@leapyear.org> wrote:
>
> On Thu, Aug 11, 2011 at 2:06 PM, Devin Jeanpierre <jeanpi...@gmail.com>
> wrote:
>>
>> Eek no. If I was suggesting anything, it would have been a third form
>> of continuation: collapsing subsequent extra-indented lines. This is
>> never ambiguous. (This could be done in such a way as to permit
>> comments, namely, by doing it to the tokenstream rather than to the
>> actual text)
>
> So if I miss-indent this
> a = b
> (x, y) = z
>
> instead of getting "unexpected indent" I get "SyntaxError: can't assign to
> function call". I'm sure someone can come up with two valid statements that
> have a different meaning when spliced together.
Jim Jewett
<jeanpi...@gmail.com> wrote:
> Howeverm indentation errors have been extremely rare in my experience,
> so I'm not really compelled to think it's harmful. Especially since
> 3.x outlaws mixing tabs and spaces.
I normally get them when starting with code from somewhere else (which
might well mixed tabs and spaces, or worse, if emailed or posted to
the web) or when cutting and pasting at an interactive prompt.
-jJ
Seebs
> What evidence do you have of these? The latter, especially, seems to be
> mere opinion unfounded in any measurement.
Well, on new collection of data, I'm less convinced.
The basic rule is:
Engineers are nearly always aware of tradeoffs. If I suddenly encounter
something where many engineers perceive a tradeoff, and a few deny that
there is any tradeoff at all, that usually means that the latter category
are not actually doing the engineering thing.
> Again, I don't know where you've been observing that, but it's not what
> I've seen.
I've seen it some here, and in other Python discussion threads. I've also
seen counterexamples, though, more now that I brought it up.
> 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 have noticed a tendency for "Pythonic" to produce fierce debates in
which there is absolutely nothing measurable to point to. I'm not sold
on it.
I guess the thing is this:
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.
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.
See, that's the thing. If you want to tell me that there are problems with
braces, I'll *agree*. I am aware of those problems. I don't feel a need to
deny that they exist.
Seebs
>> I have seen all the counterarguments, and what I've
>> mostly become convinced of is this:
>> 1. Indentation as flow control was a bad idea.
> I'm not aware of any language where indentation is used for flow control.
> Python is not one of those languages: it uses for, while, if, etc. for flow
> control, just like most other languages. It does however use indentation
> for grouping code into blocks -- a different concept.
Agh! Point granted. Presumably you knew what I meant, but you're right
that I said it wrong.
> You are free to hold whatever opinions you like, but have you considered
> that the reason people get emotional and angry when others insist that
> indentation as flow control should be discarded is because they actually
> believe that the "off-side rule" (as it is called) makes for a better
> language and a better coding experience?
Yes.
And when I talk to people who are *able to admit that there exist problems*,
and who argue that the benefits outweigh them, I believe that they are
probably making a good point.
It's the people who insist that there are no problems that worry me.
> There are dozens, hundreds of brace languages, and 1-2 dozen using
> indentation, including Python. If braces are so important to you, go use
> one of those other languages, don't wreck the language we like by taking
> away one of the best features of the language.
If I had a choice, believe me, I'd do just that.
> We're fully aware of the tradeoffs of significant indentation.
You are. A couple of other people I've talked to are. Many others
are not.
> We believe
> that brace languages get the trade-offs backwards: they optimise code for
> environments which mangle source code. 99.999% of code will never pass
> through a broken mail server that strips leading whitespace, or pasted into
> broken web forum software that mangles indentation, or go through any other
> broken tool that messes with indentation. Brace languages optimise for the
> 0.001% case, Python optimised the 99.999% case.
This is a really interesting analysis. My experience, though, puts it
more at about 99% and 1%. And the thing is...
> Because people simply don't like it when their code's indentation doesn't
> match the actual semantics, people usually manually ensure that the two
> match, braces or no braces. Editors still have commands to indent and
> outdent blocks of code. There is no difference between (say) C or Pascal
> and Python in that regard.
Yes, there very much is.
You can't outdent "a block" in Python unless it is already correctly
indented.
The underlying thing I've noticed is:
Braces have problems more often, but the problems are *always* 100%
machine-fixable and therefore trivial. It takes milliseconds to get
a program fixed so it looks like what it means.
Indentation has problems less often, but the problems are *never*
machine-fixable. It takes minutes or hours to figure out what was
supposed to be there.
> There is nothing implicit about indentation. This false dichotomy between
> so-called explicit braces and allegedly implicit indentation gets thrown
> around all the time, but it is simply *wrong*. Indentation is not implicit.
Hmm. Maybe "implicit" isn't quite the right word, but... The end of an
indented block is not a thing, it's the lack-of-a-thing.
foo
bar
How many unindents are there between "foo" and "bar"?
If you can't answer this from looking between "foo" and "bar", but must
instead look at previous lines and *INFER* the number of unindents, then
it seems to me that there is something implicit going on here.
> And ABC, Boo, BuddyScript, Cobra, CoffeeScript, Curry, F#, Genie, HAML,
> Haskell, ISWIM, Miranda, Nemerle, Occam, PROMAL, Spin and XL, plus any
> other languages with significant indentation.
Point made.
> No, most mail servers don't mangle whitespace in the body of the email, or
> in attachments.
Most don't, that's true.
Part of my frustration comes from a 6-month period during which most of my
email was sent through a mail server which, for reasons no one was able to
determine, was dutifully converting any plain text it received into HTML,
and stripping "irrelevant" spaces along the way. :)
> Some mail clients do, usually because they default to using
> HTML for text. So get a better mail client.
I have tried occasionally. Mine does not default to use HTML, but it
does sometimes mangle lines. Unfortunately, it's the closest to having
other funcitonality I want I've ever seen.
> Avoid pig-ignorant web forums
> that think that source code can be reflowed or that remove leading
> whitespace. Stop using Notepad, and use an editor that offers indent and
> outdent commands.
I'm not using Notepad. And actually, it's the indent/outdent that bit me
worst, so far. :)
> If your mail server had a bug that deleted braces from emails, would you fix
> the bug, or would you insist that braces were a failed experiment and that
> C should stop using { } and start using BEGIN END like Pascal?
If *only one program* deleted braces, sure. If "braces get deleted" were
pretty much a daily occurrence among people I know (not everyone gets hit
every day, but someone gets hit just about every day), and had been for the
last 20+ years, I might feel differently.
But I think a lot of this just comes down to the underlying human thing:
People don't like being dismissed. When people come here and say that, for
whatever reason, they are in an environment in which the whitespace thing
is a problem, they get insulted and told that all their tools, which they
may have been using without any trouble for twenty years, are defective and
should be completely thrown out. Heck, arguably I should consider "Stop using
Notepad" to be pretty insulting.
And at the same time, I think the people who like the indentation policy
are probably pretty sick of seeing it bashed. So there's a tendency for
gradual escalation, and of course, each new person who comes here is coming
here with a thing which is new *to them*, but old *to you*. So CLP jumps
all over people who say that this is a problem for them, tells them
they're wrong, tells them they're stupid, tells them that their work
environment isn't *good enough* for them to be worthy of using Python. And
tells them to leave.
Well, seriously. If I could, I would. If it were up to me, I'd talk to the
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.
Seebs
> How embarrassment.
My fault, I probably hypnotized you with my bad word choice. :)
Ethan Furman
>> We're fully aware of the tradeoffs of significant indentation.
>
> You are. A couple of other people I've talked to are. Many others
> are not.
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.
>> Because people simply don't like it when their code's indentation doesn't
>> match the actual semantics, people usually manually ensure that the two
>> match, braces or no braces. Editors still have commands to indent and
>> outdent blocks of code. There is no difference between (say) C or Pascal
>> and Python in that regard.
>
> Yes, there very much is.
>
> You can't outdent "a block" in Python unless it is already correctly
> indented.
I fix the block, then move it as I need to.
> The underlying thing I've noticed is:
>
> Braces have problems more often, but the problems are *always* 100%
> machine-fixable and therefore trivial. It takes milliseconds to get
> a program fixed so it looks like what it means.
Not so. If the braces do not match /intent/ (which is the problem I
care most about) then it cannot be fixed by machine.
> Indentation has problems less often, but the problems are *never*
> machine-fixable. It takes minutes or hours to figure out what was
> supposed to be there.
I can see where a messed-up mail server could cause hours of grief. Not
having experienced that, but only cases where I, myself, accidently
changed indentation when I should have, it's not been a big deal to fix;
I'm willing to live with not having the machine reformat my source code
from incorrect to correct.
...
> Well, seriously. If I could, I would. If it were up to me, I'd talk to the
> 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.
~Ethan~
Devin Jeanpierre
understand it (such a change to indent semantics could only go into
3.x), and cutting and pasting to the interpreter is obvious anyway
just visually, regardless of the specific error message.
The other issue sounds reasonable. Code that has indentation stripped
or mangled due to the transition medium would be even harder to
recompose.
Devin
Chris Angelico
> 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.
>
Indentation-is-syntax is a feature of Python, and one that's not
likely to change. Some programmers do not like indentation to be
syntax, and a lot of them are not likely to change their views.
There's a solution to this dilemma; it's called "using another
language".
Python is just one of many excellent languages in the world today.
Even if you exclude non-free languages and non-free
compilers/interpreters, you still have a wealth of options. Check
Wikipedia, find one in a category that interests you, download a
development environment, and give it a shot!
It would surprise me *greatly* if the regular posters on this list
were not all familiar with several languages other than Python,
including at least one bracey language. The arguments do not come from
ignorance but from knowledge. Incidentally, I will happily argue the
benefits of Python's significant whitespace, even though I disagree
with it; there are quite a few. (Is the fact that it discourages
massive one-liners considered to be a benefit?)
Of course, sometimes choosing another language is a luxury you can't
afford. But in those situations, usually you're slotting into someone
else's code Manual of Style too, so you might be required to write C
code with three-space indents and a blank line before every open
brace, for all we know. Doesn't matter that you're in a
whitespace-insignificant language; you are in a whitespace-significant
*environment*, and that's what matters.
Chris Angelico
Steven D'Aprano
> 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. 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)
See also:
http://weblog.hotales.org/cgi-bin/weblog/nb.cgi/view/python/2005/02/19/1
http://c2.com/cgi/wiki?SyntacticallySignificantWhitespaceConsideredHarmful
> (Is the fact that it discourages
> massive one-liners considered to be a benefit?)
Hell yes!
--
Steven
Steven D'Aprano
> +0.5
>
> The "trailing \" workaround is nonobvious. Wrapping in () is noisy and
> already heavily used by other syntactical structures.
"Noisy"? Compare:
# Best viewed with a fixed-width font
if a if (a
and b and b
or c: or c):
do stuff() do stuff()
That is not my idea of "noise". The brackets have a clear and obvious
meaning: they group the condition.
> Since a final
> ':' is needed anyway, i think this would be great.
A final : is not needed for arbitrary expressions.
flag = (a
and b
or c)
--
Steven
Seebs
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
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.
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.
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.
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.
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. All the people yelling at me and insulting
my choice of editors, and telling me I should control every mail server
between me and anyone who will ever send me code, have done nothing at all
to make me feel like this is a language community I'd like. Meanwhile, the
Python users I've talked to elsewhere who have funny indentation war stories
but say that over time they've gotten used to it and they like how the code
looks have made it sound like the language might be sorta fun.
Chris Angelico
<steve+comp....@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
Chris Angelico
> 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
Ben Finney
> On 2011-08-11, Ben Finney <ben+p...@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
Ben Finney
> 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
Steven D'Aprano
> 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
Ben Finney
> 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
Neil Cerutti
<steve+comp....@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
Thomas Rachel
> 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...
Chris Rebert
> Seebs <usenet...@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
Seebs
>> 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*.
Seebs
>> 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.
Seebs
> On Fri, Aug 12, 2011 at 7:34 AM, Seebs <usenet...@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.
Seebs
> 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?
Seebs
> 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.
Chris Angelico
> 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?
>
> 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
Chris Angelico
> 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
Chris Angelico
> 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.
Ethan Furman
> 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.
Argh! ;)
~Ethan~
Seebs
>> 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 :)
I think it sort of is. My current preference would be that C-like languages
would simply absolutely eliminate optional-braces. Then the whole category
of errors would partially-go-away. You could still have code which didn't
do what you meant, but it would be reliably easy to see what it did, and
so on. But it's interesting to note that there are many ways to address
this.
Most of the C I've done has been in circumstances where misindented code
was in fact a thing that would fail reviews.
Seebs
> 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.
... Hmm. There is a thought; I think it may be useful to distinguish
between "Pythonic" and "Pythonic in a vacuum". That is to say, there
are things which would fit the basic philosophy of Python very well
if previous programming languages and tools were not widespread, and
there are other things which fit anyway. Using a simple left-to-right
evaluation would probably be easier for people to understand, and
more self-explanatory, *IF* there were no prior art.
> Why is it more logical than
> right-to-left? And why is changing people's expectations more logical
> than fulfilling them?
Well, playing devil's advocate's advocate here... You could argue that
switching from braces to indentation might be "changing" peoples'
expectations, or might be fulfilling them, depending on the people.
I think there's certainly cases where it is probably better to say
"that expectation proves to make it impossible to build a clean
language, so we're going to ask you to do things this way", and cases
where it is probably better to say "that expectation is very deeply
established, and doesn't really hurt the language, so we'll adapt
to you".
> 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 wouldn't mind that.
> 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.
Yes, yes they do.
Huh.
You know, that's why the outdents-without-symbols bug me; I have a
thing with a colon on it introducing something, and then there's nothing
ending it. I want that match so I can let the naive stack-depth-counter
off somewhere in my brain do its thing without leaving me with a huge
feeling of unclosed blocks.
Seebs
>> 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 think that, then? Okay.
> You are clutching the past and it is taking
> you down with it.
I see. This is a brilliant new theory. I will further explore the notion
that actually my brain is 100% normal with no limitations except that I have
used languages with braces. Doubtless this will prove illuminating.
>> 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.
Nope, not telling you that. Here's my example:
if foo:
blah
blah
blah
if bar:
moreblah
moreblah
if quux:
typingisboring
typingisboring
typingisboring
moreblah
moreblah
if baz:
somuchblah
somuchblah
somuchblah
somuchblah
somuchblah
somuchblah
somuchblah
somuchblah
abitmoreblah
It's not easy for me to be sure, looking at something roughly like that,
what's being closed and what isn't. If I have braces, I can tell how many
things are being closed. I like that. It makes me happy.
>> 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!
Doesn't matter. At some point, somewhere, it would become desireable
to introduce precedence with (), at which point, it is quite possible
that the trailing ) would be redundant, so why not omit it?
> I am not trying to discredit you simply by disagreeing with you.
No, but you're certainly being insulting.
> 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.
Facts:
Pry your lips from Ritchie's left teet and stop slurping
that "brace" milk; because it is polluting your mind!
Emotionally charged babble:
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.
> 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.
Well played!
Steven D'Aprano
> On 2011-08-12, rantingrick <ranti...@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.
Please don't feed the troll. Responding to Rick's standard obnoxious posts
is like wrestling with a pig -- you get tired and filthy, you never
accomplish anything useful, and after a while, you realise that the pig is
enjoying it. Save yourself a lot of aggravation and kill-file him now.
--
Steven
Ben Finney
> On 2011-08-12, rantingrick <ranti...@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.
Please be aware that the particular person to whom you're responding is
decidedly not part of the helpful and welcoming community here.
> 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?
If you're interested, check the forum's archives for a thorough history
of what the helpful and welcoming community say about him. You'll find
we pretty much agree with your assessment.
--
\ “Generally speaking, the errors in religion are dangerous; |
`\ those in philosophy only ridiculous.” —David Hume, _A Treatise |
_o__) of Human Nature_, 1739 |
Ben Finney
Seebs
> is like wrestling with a pig -- you get tired and filthy, you never
> accomplish anything useful, and after a while, you realise that the pig is
> enjoying it. Save yourself a lot of aggravation and kill-file him now.
You know...
I think I just realized where a big part of my misperception of the Python
community was.
Which is that until todayish, I had not realized that he was regarded as a
troll by the rest of the community. But now that a couple of people have
told me this, I am a lot more comfortable referring to the Python community
in general as "welcoming".
I sometimes enjoy trying to extract information from people like that, but
I will respect the preferences of the actually-helpful people and drop that
line of inquiry. :)
Ben Finney
> I sometimes enjoy trying to extract information from people like that,
> but I will respect the preferences of the actually-helpful people and
> drop that line of inquiry. :)
Much appreciated, thank you :-)
--
\ “It is well to remember that the entire universe, with one |
`\ trifling exception, is composed of others.” —John Andrew Holmes |
_o__) |
Ben Finney
Steven D'Aprano
> You know, that's why the outdents-without-symbols bug me; I have a
> thing with a colon on it introducing something, and then there's nothing
> ending it.
But there is something ending it: a change in indentation level.
Python's parser explicitly pushes INDENT and OUTDENT tokens into the stream.
They're just a change of state in indentation level, which is much more
easily seen without the need for counting braces. Python's parser may need
to count tokens, but for the human reader merely needs to use its intuitive
and highly accurate ability to notice when things line up.
(Aside: this is why I dislike two-space indents. That's narrow enough to
make the "does this line up" detector subject to too many false positives.)
> I want that match so I can let the naive stack-depth-counter
> off somewhere in my brain do its thing without leaving me with a huge
> feeling of unclosed blocks.
Yet another reason to consider brace languages harmful: they spoil the
user's intuitive grasp of intuition as grouping.
And it really is intuitive[1]:
http://okasaki.blogspot.com/2008/02/in-praise-of-mandatory-indentation-for.html
Historically, nearly all languages with braces pre-date the widespread
adoption of tools that think they can mangle whitespace with impunity. (I
would say that the reasons that the tools are broken is *because*
programmers have trained themselves to think that whitespace doesn't
matter -- ask most writers or artists and they would say *of course*
whitespace matters. The separation between elements is important -- perhaps
not quite as important as the elements themselves, but still important.)
Explicit BEGIN/END tokens exist to make the job of the parser easier, not
that of the programmer. But the human brain is a funny thing: you can train
it to expect to do more work than is necessary, and it will complain when
you make its job easier.
[1] For some definition of intuition.
--
Steven
Chris Angelico
<steve+comp....@pearwood.info> wrote:
> ask most writers or artists and they would say *of course*
> whitespace matters.
You can write Perl code in the shape of a camel. Can you do that in Python?
Okay. Open challenge to anyone. Write a Python script that outputs
"Just another Python hacker" or some such message, and is shaped in
some way appropriately. And no fair doing all the shaping in comments
:)
(Has it already been done?)
ChrisA
Ben Finney
> On Fri, Aug 12, 2011 at 11:39 PM, Steven D'Aprano
> <steve+comp....@pearwood.info> wrote:
> > ask most writers or artists and they would say *of course*
> > whitespace matters.
>
> You can write Perl code in the shape of a camel. Can you do that in
> Python?
I'm glad to be using a language where that sort of hard to-read code is
not encouraged by the syntax.
Art is wonderful, if you don't want to communicate clearly. I'll thank
the people who write the programs in my life to save their artistic
expression for areas where clear communication is optional.
--
\ “My business is to teach my aspirations to conform themselves |
`\ to fact, not to try and make facts harmonise with my |
_o__) aspirations.“ —Thomas Henry Huxley, 1860-09-23 |
Ben Finney
Tim Chase
> You can write Perl code in the shape of a camel. Can you do that in Python?
>
> "Just another Python hacker" or some such message, and is shaped in
> some way appropriately. And no fair doing all the shaping in comments
Okay, my entry:
print("Just another Python hacker")
That lovely one-line shape resembles a straight & narrow snake ;-)
-tkc
Terry Reedy
I am responding to your whole line of posts.
I have been indenting code neatly for at least 32 years whenever the
language I used allowed it. Just over 14 years ago, when Python was an
obscure little known or used languge, I adopted it *because* it dropped
all the redundant bracket noise and looked to me like 'executable
pseudocode', as I explained (with an unfortunate misspelling) in
https://groups.google.com/group/comp.lang.python/msg/cc25701a283a3f68
Indentation is part of that. Python-with-brackets would, to me, be
something different -- sure, derived from Python, but not the same.
I do not need for you to adopt and use Python to validate my choice. If
you like it fine, welcome. If not, have fun with something else. I said
that over a decade when this same discussion took place, and I say it
now. Different brains are different. I do not care which of us is in the
majority in which population.
As I and others also pointed out over a decade ago, anyone is free to
add insignificant comment braces (but keep that private, please) or,
more sensibly, commented dedents to help the reader keep track of indent
level.
for...
for ...
if ...
for ...
if ...
[50 more lines of code]
#end outer if
[more code]
--
Terry Jan Reedy
Seebs
> Seebs wrote:
>> You know, that's why the outdents-without-symbols bug me; I have a
>> thing with a colon on it introducing something, and then there's nothing
>> ending it.
> But there is something ending it: a change in indentation level.
Hmm.
Okay, here's what I'm not getting. Consider this:
if foo:
blah
if bar:
blah
blah
if baz:
blah
blah
> Python's parser explicitly pushes INDENT and OUTDENT tokens into the stream.
What's being pushed into the stream to indicate that the first outdent
is two outdents and the second is one?
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.
> They're just a change of state in indentation level, which is much more
> easily seen without the need for counting braces. Python's parser may need
> to count tokens, but for the human reader merely needs to use its intuitive
> and highly accurate ability to notice when things line up.
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.
> (Aside: this is why I dislike two-space indents. That's narrow enough to
> make the "does this line up" detector subject to too many false positives.)
Yeah.
>> I want that match so I can let the naive stack-depth-counter
>> off somewhere in my brain do its thing without leaving me with a huge
>> feeling of unclosed blocks.
> 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".
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.
> But the human brain is a funny thing: you can train
> it to expect to do more work than is necessary, and it will complain when
> you make its job easier.
Easier varies somewhat from person to person. I need a LOT of parity checks
(speaking metaphorically) because my brain is fantastically prone to dropping
bits. But I'm really fast. So a thing with lots of parity checks is much
easier for me to actually *successfully* use than a thing which omits all
that extra stuff.
I was overjoyed when I saw that Ruby would let me write 1_048_576. I can
read that with fewer errors than I can read 1048576. (And yes, I could
also write "1<<20".)
Seebs
> I have been indenting code neatly for at least 32 years whenever the
> language I used allowed it. Just over 14 years ago, when Python was an
> obscure little known or used languge, I adopted it *because* it dropped
> all the redundant bracket noise and looked to me like 'executable
> pseudocode', as I explained (with an unfortunate misspelling) in
> https://groups.google.com/group/comp.lang.python/msg/cc25701a283a3f68
> Indentation is part of that. Python-with-brackets would, to me, be
> something different -- sure, derived from Python, but not the same.
Fair enough.
> I do not need for you to adopt and use Python to validate my choice. If
> you like it fine, welcome. If not, have fun with something else.
If this were among my options, it's probably what I'd do. It is what I do
for things where I get a choice of languages.
FWIW, yes, I spec machines with ECC memory whenever I can. I am a big
fan of "redundant" data that can detect likely errors.
Ben Finney
> What's being pushed into the stream to indicate that the first outdent
> is two outdents and the second is one?
See <URL:http://docs.python.org/reference/lexical_analysis.html> for a
comprehensive discussion of the lexing done on Python source.
To examine the resulting code objects, see the ‘dis’ module in the
standard library <URL:http://docs.python.org/library/dis.html>.
--
\ “[T]he question of whether machines can think … is about as |
`\ relevant as the question of whether submarines can swim.” |
_o__) —Edsger W. Dijkstra |
Ben Finney
Gregory Ewing
> But both of these violate XKCD 859.
For the benefit of all those who just went off to read
that strip, here's something to help you unwind:
)
There, you can relax now.
--
Greg
Seebs
> Seebs <usenet...@seebs.net> writes:
>> What's being pushed into the stream to indicate that the first outdent
>> is two outdents and the second is one?
> See <URL:http://docs.python.org/reference/lexical_analysis.html> for a
> comprehensive discussion of the lexing done on Python source.
Interesting, thanks.