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

Groups > comp.lang.python > #11094 > unrolled thread

Re: allow line break at operators

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: allow line break at operators Yingjie Lan <lanyjie@yahoo.com> - 2011-08-09 23:05 -0700
    Re: allow line break at operators Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-10 18:32 +1000
      Re: allow line break at operators Chris Angelico <rosuav@gmail.com> - 2011-08-10 09:39 +0100
      Re: allow line break at operators Dan Sommers <dan@tombstonezero.net> - 2011-08-10 09:56 +0000
        Re: allow line break at operators Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-11 00:44 +1000
      Re: allow line break at operators Chris Angelico <rosuav@gmail.com> - 2011-08-10 11:26 +0100
        Re: allow line break at operators Duncan Booth <duncan.booth@invalid.invalid> - 2011-08-10 12:25 +0000
          Re: allow line break at operators Chris Angelico <rosuav@gmail.com> - 2011-08-10 13:42 +0100
          Re: allow line break at operators Yingjie Lan <lanyjie@yahoo.com> - 2011-08-10 05:58 -0700
          Re: allow line break at operators Chris Angelico <rosuav@gmail.com> - 2011-08-10 15:45 +0100
          Re: allow line break at operators Yingjie Lan <lanyjie@yahoo.com> - 2011-08-10 06:19 -0700
          Re: allow line break at operators Chris Angelico <rosuav@gmail.com> - 2011-08-10 16:56 +0100
            Re: allow line break at operators Seebs <usenet-nospam@seebs.net> - 2011-08-10 17:55 +0000
              Re: allow line break at operators Ben Finney <ben+python@benfinney.id.au> - 2011-08-11 07:51 +1000
                Re: allow line break at operators Chris Angelico <rosuav@gmail.com> - 2011-08-10 23:42 +0100
                  Re: allow line break at operators Neil Cerutti <neilc@norwich.edu> - 2011-08-11 14:40 +0000
                Re: Python & Sullivan Tim Chase <python.list@tim.thechases.com> - 2011-08-10 18:26 -0500
                  Re: Python & Sullivan Ben Finney <ben+python@benfinney.id.au> - 2011-08-11 10:57 +1000
                Re: Python & Sullivan Chris Angelico <rosuav@gmail.com> - 2011-08-11 00:54 +0100
                Re: allow line break at operators Seebs <usenet-nospam@seebs.net> - 2011-08-11 04:59 +0000
                  Re: allow line break at operators Ben Finney <ben+python@benfinney.id.au> - 2011-08-11 15:56 +1000
                    Re: allow line break at operators Seebs <usenet-nospam@seebs.net> - 2011-08-11 21:19 +0000
                      Re: allow line break at operators Chris Angelico <rosuav@gmail.com> - 2011-08-12 00:58 +0100
                        Re: allow line break at operators Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-12 11:40 +1000
                          Re: allow line break at operators Chris Angelico <rosuav@gmail.com> - 2011-08-12 08:09 +0100
                          Re: allow line break at operators Neil Cerutti <neilc@norwich.edu> - 2011-08-12 12:57 +0000
                          Re: allow line break at operators Thomas Rachel <nutznetz-0c1b6768-bfa9-48d5-a470-7603bd3aa915@spamschutz.glglgl.de> - 2011-08-12 14:54 +0200
                          Re: allow line break at operators Tim Roberts <timr@probo.com> - 2011-08-14 22:22 -0700
                      Re: allow line break at operators Ben Finney <ben+python@benfinney.id.au> - 2011-08-12 18:59 +1000
                        Re: allow line break at operators Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-12 20:40 +1000
                          Re: allow line break at operators Ben Finney <ben+python@benfinney.id.au> - 2011-08-12 21:16 +1000
                        Re: allow line break at operators Seebs <usenet-nospam@seebs.net> - 2011-08-12 16:33 +0000
                  Re: allow line break at operators Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-11 22:29 +1000
                    Re: allow line break at operators Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-11 22:40 +1000
                      Re: allow line break at operators Seebs <usenet-nospam@seebs.net> - 2011-08-11 21:19 +0000
                    Re: allow line break at operators Seebs <usenet-nospam@seebs.net> - 2011-08-11 21:19 +0000
                      Re: allow line break at operators Ethan Furman <ethan@stoneleaf.us> - 2011-08-11 15:43 -0700
                        Re: allow line break at operators Seebs <usenet-nospam@seebs.net> - 2011-08-12 06:34 +0000
                          Re: allow line break at operators Chris Angelico <rosuav@gmail.com> - 2011-08-12 08:20 +0100
                            Re: allow line break at operators rantingrick <rantingrick@gmail.com> - 2011-08-12 08:33 -0700
                              Re: allow line break at operators Chris Angelico <rosuav@gmail.com> - 2011-08-12 20:52 +0100
                            Re: allow line break at operators Seebs <usenet-nospam@seebs.net> - 2011-08-12 16:33 +0000
                          Re: allow line break at operators Ben Finney <ben+python@benfinney.id.au> - 2011-08-12 20:39 +1000
                            Re: allow line break at operators Chris Rebert <clp2@rebertia.com> - 2011-08-12 10:03 -0700
                              Re: allow line break at operators Seebs <usenet-nospam@seebs.net> - 2011-08-12 18:37 +0000
                            Re: allow line break at operators Seebs <usenet-nospam@seebs.net> - 2011-08-12 16:33 +0000
                              Re: allow line break at operators Chris Angelico <rosuav@gmail.com> - 2011-08-12 21:01 +0100
                                Re: allow line break at operators Seebs <usenet-nospam@seebs.net> - 2011-08-12 21:06 +0000
                          Re: allow line break at operators rantingrick <rantingrick@gmail.com> - 2011-08-12 08:26 -0700
                            Re: allow line break at operators Seebs <usenet-nospam@seebs.net> - 2011-08-12 16:33 +0000
                              Re: allow line break at operators rantingrick <rantingrick@gmail.com> - 2011-08-12 10:57 -0700
                                Re: allow line break at operators Chris Angelico <rosuav@gmail.com> - 2011-08-12 21:09 +0100
                                  Re: allow line break at operators Seebs <usenet-nospam@seebs.net> - 2011-08-12 21:06 +0000
                                    Re: allow line break at operators Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-13 08:39 +1000
                                      Re: allow line break at operators Chris Angelico <rosuav@gmail.com> - 2011-08-12 23:50 +0100
                                        Re: allow line break at operators Ben Finney <ben+python@benfinney.id.au> - 2011-08-13 09:19 +1000
                                      Re: allow line break at operators Tim Chase <python.list@tim.thechases.com> - 2011-08-12 18:53 -0500
                                      Re: allow line break at operators Seebs <usenet-nospam@seebs.net> - 2011-08-13 00:39 +0000
                                        Re: allow line break at operators Ben Finney <ben+python@benfinney.id.au> - 2011-08-13 10:57 +1000
                                          Re: allow line break at operators Seebs <usenet-nospam@seebs.net> - 2011-08-13 02:34 +0000
                                        Re: allow line break at operators rantingrick <rantingrick@gmail.com> - 2011-08-13 18:50 -0700
                                        Re: allow line break at operators rantingrick <rantingrick@gmail.com> - 2011-08-13 19:07 -0700
                                        Re: allow line break at operators rantingrick <rantingrick@gmail.com> - 2011-08-13 18:59 -0700
                                        Re: allow line break at operators Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-14 17:10 +1000
                                          Re: allow line break at operators Seebs <usenet-nospam@seebs.net> - 2011-08-14 08:07 +0000
                                            Re: allow line break at operators Ben Finney <ben+python@benfinney.id.au> - 2011-08-14 19:25 +1000
                                            Re: allow line break at operators Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-15 00:26 +1000
                                              Re: allow line break at operators Roy Smith <roy@panix.com> - 2011-08-14 11:35 -0400
                                                Re: allow line break at operators Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-15 03:24 +1000
                                                Re: Re: allow line break at operators Dave Angel <davea@ieee.org> - 2011-08-14 17:46 -0400
                                                  Re: allow line break at operators Roy Smith <roy@panix.com> - 2011-08-14 18:46 -0400
                                                    Re: allow line break at operators Chris Angelico <rosuav@gmail.com> - 2011-08-15 00:02 +0100
                                              Re: allow line break at operators Chris Angelico <rosuav@gmail.com> - 2011-08-14 16:39 +0100
                                                Re: allow line break at operators Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-15 03:26 +1000
                                              Re: allow line break at operators Seebs <usenet-nospam@seebs.net> - 2011-08-14 19:01 +0000
                                                Re: allow line break at operators Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-15 11:54 +1000
                                                  Re: allow line break at operators Chris Rebert <clp2@rebertia.com> - 2011-08-14 19:10 -0700
                                                    Re: allow line break at operators Seebs <usenet-nospam@seebs.net> - 2011-08-15 04:28 +0000
                                                      Re: allow line break at operators Tim Chase <python.list@tim.thechases.com> - 2011-08-15 06:40 -0500
                                                      Re: allow line break at operators Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-15 23:30 +1000
                                                        Re: allow line break at operators Seebs <usenet-nospam@seebs.net> - 2011-08-15 16:32 +0000
                                                        Re: allow line break at operators alex23 <wuwei23@gmail.com> - 2011-08-15 21:13 -0700
                                                          Re: allow line break at operators rantingrick <rantingrick@gmail.com> - 2011-08-15 21:37 -0700
                                                            Re: allow line break at operators alex23 <wuwei23@gmail.com> - 2011-08-15 23:49 -0700
                                                              Re: allow line break at operators rantingrick <rantingrick@gmail.com> - 2011-08-16 11:56 -0700
                                                  Re: allow line break at operators Seebs <usenet-nospam@seebs.net> - 2011-08-15 04:28 +0000
                                                    Re: allow line break at operators Terry Reedy <tjreedy@udel.edu> - 2011-08-15 03:31 -0400
                                                      Re: allow line break at operators rantingrick <rantingrick@gmail.com> - 2011-08-15 14:21 -0700
                                                    Re: allow line break at operators Chris Angelico <rosuav@gmail.com> - 2011-08-15 09:27 +0100
                                          Re: allow line break at operators Chris Angelico <rosuav@gmail.com> - 2011-08-14 09:34 +0100
                                            Re: allow line break at operators Ben Finney <ben+python@benfinney.id.au> - 2011-08-14 19:27 +1000
                                              Re: allow line break at operators Ethan Furman <ethan@stoneleaf.us> - 2011-08-14 03:51 -0700
                                              Re: allow line break at operators Chris Angelico <rosuav@gmail.com> - 2011-08-14 12:59 +0100
                                            Re: allow line break at operators Teemu Likonen <tlikonen@iki.fi> - 2011-08-14 12:46 +0300
                                              Re: allow line break at operators Seebs <usenet-nospam@seebs.net> - 2011-08-14 19:01 +0000
                                            Re: allow line break at operators Seebs <usenet-nospam@seebs.net> - 2011-08-14 19:01 +0000
                                          Re: allow line break at operators Chris Rebert <clp2@rebertia.com> - 2011-08-14 01:44 -0700
                                            Re: allow line break at operators Teemu Likonen <tlikonen@iki.fi> - 2011-08-16 07:04 +0300
                                    Re: allow line break at operators rantingrick <rantingrick@gmail.com> - 2011-08-13 19:18 -0700
                                  Re: allow line break at operators Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-08-13 13:19 +1200
                                  Re: allow line break at operators Johann Hibschman <jhibschman+usenet@gmail.com> - 2011-08-15 08:27 -0500
                                  Re: allow line break at operators Roy Smith <roy@panix.com> - 2011-08-15 09:41 -0400
                                    Re: allow line break at operators Chris Angelico <rosuav@gmail.com> - 2011-08-15 15:16 +0100
                                      Re: allow line break at operators Roy Smith <roy@panix.com> - 2011-08-15 20:34 -0400
                                        Re: allow line break at operators Chris Angelico <rosuav@gmail.com> - 2011-08-16 01:37 +0100
                                    Re: allow line break at operators Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-16 00:28 +1000
                                      Re: allow line break at operators Chris Angelico <rosuav@gmail.com> - 2011-08-15 15:42 +0100
                                      Re: allow line break at operators Roy Smith <roy@panix.com> - 2011-08-15 20:30 -0400
                                        Re: allow line break at operators Seebs <usenet-nospam@seebs.net> - 2011-08-16 00:39 +0000
                                      Re: allow line break at operators Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-08-16 12:43 +1200
                                    Re: allow line break at operators Seebs <usenet-nospam@seebs.net> - 2011-08-15 16:32 +0000
                                Re: allow line break at operators Ethan Furman <ethan@stoneleaf.us> - 2011-08-12 13:35 -0700
                                Re: allow line break at operators Seebs <usenet-nospam@seebs.net> - 2011-08-12 21:06 +0000
                              Re: allow line break at operators Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-13 08:03 +1000
                                Re: allow line break at operators Seebs <usenet-nospam@seebs.net> - 2011-08-12 22:14 +0000
                                  Re: allow line break at operators Ben Finney <ben+python@benfinney.id.au> - 2011-08-13 08:36 +1000
                                  Re: allow line break at operators Terry Reedy <tjreedy@udel.edu> - 2011-08-12 20:15 -0400
                                    Re: allow line break at operators Seebs <usenet-nospam@seebs.net> - 2011-08-13 00:44 +0000
                                Re: allow line break at operators rantingrick <rantingrick@gmail.com> - 2011-08-13 18:25 -0700
                              Re: allow line break at operators Ben Finney <ben+python@benfinney.id.au> - 2011-08-13 08:12 +1000
                              RE: allow line break at operators "Prasad, Ramit" <ramit.prasad@jpmorgan.com> - 2011-08-16 15:51 -0400
                  RE: allow line break at operators "Prasad, Ramit" <ramit.prasad@jpmorgan.com> - 2011-08-16 15:26 -0400
                    Re: allow line break at operators Seebs <usenet-nospam@seebs.net> - 2011-08-16 20:19 +0000
                  Re: allow line break at operators Chris Angelico <rosuav@gmail.com> - 2011-08-16 21:05 +0100
              Re: allow line break at operators Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-11 10:32 +1000
                Re: allow line break at operators Chris Angelico <rosuav@gmail.com> - 2011-08-11 01:47 +0100
                Re: allow line break at operators Seebs <usenet-nospam@seebs.net> - 2011-08-11 04:59 +0000
          Re: allow line break at operators Yingjie Lan <lanyjie@yahoo.com> - 2011-08-10 19:52 -0700
            Re: allow line break at operators Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-11 14:18 +1000
              Re: allow line break at operators Chris Rebert <clp2@rebertia.com> - 2011-08-11 00:50 -0700
              Re: allow line break at operators Vito 'ZeD' De Tullio <zak.mc.kraken@libero.it> - 2011-08-11 12:21 +0200
          Re: allow line break at operators Yingjie Lan <lanyjie@yahoo.com> - 2011-08-10 19:58 -0700
          Re: allow line break at operators Chris Rebert <clp2@rebertia.com> - 2011-08-10 21:16 -0700
          Re: allow line break at operators Chris Rebert <clp2@rebertia.com> - 2011-08-10 22:07 -0700
          Re: allow line break at operators Chris Angelico <rosuav@gmail.com> - 2011-08-11 09:24 +0100
          Re: allow line break at operators MRAB <python@mrabarnett.plus.com> - 2011-08-11 14:03 +0100
          Re: [Python-ideas] allow line break at operators Matt Joiner <anacrolix@gmail.com> - 2011-08-12 00:28 +1000
            Re: [Python-ideas] allow line break at operators Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-12 12:32 +1000
          Re: [Python-ideas] allow line break at operators Jakob Bowyer <jkbbwr@gmail.com> - 2011-08-11 16:42 +0100
          Re: [Python-ideas] allow line break at operators Daniel Greenfeld <pydanny@gmail.com> - 2011-08-11 10:04 -0700
          Re: [Python-ideas] allow line break at operators Paul Colomiets <paul@colomiets.name> - 2011-08-11 22:17 +0300
          Re: [Python-ideas] allow line break at operators Devin Jeanpierre <jeanpierreda@gmail.com> - 2011-08-11 17:06 -0400
          Re: [Python-ideas] allow line break at operators Devin Jeanpierre <jeanpierreda@gmail.com> - 2011-08-11 17:29 -0400
          Re: [Python-ideas] allow line break at operators Jim Jewett <jimjjewett@gmail.com> - 2011-08-11 17:39 -0400
          Re: [Python-ideas] allow line break at operators Devin Jeanpierre <jeanpierreda@gmail.com> - 2011-08-11 18:29 -0400
          Re: [Python-ideas] allow line break at operators Matt Joiner <anacrolix@gmail.com> - 2011-09-02 15:33 +1000
            Re: [Python-ideas] allow line break at operators Roy Smith <roy@panix.com> - 2011-09-03 12:59 -0400
          Re: [Python-ideas] allow line break at operators "Stephen J. Turnbull" <stephen@xemacs.org> - 2011-09-02 16:28 +0900
          Re: [Python-ideas] allow line break at operators Guido van Rossum <guido@python.org> - 2011-09-02 12:30 -0700
          Re: [Python-ideas] allow line break at operators "Stephen J. Turnbull" <stephen@xemacs.org> - 2011-09-03 13:38 +0900
          Re: [Python-ideas] allow line break at operators "Stephen J. Turnbull" <stephen@xemacs.org> - 2011-09-03 15:10 +0900
          Re: [Python-ideas] allow line break at operators Terry Reedy <tjreedy@udel.edu> - 2011-09-03 15:01 -0400
          Re: [Python-ideas] allow line break at operators ron3200 <ron3200@gmail.com> - 2011-09-04 10:22 -0500
            Re: allow line break at operators rantingrick <rantingrick@gmail.com> - 2011-09-04 11:08 -0700
        Re: allow line break at operators Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-11 00:37 +1000
          Re: allow line break at operators Chris Angelico <rosuav@gmail.com> - 2011-08-10 16:13 +0100
          Re: allow line break at operators Ian Kelly <ian.g.kelly@gmail.com> - 2011-08-10 09:16 -0600
            Re: allow line break at operators Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-11 09:32 +1000
              Re: allow line break at operators Chris Angelico <rosuav@gmail.com> - 2011-08-11 00:55 +0100

