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 4 of 8 — ← Prev page 1 2 3 [4] 5 6 7 8  Next page →

#11361

On Aug 12, 7:39 pm, Seebs <usenet-nos...@seebs.net> wrote:

> Well, that's the thing.
>
> In a case like:
>
>         if foo:
>                 if bar:
>                         blah
>         blah
>
> I notice that *NOTHING* lines up with "if bar:".  And that affects me
> about the way unmatched brackets do.

For me, i believe it was a grave mistake to allow "user defined
indention" within a python module. Not only that, but allowing
indentation to be inconsistent (within the same module) not only
worse, it's insane!

I could have "slightly" understood giving people a choice of how many
indents to use however i cannot fathom the idiocy of allowing
inconsistent indentation within the same module! Although GvR is no
doubt a brilliant mind he keeps making the same mistakes over and over
again in the name of muti-stylism. ¡Ay, caramba!

Not that i find it *impossible* to read inconsistent indentation mind
you, but that i find it blasphemous to the name of consistency.
Programming languages MUST be consistent. Python should allow one and
only one obvious way to indent a block; whether it be by a single tab
char or by four spaces i don't care! But for crikey's sake pick one of
them and stick with it!!!

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

#11362

On Aug 12, 7:39 pm, Seebs <usenet-nos...@seebs.net> wrote:

> I was overjoyed when I saw that Ruby would let me write 1_048_576.

I'll have to admit that Ruby has a few very interesting ideas, this
being one of them. We all know how impossible it can be to eyeball
parse a very long number like this. Having the interpretor ignore
underscores in a number was very wise indeed!

However i really hate the fact that Ruby FORCES you to use OOP. I LOVE
OOP, however there are times when you just don't need that level of
machinery to solve a problem. A good example is when scripting an API.
Most times all you need is a few module level procedures and some
simple logic. Try that with Ruby, then try that with Python, you'll be
switching to Python in no time!

PS: And before any Matz lovers start complaining: Yes, i know you can
do procedural programming with ruby HOWEVER it suffers many pitfall
due to (1) Ruby's scoping issues and (2) Ruby's explicit module
declaration (which is more indirect than the first).

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

#11364

On Aug 12, 7:39 pm, Seebs <usenet-nos...@seebs.net> wrote:

> Consider the hypothetical array syntax:
>
>         a = [
>             1,
>             2
>         b = [
>             3,
>             4
>
> This *bugs* me.  It's perfectly legible, and if you define it that way, it's
> unambiguous and everything, but... It bugs me.  I want beginnings to have
> an actual corresponding end.

It "almost" seems as if you have a valid point here until you consider
that conditionals and blocks are ridged structures that must be
defined under a strict set of syntactical rules with keywords and
indentation. Whereas the list, dict, set, and tuple absolutely MUST
have an explicit beginning AND an explicit end due to their free-form
nature. You could create some strict rules for defining "X-literals"
and remove any need for start and end tags however i see no need to do
so.

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

#11368

Seebs wrote:

> I guess... The parser is explicitly pushing those tokens, but I can't
> *SEE* those tokens.  If I am looking at the end of a really long
> thing, and I see:
> 
>                         blah
>         blah
> 
> I only know what's happening if I have absolute confidence that the
> indentation is always by the same amount, etectera.

I believe this is a dubious argument. With only two lines of code in
isolation, understanding the indentation changes is the least of your
worries. Adding block delimiters doesn't give you any significant help --
ESPECIALLY if the block delimiters don't align with the indentation!

                        blah
 }
        blah
                                }


In isolation, you don't even know whether the above is syntactically valid,
since you have no way of knowing that either end brace is closing an open
brace or not. 

"Who would write such a horrible mis-aligned piece of code?" Good question.
If you're going to have style-guides that prohibit writing code like the
above, then what exactly do the braces give you?

Yes, yes, if you paste the code into a web forum the indentation may
disappear, and if your hard drive controller is faulty it may randomly
overwrite blocks with data belonging to other files. We all agree that
environments that destroy data are Bad.


>> Yet another reason to consider brace languages harmful: they spoil the
>> user's intuitive grasp of intuition as grouping.
> 
> I assume you mean "indentation as grouping".

Yes, sorry about that.


> I'm... not sold on this.  It's not that I don't see indentation as a kind
> of grouping.  It's just that I really, really, want groups to have ends.
> 
> Consider the hypothetical array syntax:
> 
>         a = [
>             1,
>             2
>         b = [
>             3,
>             4
>
> This *bugs* me.  It's perfectly legible, and if you define it that way,
> it's
> unambiguous and everything, but... It bugs me.  I want beginnings to have
> an actual corresponding end.

Do you get worried by books if the last page doesn't include the phrase "The
End"? These days, many movies include an extra clip following the credits.
When the clip finishes, and the screen goes dark, how long do you sit
waiting before you accept that the movie is over?

*wink*

The above example bugs me too, because it is too close to what I'm used to
in Python. I see an open bracket, I wait for a close bracket. Perhaps this
would be better:

a = array 
    1, 
    2,
b = array 
    3, 
    4,

Not so bad now, I betcha. And you can nest arrays:

c = array 
    5, 
    6,
    array
         7,
         8,
    9,

Now, I wouldn't actually recommend such a syntax for a programming language.
(Maybe for a config file format?) It's too big and awkward for array
literals in an expression. You can partly fix that by making the whitespace
optional, allowing an array to be written on one line:

a = array 1, 2
b = array 3, 4

but that screws up the ability to nest arrays. Also, what happens here?

spam(a, b, array 5, 6)

That's ambiguous -- does spam have three arguments or four? Again, easy
enough to fix:

spam(a; b; array 5; 6)  # four args

but you still can't nest arrays. This potential syntax doesn't feel like a
unified whole, but like a bunch of unrelated fixes for problems. Sometimes
a literal START and END delimiter is the right answer.

Python's use of indentation to delimit blocks doesn't feel like that. Unlike
arrays, you can't use blocks in an expression, and I think that's the
factor which makes all the difference. Ruby folks may call the lack of
block expressions a problem with Python, but even if they're right, I don't
think it's a *big* problem. Either way, given the restriction that blocks
are statements, not expressions, the lack of an overt block markers is not
a problem for code (with the proviso that a rogue editor doesn't go making
arbitrary changes to your source code).



-- 
Steven

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

#11371

On 2011-08-14, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:
> Seebs wrote:
>> I guess... The parser is explicitly pushing those tokens, but I can't
>> *SEE* those tokens.  If I am looking at the end of a really long
>> thing, and I see:
>> 
>>                         blah
>>         blah
>> 
>> I only know what's happening if I have absolute confidence that the
>> indentation is always by the same amount, etectera.

> I believe this is a dubious argument. With only two lines of code in
> isolation, understanding the indentation changes is the least of your
> worries. Adding block delimiters doesn't give you any significant help --
> ESPECIALLY if the block delimiters don't align with the indentation!

>                         blah
>  }
>         blah
>                                 }

Interesting.  I am sort of getting to an insight into this, which I am not
sure I can articulate.

FWIW, I've had to debug C (well, C++) much worse than that (... long story,
but rest assured, the lulz justified the effort of reading the transcendantly
awful code).  I could still do it.  :)

> In isolation, you don't even know whether the above is syntactically valid,
> since you have no way of knowing that either end brace is closing an open
> brace or not. 

Ahh, but the computer can tell me that.  I don't have to see it.

> "Who would write such a horrible mis-aligned piece of code?" Good question.
> If you're going to have style-guides that prohibit writing code like the
> above, then what exactly do the braces give you?

I think what they give me is... basically a parity bit.

It's easy for people to screw up code, such that the code written does not
reflect intent.

Braces give me a likely red flag -- if they are screwed up, I know that this
is a good palce to start looking.  If they're not, then all they're costing me
is a little vertical space.

> Yes, yes, if you paste the code into a web forum the indentation may
> disappear, and if your hard drive controller is faulty it may randomly
> overwrite blocks with data belonging to other files. We all agree that
> environments that destroy data are Bad.

"Destroy data" is a sort of fungible concept.  I was reading a comic book
recently and it contained a URL for a poem which had been parodied.  The
URL had been hand-lettered... in block capitals.  The actual URL had exactly
one upper case letter in it.

Whoops.

In general, I don't think all data-loss is identical in severity.  Outside
of Python and Makefiles, I don't use anything where whitespace damage of
the sort of "losing or changing leading spaces" is usually significant,
so I *normally* regard it as a trivial change.

> Do you get worried by books if the last page doesn't include the phrase "The
> End"? These days, many movies include an extra clip following the credits.
> When the clip finishes, and the screen goes dark, how long do you sit
> waiting before you accept that the movie is over?

> *wink*

It's an actual thing I have been bitten by, especially because I often really
enjoy those clips, and I've seen a movie that had two.

> The above example bugs me too, because it is too close to what I'm used to
> in Python. I see an open bracket, I wait for a close bracket. Perhaps this
> would be better:

> a = array 
>     1, 
>     2,
> b = array 
>     3, 
>     4,

> Not so bad now, I betcha.

Interesting!  For me this triggers the same "WHERE IS THE END MARKER???"
reflex.  These bug me like unmatched brackets.

> but you still can't nest arrays. This potential syntax doesn't feel like a
> unified whole, but like a bunch of unrelated fixes for problems. Sometimes
> a literal START and END delimiter is the right answer.