Page 2 of 8 — ← Prev page 1 [2] 3 4 5 6 7 8  Next page →

#11187

Seebs <usenet-nospam@seebs.net> writes:

> On 2011-08-10, Ben Finney <ben+python@benfinney.id.au> wrote:
> > Seebs <usenet-nospam@seebs.net> writes:
> >> On 2011-08-10, Chris Angelico <rosuav@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

[toc] | [prev] | [next] | [standalone]

#11231

On 2011-08-11, Ben Finney <ben+python@benfinney.id.au> wrote:
> 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.

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@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.

[toc] | [prev] | [next] | [standalone]

#11239

On Thu, Aug 11, 2011 at 10:19 PM, Seebs <usenet-nospam@seebs.net> wrote:
> 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

[toc] | [prev] | [next] | [standalone]

#11244

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. 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

[toc] | [prev] | [next] | [standalone]

#11254

On Fri, Aug 12, 2011 at 2:40 AM, Steven D'Aprano
<steve+comp.lang.python@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

[toc] | [prev] | [next] | [standalone]

#11271

On 2011-08-12, Steven D'Aprano
<steve+comp.lang.python@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

[toc] | [prev] | [next] | [standalone]

#11272

Am 12.08.2011 03:40 schrieb Steven D'Aprano:

> The only exception I can think of is *very* early Fortran, and that rightly
> is considered a mistake.