I think so.

> Python's use of indentation to delimit blocks doesn't feel like that. Unlike
> arrays, you can't use blocks in an expression, and I think that's the
> factor which makes all the difference. Ruby folks may call the lack of
> block expressions a problem with Python, but even if they're right, I don't
> think it's a *big* problem.

I actually really *like* that Ruby and Lua let pretty much everything just
be an expression.  I was utterly dumbfounded when I found out that "print"
in Python is a kind of statement, not a function or something comparable.
(This seems to have changed recentlyish.)

> Either way, given the restriction that blocks
> are statements, not expressions, the lack of an overt block markers is not
> a problem for code (with the proviso that a rogue editor doesn't go making
> arbitrary changes to your source code).

Yeah.  I suspect that if I'd never used something with braces, I might not
mind as much, but the kinds of errors I've had would probably still be issues.

Say I try to indent or outdent something and I grab the wrong set of lines.
It's certainly possible for this to result in valid code... And I have no
cue as to what happened.  Even if I get a warning, I can't necessarily
tell what happened.

To some extent, I think I like braces for the same reason I like to use
ECC memory whenever hardware supports it, and I prefer hardware that
supports it.  Yes, they're only really useful to me when Something Goes
Wrong (or to accommodate my fussy brain), but something goes wrong often
enough that I derive a lot of benefit from that.

Refactoring C or Ruby is easy for me.  Refactoring Python is hard for me.
I really do rely on visible markers to sanity-check the boundaries of what
I'm indenting or outdenting.  If I do something in my editor and end up with:

	foo.each do |bar|
	    bar.do_a_thing
	    do_something_with(bar)
	    end
	next_thing
	something else

I know immediately that it's wrong.

If I do something in my editor and end up with:
	if foo:
	    bar.do_a_thing
	    do_something_with(bar)
	    next_thing
	something else

I can't immediately see that I hit the wrong number key when telling
the editor how many lines to adjust.

Typos happen.  I rely heavily on things that let me catch them in as many
ways as possible.

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

#11376

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

> I was utterly dumbfounded when I found out that "print" in Python is a
> kind of statement, not a function or something comparable. (This seems
> to have changed recentlyish.)

It has long been recognised as a wart, but it required waiting for an
opportunity for breaking backward compatibility (the Python 2 → 3
transition) to fix it.

If you can't yet switch to Python 3, you can explicitly ask for ‘print’
as a function in Python 2.6 or later.

More at <URL:http://wiki.python.org/moin/PrintAsFunction>.