ATARI 800XL. Built-in BASIC, acknowledging every command with "READY". 
Going over it with the cursor results in "ERROR- 6", meaning "no READ 
without DATA"... same as "READ Y".


Thomas, it was a long time ago...

[toc] | [prev] | [next] | [standalone]

#11443

Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:
>
>The only exception I can think of is *very* early Fortran, and that rightly
>is considered a mistake. Fortran 77 used to treat whitespace as always
>optional, so that in Python terms this:
>
>forxinrange(42)
>
>would be parsed as this:
>
>for x in range(42)

Absolutely true, and that led to one of the more famous computing screw-ups
in the early space program.  The author intended to write this:
      DO 10 I=1,8
which, in Fortran, begins a loop that will run 8 times ending at the
statement labeled "10".  In this case, the author mistakenly typed a period
instead of a comma:
      DO 10 I=1.8

That, unfortunately, is a perfectly valid statement that assigns the value
"1.8" to the floating point variable "DO10I", supposedly resulting in the
loss of an unmanned launch vehicle...
-- 
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

[toc] | [prev] | [next] | [standalone]

#11260

Seebs <usenet-nospam@seebs.net> writes:

> On 2011-08-11, Ben Finney <ben+python@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

[toc] | [prev] | [next] | [standalone]

#11266

Ben Finney wrote:

> Likewise, “end of line as end of statement” has caused me and many
> others problems.

I don't understand this. Can you give an example?

Do you mean, "Sometimes I want more code in a single statement than will
comfortably fit in a single line"?



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#11270

Steven D'Aprano <steve+comp.lang.python@pearwood.info> writes:

> Ben Finney wrote:
>
> > Likewise, “end of line as end of statement” has caused me and many
> > others problems.
>
> I don't understand this. Can you give an example?

Many times I have split a line expecting that some bracketing syntax
will cause the statement to continue across the split. I've been wrong,
and the code either gave a SyntaxError or, worse, did something
functional but unintended.

That is a problem only because end-of-line (outside some bracketing
syntax) ends a statement.

My point is that I consider that problem to be at least on par in the
severity of the problems caused by indentation-as-block-syntax. That is,
very small compared with the great benefit of the clean and readable
syntax that results.

-- 
 \     “Not to be absolutely certain is, I think, one of the essential |
  `\                         things in rationality.” —Bertrand Russell |
_o__)                                                                  |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#11288

On 2011-08-12, Ben Finney <ben+python@benfinney.id.au> wrote:
> Seebs <usenet-nospam@seebs.net> writes:
>> I am pretty sure Python is a pretty nice language. However, the
>> indentation thing has screwed me a few times. Furthermore, I know
>> people who like Python a great deal and acknowledge, without much
>> difficulty, that the indentation thing has caused problems or
>> incompatibilities for them.

> Yes. It's caused problems for me too, so I'm not going to deny that.

> This is different from saying ???indentation as block structure??? is a
> problem; that statement is what I disagree with, and what I think most
> respondents who disagree with you are objecting to.

See below; I think I agree with what I meant by it, and disagree with what
you seem to interpret it as.  Your interpretation makes as much sense as mine,
so far as I can tell.

> I don't see anyone making the denials you're referring to there. If I
> did, you would have my support in considering those denials mistaken.

I suspect, thinking about it more, that it's a communications problem.

> Likewise, ???end of line as end of statement??? has caused me and many
> others problems. I'd go so far as to say that any Python programmer for
> whom that's not true has not done any significant Python programming.
> That doesn't make ???end of line as end of statement??? a problem.

True, although it does make it a thing which *has* at least one problem.

> If a language feature is beneficial in far greater proportion to the
> inconveniences of that feature, I'd say that feature *is not a problem*
> for users of that language.

I wouldn't.

Lemme give a concrete example, from C, since that's the language I know best.
There are sound technical reasons for which C lets you manipulate pointers.
If you couldn't, it wouldn't be C, and you couldn't do the bulk of the stuff
that makes C useful.  But...

Pointer manipulation leads to crashes.  LOTS of crashes.  I have never met
a C programmer with over a day or two of experience who has not had a
program crash due to some mishap involving a pointer.

When people say that a language like, say, Java, is trying to solve the
problems of C's pointer system, I think that's a reasonable thing to try to
do.  There are tradeoffs.  But it would be, IMHO, silly to claim that there
are no problems with pointers; there are just benefits which outweigh them
*for the things the language is trying to do*.

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@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.

[toc] | [prev] | [next] | [standalone]

#11209

Seebs wrote:

> 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

[toc] | [prev] | [next] | [standalone]

#11210

Steven D'Aprano wrote:

> 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

[toc] | [prev] | [next] | [standalone]

#11233

On 2011-08-11, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:
> Steven D'Aprano wrote:
>> 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.

My fault, I probably hypnotized you with my bad word choice.  :)

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@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.

[toc] | [prev] | [next] | [standalone]

#11232

On 2011-08-11, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:
> Seebs wrote:

>> 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.

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@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.

[toc] | [prev] | [next] | [standalone]

#11234

Seebs wrote:
>> 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~

[toc] | [prev] | [next] | [standalone]

#11252

Before I get to the rest of this:

Thinking it through, I've been unreasonable and grumpy here, and I'm trying
to figure this out a bit more.

A general observation:  There's no real data here, so far as I can tell.
There is no pair of languages which are exactly identical except for whether
they use whitespace or some kind of brace/bracket/thing to indicate blocks,
such that we can compare results between them.  Humans are *notoriously*
unreliable at evaluating the ease with which they do things, how long it
takes them, how many mistakes they're making, and so on...

So really, this is probably in large part a matter of taste or preference.

On 2011-08-11, Ethan Furman <ethan@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.

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@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.

[toc] | [prev] | [next] | [standalone]

#11256

On Fri, Aug 12, 2011 at 7:34 AM, Seebs <usenet-nospam@seebs.net> wrote:
> If Python with braces wouldn't be Python at all, why on earth does the
> language even exist?

Every language has its philosophy. Python, as conceived by Guido van
Rossum, is a language which (guys, correct me where I'm wrong
please!):

* Eschews unnecessary syntactic salt
* Has "batteries included"
* Has a clean and readable syntax

To achieve this, Python:

* Uses indentation and other whitespace as structural elements (rather
than semicolons, braces, etc)
* Has a large standard library and an enormous PyPI collection
* Uses keywords (and, or, not, if/else) rather than symbols (&, |, !,
?:) for common tasks

Etcetera. These are the philosophical decisions made by GvR and the
Python community, and these define Python's syntax. If you go against
these, you could make something that compiles down to Python's byte
code; in fact, I'd say you could make something that produces a .pyc
file and then hands it to the regular Python interpreter for
execution. Is it Python? No, no more than NetREXX is Java just because
it can make a .class file. It's a different language.

Pike is very similar to Python in underlying structure. You can pass
lists and dictionaries (called arrays and mappings) around as
first-class objects, you can reference objects in multiple places, you
can work with huge integers comfortably. But they're different in
philosophy. Pike's purpose is primarily zero-downtime servers; I can
(and do on a daily basis) update parts of the code of a running
program, without disconnecting clients. Python doesn't do this, and to
make Python do this would violate a lot of its simplicities and
underlying referencings. It can be done without modifying the
interpreter, but it's never been designed in. If you want that
feature, you go to Pike; if you want Python's syntax, you go to
Python.

I hope I make myself clear, Josephine?

ChrisA

[toc] | [prev] | [next] | [standalone]

#11281

On Aug 12, 2:20 am, Chris Angelico <ros...@gmail.com> wrote:

> Pike is very [snip]
> Pike's purpose is [snip]
> you go to Pike[snip]
>
> I hope I make myself clear, Josephine?

The only thing that is clear to me is that you have a hidden agenda to
incorporate pike's functionality into Python -- and this is not the
first time!

Chris, this incessant babbling about "pike this" and "pike that" is
starting to get on my nerves. Why don't you go over to comp.lang.pike
and gush to them about how wonderful the language is.

PS: Although i give you brownie point for sucking up to GvR and the
community at large before hinting about "Esox lucius" greatness. Nice!

[toc] | [prev] | [next] | [standalone]

Page 2 of 8 — ← Prev page 1 [2] 3 4 5 6 7 8  Next page →

Back to top | Article view | comp.lang.python

csiph-web