-- 
 \       “The generation of random numbers is too important to be left |
  `\                                    to chance.” —Robert R. Coveyou |
_o__)                                                                  |
Ben Finney

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

#11391

Seebs wrote:

> "Destroy data" is a sort of fungible concept.  I was reading a comic book
> recently and it contained a URL for a poem which had been parodied.  The
> URL had been hand-lettered... in block capitals.  The actual URL had
> exactly one upper case letter in it.
> 
> Whoops.

Er, most URLs are case insensitive, at least the most common ones, including
HTTP and HTTPS. So I don't quite see why you think this was a Whoops.


> In general, I don't think all data-loss is identical in severity.  Outside
> of Python and Makefiles, I don't use anything where whitespace damage of
> the sort of "losing or changing leading spaces" is usually significant,
> so I *normally* regard it as a trivial change.

Ys, nd n rdnry nglsh txt, th lss ar chng af vwls cn olsu b e trvl chng.

But try that with your source code :)


> I actually really *like* that Ruby and Lua let pretty much everything just
> be an expression.  I was utterly dumbfounded when I found out that "print"
> in Python is a kind of statement, not a function or something comparable.
> (This seems to have changed recentlyish.)

Yes, print as a statement was a mistake. But assignment as a statement, not
so much. Assignment as an expression in languages that have it tends to be
associated with frequent errors.

The way I see it, if something operates by side-effect, then it has no
business being treated as an expression. I'm not even happy with the usual
convention of Python functions that return None, such as list.sort() -- in
my opinion, languages should have procedures which don't return anything,
and can only be used as a statement, similar to Pascal procedures.

(I'm prepared to make an exception for purely functional languages.)


> Say I try to indent or outdent something and I grab the wrong set of
> lines. It's certainly possible for this to result in valid code... And I
> have no
> cue as to what happened.  Even if I get a warning, I can't necessarily
> tell what happened.

Then don't do that.

I'm not impressed by arguments based on "but if I do something stupid, like
select text with my eyes closed and reindent it without looking, I expect
the compiler to save my bacon". In my opinion, it's not the compiler's job
to protect you from errors caused by sheer carelessness at the keyboard.

In any case, while reindenting an arbitrary set of lines may *possibly*
result in valid code that runs but does the wrong thing, the likelihood of
that happening is remote enough that I'm not going to lose any sleep over
it. There are real-world scenarios involving such semantic errors involving
indentation, but they're pretty rare. I think that six weeks of not having
to type { } or BEGIN END around code blocks has saved far more time and
effort than such errors have cost me in my entire history of Python
programming.


> Refactoring C or Ruby is easy for me.  Refactoring Python is hard for me.
> I really do rely on visible markers to sanity-check the boundaries of what
> I'm indenting or outdenting.  If I do something in my editor and end up
> with:
> 
>     foo.each do |bar|
>         bar.do_a_thing
>         do_something_with(bar)
>         end
>     next_thing
>     something else
> 
> I know immediately that it's wrong.

How? What makes you so certain that next_thing and something else are
supposed to be inside the loop? They don't even refer to bar. Even if they
did, it's not a foolproof sign, although it is a good hint.

Unless I understand the intent of the code, how can I tell whether the END
token is in the right place or not? And if I understand the intent of the
code, then the END token is redundant.


> If I do something in my editor and end up with:
>     if foo:
>         bar.do_a_thing
>         do_something_with(bar)
>         next_thing
>     something else
> 
> I can't immediately see that I hit the wrong number key when telling
> the editor how many lines to adjust.
> 
> Typos happen.  I rely heavily on things that let me catch them in as many
> ways as possible.

I call that a poor user interface design. If you have to count the number of
lines before applying an edit, instead of selecting a range of text, then
you should stop using a tool that is stuck with a UI from the early 1980s.

Please don't take this as an insult, because it is not meant as one, but it
seems to me from this discussion that you're a more careless coder than I
am[1], and you want more insurance to protect you from your own mistakes.
Braces give you that insurance.

I'm not saying I've never mis-indented a block of code, surely I must have.
But if I did, it was so trivial to fix, and done so rarely, I've forgotten
all about it. Consequently I don't want to pay the cost of that insurance,
as little as it is, because I don't get the benefit of it -- for me, it's
just redundant information that I have to type and read that provides no
real benefit.

And that's why I love Python, because it doesn't make my pay for insurance I
don't need.



[1] For some definition of "careless".


-- 
Steven

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

#11397

In article <4e47db26$0$30002$c3e8da3$5496439d@news.astraweb.com>,
 Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:

> Er, most URLs are case insensitive, at least the most common ones, including
> HTTP and HTTPS. So I don't quite see why you think this was a Whoops.

URLs are most certainly not case insensitive.  Parts of them may be 
(i.e. the scheme and host parts), but not the stuff after the hostname.

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

#11404

Roy Smith wrote:

> In article <4e47db26$0$30002$c3e8da3$5496439d@news.astraweb.com>,
>  Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:
> 
>> Er, most URLs are case insensitive, at least the most common ones,
>> including HTTP and HTTPS. So I don't quite see why you think this was a
>> Whoops.
> 
> URLs are most certainly not case insensitive.  Parts of them may be
> (i.e. the scheme and host parts), but not the stuff after the hostname.

I stand corrected.



-- 
Steven

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

#11418

On 01/-10/-28163 02:59 PM, Roy Smith wrote:
> In article<4e47db26$0$30002$c3e8da3$5496439d@news.astraweb.com>,
>   Steven D'Aprano<steve+comp.lang.python@pearwood.info>  wrote:
>
>> Er, most URLs are case insensitive, at least the most common ones, including
>> HTTP and HTTPS. So I don't quite see why you think this was a Whoops.
> URLs are most certainly not case insensitive.  Parts of them may be
> (i.e. the scheme and host parts), but not the stuff after the hostname.
>
The thing that confuses people is that not only is the part up to and 
through the domain name is case-insensitive, but that simple pages on 
Windows become case-insensitive for the remainder simply because Windows 
is such.

And the same page hosted on Linux would be case sensitive, per 
specification.

The thing I find annoying is a host that decides that if a URL is close 
to an existing URL, it'll fix one or two "typos."  To me, it's either 
right, or it's not.  Don't change     www.mydomain.com/page105.html   
to  www/mydomain.com/page102.html and pretend it's "close enough."

DaveA

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

#11421

In article <mailman.2285.1313358379.1164.python-list@python.org>,
 Dave Angel <davea@ieee.org> wrote:

> > URLs are most certainly not case insensitive.  Parts of them may be
> > (i.e. the scheme and host parts), but not the stuff after the hostname.
> >
> The thing that confuses people is that not only is the part up to and 
> through the domain name is case-insensitive, but that simple pages on 
> Windows become case-insensitive for the remainder simply because Windows 
> is such.

Sure.  But it's only in the most trivial of situations that URLs map in 
any trivial way to file names.

> And the same page hosted on Linux would be case sensitive, per 
> specification.

Well, I certainly could write an HTTP server on Linux which treated 
routes in a case-insensitive way.  For example, if I do a GET on 
http://en.wikipedia.org/wiki/hypertext, I get redirected to 
http://en.wikipedia.org/wiki/Hypertext.  On the other hand, 
http://en.wikipedia.org/WIKI/Hypertext gets me a 404.  It's entirely up 
to the server to do whatever makes sense for that application.

> The thing I find annoying is a host that decides that if a URL is close 
> to an existing URL, it'll fix one or two "typos."  To me, it's either 
> right, or it's not.  Don't change     www.mydomain.com/page105.html   
> to  www/mydomain.com/page102.html and pretend it's "close enough."

Hosts don't decide anything.  Applications running on those hosts decide 
things.  Without knowing the application, it's impossible to say if this 
is the right thing to do or not.

For example, it's good practice that if a URL ever worked in the past, 
you should keep that URL working, even if it becomes "obsolete".  You 
might want to silently return some other page, or redirect the user to 
some other URL.  This keeps bookmarks, existing links, cached search 
results, etc, from going stale.

To use the wikipedia example again, there are lots of redirect entries, 
for other (perhaps incorrect) spellings, and so forth.  For example, 
http://en.wikipedia.org/w/index.php?title=Taboule&redirect=no

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

#11423

On Sun, Aug 14, 2011 at 11:46 PM, Roy Smith <roy@panix.com> wrote:
> In article <mailman.2285.1313358379.1164.python-list@python.org>,
>  Dave Angel <davea@ieee.org> wrote:
>
>> The thing that confuses people is that not only is the part up to and
>> through the domain name is case-insensitive, but that simple pages on
>> Windows become case-insensitive for the remainder simply because Windows
>> is such.
>
> Sure.  But it's only in the most trivial of situations that URLs map in
> any trivial way to file names.

And even then, it plays havoc with caches (both browser and proxy),
which have no way of knowing that http://blah.com/Foo.html and
http://blah.com/foo.html are the same document. (It's not hard to set
up a Windows system to be case sensitive with URLs, or (even easier -
at least with Apache) to have any request with uppercase letters to
instantly redirect to the lower-cased version.) URLs are definitely
case sensitive; any server that

ChrisA

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

#11398

On Sun, Aug 14, 2011 at 3:26 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> Yes, print as a statement was a mistake. But assignment as a statement, not
> so much. Assignment as an expression in languages that have it tends to be
> associated with frequent errors.
>
> The way I see it, if something operates by side-effect, then it has no
> business being treated as an expression.

Wikipedia (that well-known authority) lists among examples of side
effects both "write data to a display or file" and "modify one of its
arguments".

This strongly implies that print() is a function that operates by
side-effect, just as the assignment operator (in languages in which it
is one) does. Treating "a=5" as an expression with the value 5 is no
more relying on side effects than having "print('asdf')" an expression
with the value None.

I believe that print-as-a-function is a Good Thing, mainly because it
can be used as an argument to such as map. Somewhat silly/trivial
example:
msgs=["Hello","World"]
list(map(print,msgs))

I'm aware that assignment-as-an-expression has plenty of risks
associated with it (the main one being the classic C issue of
assignment inside a conditional - a feature that I use frequently
myself, but which trips plenty of people up), which is a strong
argument for its remaining a statement, but side effects isn't on its
own.

ChrisA

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

#11405

Chris Angelico wrote:

> On Sun, Aug 14, 2011 at 3:26 PM, Steven D'Aprano
> <steve+comp.lang.python@pearwood.info> wrote:
>> Yes, print as a statement was a mistake. But assignment as a statement,
>> not so much. Assignment as an expression in languages that have it tends
>> to be associated with frequent errors.
>>
>> The way I see it, if something operates by side-effect, then it has no
>> business being treated as an expression.
> 
> Wikipedia (that well-known authority) lists among examples of side
> effects both "write data to a display or file" and "modify one of its
> arguments".
[...]

Good point. I withdraw my statement about things that operate about
side-effects.



-- 
Steven

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

#11410

On 2011-08-14, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:
> Seebs wrote:
>> "Destroy data" is a sort of fungible concept.  I was reading a comic book
>> recently and it contained a URL for a poem which had been parodied.  The
>> URL had been hand-lettered... in block capitals.  The actual URL had
>> exactly one upper case letter in it.

> Er, most URLs are case insensitive, at least the most common ones, including
> HTTP and HTTPS. So I don't quite see why you think this was a Whoops.

Sort of.  Host names are case insensitive, so far as I can tell "always".
Paths past that are distinctly NOT always case insensitive, and since the
server in question happened to be doing what appear to be "straight path
lookups", it mattered a great deal that you had to downcase all but one of
the letters.  (The obvious technique of downcasing them all failed.)

> Ys, nd n rdnry nglsh txt, th lss ar chng af vwls cn olsu b e trvl chng.

> But try that with your source code :)

Eh, I'm a C programmer, what makes you think I had any vowels to begin with?

> Yes, print as a statement was a mistake. But assignment as a statement, not
> so much. Assignment as an expression in languages that have it tends to be
> associated with frequent errors.

It does.  I'm not sure whether the errors are compensated for by the
expressiveness.  I *think* on the whole they are, but I am honestly not
sure.  I do like gcc's warning for assignment used as a truth value.

> The way I see it, if something operates by side-effect, then it has no
> business being treated as an expression.

Interesting!  I tend to really like the ability to chain methods, depending
on context.  I find the side-effect/expression mix pretty normal, so I'm
used to it.

>> Say I try to indent or outdent something and I grab the wrong set of
>> lines. It's certainly possible for this to result in valid code... And I
>> have no
>> cue as to what happened.  Even if I get a warning, I can't necessarily
>> tell what happened.

> Then don't do that.

If not doing that were a realistic option for me, I'm guessing I'd have
stopped making typos thirty years ago.

> I'm not impressed by arguments based on "but if I do something stupid, like
> select text with my eyes closed and reindent it without looking, I expect
> the compiler to save my bacon". In my opinion, it's not the compiler's job
> to protect you from errors caused by sheer carelessness at the keyboard.

I don't know about "sheer carelessness".  Typos happen.  Typos are not
something you can prevent from happening just by wanting it very much.

> In any case, while reindenting an arbitrary set of lines may *possibly*
> result in valid code that runs but does the wrong thing, the likelihood of
> that happening is remote enough that I'm not going to lose any sleep over
> it.

Ahh, but what about the case where it results in invalid code?  It's not
necessarily obvious which lines need to be moved after that.

>>     foo.each do |bar|
>>         bar.do_a_thing
>>         do_something_with(bar)
>>         end
>>     next_thing
>>     something else

>> I know immediately that it's wrong.

> How?

The "end" is misaligned.  Therefore SOMETHING is wrong.  I don't know what,
but I can be confident that something went wrong.

> Unless I understand the intent of the code, how can I tell whether the END
> token is in the right place or not? And if I understand the intent of the
> code, then the END token is redundant.

The question is not whether it's on the right line.  No amount of indenting or
outdenting can ever break that.  The question is whether I've gotten the
indentation screwed up.

>> If I do something in my editor and end up with:
>>     if foo:
>>         bar.do_a_thing
>>         do_something_with(bar)
>>         next_thing
>>     something else

>> I can't immediately see that I hit the wrong number key when telling
>> the editor how many lines to adjust.

>> Typos happen.  I rely heavily on things that let me catch them in as many
>> ways as possible.

> I call that a poor user interface design. If you have to count the number of
> lines before applying an edit, instead of selecting a range of text, then
> you should stop using a tool that is stuck with a UI from the early 1980s.

You keep telling me to stop using this editor.  I have not seen a suggested
improvement.  (Hint:  GUI editors are not an improvement for my purposes,
as I do about 99.5% of my editing on machines that aren't in the same state
that I am.  No, the GUI editor cannot offer enough improvement in anything
to justify the cost of copying files back and forth constantly.)

> Please don't take this as an insult, because it is not meant as one, but it
> seems to me from this discussion that you're a more careless coder than I
> am[1], and you want more insurance to protect you from your own mistakes.
> Braces give you that insurance.

I have really, really, bad ADHD.  When I was a kid a firecracker blew up in
my hand because I *forgot* I was holding it.

I'm not exactly "careless" in the pejorative sense (I don't accept
the implication that it's a character flaw, but I don't think you
intended it either), but functionally, I will make DOZENS of tiny
errors per hour, and yes, I rely on having insurance against them.
I don't really get a vote in this; I can either have insurance
against them, never program at all, or spend a whole bunch of time
trying to figure out what happened.

> And that's why I love Python, because it doesn't make my pay for insurance I
> don't need.

I think that's pretty much the thing.  I regard the "cost" of the insurance
as completely nugatory, and I can identify dozens of times when it's saved
me hours of effort on debugging code, whether mine or someone else's.  And
in general, I am a HUGE fan of things that offer a bit of insurance against
otherwise-minor errors.

If something can make a potentially severe problem into a trivial problem,
that's usually a big attraction to me.

So I think there are a couple of big personal-style questions influencing
this.

1.  Preference for "insurance"-type syntax -- stuff that may not be useful
most of the time but will occasionally prevent failures.
2.  Likelihood of "minor" formatting errors either in your direct work or
in your larger environment (say, people mailing you code, use of web
forum software, etc.)
3.  General preferences for how things are structured.

I strongly prefer explicit matching markers, and by "explicit" I mean *actual
symbols you can see*.  The way in which I view indentation as non-explicit
is as follows:

	if foo:
		if bar:
			baz
	quux

	if foo:
			baz
	quux

The two-tab outdent is either one or two outdents.  I can't point to a
specific character and say "this is *one* outdent".  So it's not explicit.
I really don't see why people insist on calling it explicit; it seems
utterly unambiguous to me that it's not.  I think... I mean, the thing
about design philosophy, when you have several design philosophy rules, is
that NONE of the rules get followed all the time.  I think it'd be much
more effective to say that one of the other rules won in this case than to
try to convince people that a variable number of tokens occurring with no
difference at all in the character stream is "explicit".

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

#11433

Seebs wrote:

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

>> The way I see it, if something operates by side-effect, then it has no
>> business being treated as an expression.

Which I later withdrew.

> Interesting!  I tend to really like the ability to chain methods,
> depending
> on context.  I find the side-effect/expression mix pretty normal, so I'm
> used to it.

As a rule, chaining method calls risks violating the Law of Demeter. Just
sayin'.


>>> Say I try to indent or outdent something and I grab the wrong set of
>>> lines. It's certainly possible for this to result in valid code... And I
>>> have no
>>> cue as to what happened.  Even if I get a warning, I can't necessarily
>>> tell what happened.
> 
>> Then don't do that.
> 
> If not doing that were a realistic option for me, I'm guessing I'd have
> stopped making typos thirty years ago.

I feel your pain.

But not all typos are equivalent. There are typos in the content of the
document you are editing, and command typos. There's nothing an editor can
do to prevent the first -- how is the editor supposed to know that you
meant "referrer" rather than "referer"? And because it didn't, now we're
stuck with a %*$%@&! spelling error forever.

But a good editor can minimise command typos. User interfaces matter. If
your car required you to reach over your left shoulder and pull a lever in
order to slow down, it would be a really bad design. It would join these
interfaces:

http://www.asktog.com/columns/027InterfacesThatKill.html
http://www.useit.com/alertbox/20050411.html

If your editor doesn't help you minimise bad commands, then your editor
doesn't work for you, it works against you.


>> I'm not impressed by arguments based on "but if I do something stupid,
>> like select text with my eyes closed and reindent it without looking, I
>> expect the compiler to save my bacon". In my opinion, it's not the
>> compiler's job to protect you from errors caused by sheer carelessness at
>> the keyboard.
> 
> I don't know about "sheer carelessness".  Typos happen.  Typos are not
> something you can prevent from happening just by wanting it very much.

I sympathise, but don't care. That's your problem man, not Python's. Python
has a design philosophy that doesn't match your needs precisely. Oh well,
no language can be all things to all people. If you try, you get Perl, and
you still fail, because your language doesn't meet the needs of people
looking for something that isn't Perl *wink*

I hope you can still be productive in Python, and it's not like anyone
*wants* you to stop using Python and use another language, but you have to
understand that Python wasn't designed for *your* needs precisely. That
doesn't make indentation as syntax a bad choice.


>> In any case, while reindenting an arbitrary set of lines may *possibly*
>> result in valid code that runs but does the wrong thing, the likelihood
>> of that happening is remote enough that I'm not going to lose any sleep
>> over it.
> 
> Ahh, but what about the case where it results in invalid code?  It's not
> necessarily obvious which lines need to be moved after that.

Are you talking about code you've moved from somewhere else and need to
reindent? Then if the code was working before, it will keep working if you
have the same relative indentation. (At least indentation-wise. It may
break due to other factors.) Revert your bad reindent and try again, more
carefully this time.

If you're making semantic changes to the code, not just a simple move, then
surely you understand what changes you're making and not just randomly
indenting and dedenting until it complies? Read the code and decide how to
fix it.

I get it that sometimes there will be code which is hard to follow and hard
to edit. But if that's the case, you've got more maintenance problems than
indentation, and indents are the least of your problems.

 
>>>     foo.each do |bar|
>>>         bar.do_a_thing
>>>         do_something_with(bar)
>>>         end
>>>     next_thing
>>>     something else
> 
>>> I know immediately that it's wrong.
> 
>> How?
> 
> The "end" is misaligned.  Therefore SOMETHING is wrong.  I don't know
> what, but I can be confident that something went wrong.

Okay, now I'm confused... if indentation doesn't matter, how is the end
misaligned? You could write this, and it would still work the same, yes?

foo.each do |bar|
 bar.do_a_thing
                    do_something_with(bar)
              end
    next_thing
           something else


>> Unless I understand the intent of the code, how can I tell whether the
>> END token is in the right place or not? And if I understand the intent of
>> the code, then the END token is redundant.
> 
> The question is not whether it's on the right line.  No amount of
> indenting or
> outdenting can ever break that.  The question is whether I've gotten the
> indentation screwed up.

But if indentation doesn't matter, you can't screw it up. Isn't that the
whole point of this discussion?


[...]
> You keep telling me to stop using this editor.  I have not seen a
> suggested improvement.

There's only one editor worth using. The standard Unix editor, ed.

http://www.gnu.org/fun/jokes/ed.msg.html

*wink*

Your editor is not my problem. But if you're going to come here and tell us
that Python is less than optimal because it doesn't solve the problems you
have with your editor, the obvious answer is that it is not Python's
responsibility to minimise the harm caused when you indent 7 lines instead
of 8, and if your editor encourages you to make mistakes, perhaps you need
another editor.

I have no idea if that editor even exists. Perhaps you need to write it
yourself.



[...]
> The two-tab outdent is either one or two outdents.  I can't point to a
> specific character and say "this is *one* outdent".  So it's not explicit.

"I can point to a specific character" is not what explicit means. The
outdent is defined by a change of indentation level. You had 8 spaces, now
you have 4. That delta is real. Just because the glyph for spaces is
transparent doesn't make it less real, and just because the delta is -4
spaces also doesn't make it less real.

To start a new block in C, I type { and then type } to end it. Explicit. To
start a new block in Python, I type TAB, and then SHIFT-TAB to end it. This
is also explicit.



> I think... I mean, the thing 
> about design philosophy, when you have several design philosophy rules, is
> that NONE of the rules get followed all the time.  I think it'd be much
> more effective to say that one of the other rules won in this case than to
> try to convince people that a variable number of tokens occurring with no
> difference at all in the character stream is "explicit".

The character stream does have a difference.

TAB TAB TAB foo

is different from 

TAB foo

That difference depends on the context, but is usually two dedents.



-- 
Steven

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

#11435

On Sun, Aug 14, 2011 at 6:54 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> Seebs wrote:
<snip>
>> Interesting!  I tend to really like the ability to chain methods,
>> depending
>> on context.  I find the side-effect/expression mix pretty normal, so I'm
>> used to it.
>
> As a rule, chaining method calls risks violating the Law of Demeter. Just
> sayin'.

Not in the specific case of fluent interfaces[1] though, which could
have been what Seebach had in mind.
Whether fluent interfaces are a good idea...

Cheers,
Chris
--
[1] http://en.wikipedia.org/wiki/Fluent_interface

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

#11442

On 2011-08-15, Chris Rebert <clp2@rebertia.com> wrote:
> On Sun, Aug 14, 2011 at 6:54 PM, Steven D'Aprano
><steve+comp.lang.python@pearwood.info> wrote:
>> As a rule, chaining method calls risks violating the Law of Demeter. Just
>> sayin'.

> Not in the specific case of fluent interfaces[1] though, which could
> have been what Seebach had in mind.

They're the most obvious example, from my point of view.

I tend to write stuff like

	foo.array_of_things.sort.map { block }.join(", ")

I like this a lot more than
	array = foo.array_of_things
	sorted_array = array.sort()
	mapped_array = [block(x) for x in sorted_array]
	", ".join(mapped_array)

(I am still not used to Python's attachment of join to strings rather
than to arrays.  I don't really object to it, it's just not how I think
about join operations.)

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

#11453

On 08/14/2011 11:28 PM, Seebs wrote:
> I tend to write stuff like
>
> 	foo.array_of_things.sort.map { block }.join(", ")
>
> I like this a lot more than
> 	array = foo.array_of_things
> 	sorted_array = array.sort()
> 	mapped_array = [block(x) for x in sorted_array]
> 	", ".join(mapped_array)

If you like the one-liner, this is readily written as

   ", ".join(block(x) for x in sorted(foo.array_of_things))

Modulo your gripes about string.join(), this is about as succinct 
(and more readable, IMHO) as your initial example.  I've got 
piles of these sorts of things in my ETL code.

-tkc

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

#11458

Seebs wrote:

> I tend to write stuff like
> 
> foo.array_of_things.sort.map { block }.join(", ")
> 
> I like this a lot more than
> array = foo.array_of_things
> sorted_array = array.sort()
> mapped_array = [block(x) for x in sorted_array]
> ", ".join(mapped_array)

If you insist on a one-liner for four separate operations, what's wrong with
this?

", ".join([block(x) for x in sorted(foo.array_of_things)])

Or if you prefer map:

", ".join(map(block, sorted(foo.array_of_things))


I think I would be less skeptical about fluent interfaces if they were
written more like Unix shell script pipelines instead of using attribute
access notation:

foo.array_of_things | sort | map block | join ", "



-- 
Steven

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

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

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

csiph-web