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

#11467

On 2011-08-15, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:
> Seebs wrote:
>> I tend to write stuff like
>> 
>> foo.array_of_things.sort.map { block }.join(", ")
>> 
>> I like this a lot more than
>> array = foo.array_of_things
>> sorted_array = array.sort()
>> mapped_array = [block(x) for x in sorted_array]
>> ", ".join(mapped_array)

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

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

Nothing in particular; I was just contrasting two styles, not asserting
that Python couldn't do that.

In general, I don't like to do things that either involve making a lot of
variables that are assigned to once and then read from once, or making a
whole lot of x = foo(x) type assignments to one variable.  It feels cluttered
to me.

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

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

Interesting!  I think that's probably why I find them so comfortable;
shell was one of the first languages I got serious about.

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

#11503

Steven D'Aprano <steve+comp.lang.pyt...@pearwood.info> wrote:
> I think I would be less skeptical about fluent interfaces if they were
> written more like Unix shell script pipelines instead of using attribute
> access notation:
>
> foo.array_of_things | sort | map block | join ", "

I've seen at least one attempt to provide this in Python:

http://dev-tricks.net/pipe-infix-syntax-for-python

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

#11505

On Aug 15, 11:13 pm, alex23 <wuwe...@gmail.com> wrote:
> Steven D'Aprano <steve+comp.lang.pyt...@pearwood.info> wrote:
> > I think I would be less skeptical about fluent interfaces if they were
> > written more like Unix shell script pipelines instead of using attribute
> > access notation:
>
> > foo.array_of_things | sort | map block | join ", "
>
> I've seen at least one attempt to provide this in Python:

If you want 100% OOP then use Ruby:

rb> [3,100,-20].sort.join('<#>')
-20<#>3<#>100

Ruby is great from this angle! The reading proceeds naturally from
right to left. I have become accustomed to reading Python's nested
function calls however it does feel much more natural in Ruby. Of
course, there are architectural reasons why Python cannot do this
linear syntactical processing which lends some paradigm-al niceties to
the python programmer that are not available to the Ruby folks.

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

#11512

On Aug 16, 2:37 pm, rantingrick <rantingr...@gmail.com> wrote:
> The reading proceeds naturally from right to left.

Well, "naturally" if you're coding in Hebrew or Japanese perhaps :)

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

#11602

On Aug 16, 1:49 am, alex23 <wuwe...@gmail.com> wrote:
> On Aug 16, 2:37 pm, rantingrick <rantingr...@gmail.com> wrote:
>
> > The reading proceeds naturally from right to left.
>
> Well, "naturally" if you're coding in Hebrew or Japanese perhaps :)

Yes :). I typo-ed that one. It was getting late when i sent that
reply. I did consider posting an edit however i decided not to and
instead, wait and see who would notice.

The map feels much better too as a consequence:

rb> [3,100,-20].map{|x| x.to_f}
[3.0, 100.0, -20.0]

And you can can induce some logic without a clunky lambda.

rb>[3,100,-20].map{|x| if x > 99 then x.to_f else x end}
[3.0, 100.0, -20.0]

in Python you'd have to create a def for that (i know bad "specific"
example but the need is there)

It feels just like a Python list comprehension though:
py> [float(x) for x in [3,100,-20]]

Even though it reads in a non-linear way, you could argue that the
most important part (float(x)). is front-and-center. Of course i like
the compactness of python's map function:

py> map(float, [3,100,-20])

But all too often the map function is insufficient AND you cannot use
map in a chain! If only we could find a happy medium between Python
and Ruby oh what a bliss that would be. We could cut off all of
Pythons warts and destroy all of Rubys multiplicity and "singular
paridigm-ness".

 * Forced indention (exactly one tab, and one tab only!)
 * No multiplicity!
 * Nice linear expressions!
 * Name spaces!
 * Implicit modules!
 * Only "truly heterogeneous" built-in functions allowed!
 * Enough freedom to be expressive, but not enough to allow sloppy-
ness.

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

#11440

On 2011-08-15, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:
>> Interesting!  I tend to really like the ability to chain methods,
>> depending
>> on context.  I find the side-effect/expression mix pretty normal, so I'm
>> used to it.

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

"Risks violating" isn't the same thing as "violates".

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

Yeah.

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

Life is full of tradeoffs.  The editor does a lot of things which very
much improve my performance, with costs which are usually pretty easily
mitigated.

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

> I sympathise, but don't care. That's your problem man, not Python's.

Debatable.  There's a sort of fuzzy boundary between "clearly this is a
defect in the product" (see interfaces that kill), and "clearly this is
a defect in the user".  In fact, one of the major areas of interesting UI
research involves interfaces that accommodate things which are generally
regarded as defects in the user.

Think about colorblindness.  Obviously, it's the user's problem, not the
editor's, but an editor which picks colors which most colorblind people
can't distinguish for something important is going to get castigated for it.

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

I think it depends a lot on the goals.  So far as I can tell, the primary
goal of the policy was to eliminate a class of errors.  It... well, it does
this in a strictly technical sense, in that every error which occurs is no
longer of that class.  It does not seem to me that it's done very much to
turn the kinds of things which used to result in that class of errors into
non-errors; rather, it's turned them into different errors.

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

The point is...

I can't *TELL* what the boundaries of the bad-reindent are.  Because there's
no unambiguous point at which I can say "oh, look, here is the line where
the indentation starts being wrong", unless there's a syntax error... and
even then, the syntax error might be before or after the actual bounds of
the bad indent.

With properly-braced code in a brace language, any mis-indent you do can be
unambiguously identified -- you have a 100% guarantee that you know what
the first and last misindented lines are.  In Python, you can usually guess
within a couple of the lines, more easily if you're familiar with the
code.

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

The case that has historically bitten me is that I move N lines of code, and
then I try to adjust the indentation of those N lines, and... SOMETHING
happens.  Maybe someone somewhere introduced tabs and adding four leading
spaces doesn't do anything.  Maybe I mis-counted N.

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

Not if the only reason that it's hard to follow is that the indentation
is screwed up.

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

> Okay, now I'm confused... if indentation doesn't matter, how is the end
> misaligned?

Indentation doesn't affect the *compiler*, but we know the rules for
indentation.

It's a parity bit.  If the indentation and the begin/end don't agree, then
I *know something is wrong*.  And I know on exactly which line it becomes
wrong.

That turns out to save me a fair bit of time if I have to look at code and
try to figure out what's wrong.

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

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

I think there is some confusion because the word "matter" has more than one
meaning.

Indentation does not control what the compiler does in, say, C or Ruby.  It
does matter to the *reader*.

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

Heh.

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

But they're *not problems* -- unless I'm using Python.  The rest of the time
it's just the ordinary thing where sometimes when you're using a computer you
typo, misclick, or whatever.

Hmm.  Lemme try an analogy.  Imagine, if you will, an editor with the helpful
trait that if you close a window it closes, bang, whether or not anything has
been touched in it.  Your argument here is roughly:

	But if you're going to come here and tell us that Hypothetical Edit
	is less than optimal because it doesn't solve the problems you have
	with your mouse, [...]

Which is to say:  Yes, I usually expect software to be designed to handle
common problems gracefully.

Whether this is "Python's problem" or not is really an incoherent question;
all we can do is talk about what the effects are, and it's up to Guido or
whoever else to decide whether they care.  In terms of language adoption,
it has certainly been a "problem" historically; there are many people who
might have used Python but ended up not doing so because the indentation
thing interacted badly with their other requirements.

I tend not to care much about assigning "blame".  I don't care whether a
tool is correctly designed for someone who isn't me, or is incorrectly
designed, because neither matters.  All that matters is whether I can use
it reasonably easily.  With Python, the single barrier I've encountered
to a pleasant and productive programming experience has been the indentation
thing.  Apart from that it's a language I'd basically get along with.

But, for whatever reason, the net result is that programming in Python is
a perpetual exercise in frustration for me.  I still prefer it to a number
of other languages, but it's always annoying; it's like using a stereo
system that has a persistent high-pitched whine, but otherwise has very good
sound.

> "I can point to a specific character" is not what explicit means.

No, but...

An explicit thing is by definition a thing which is *NOT INFERRED*.

If the same sequence of characters can be one or two tokens, depending
on a sequence of characters twenty lines ago, that looks very much like
something is being *inferred*.  Information external to the sequence of
characters currently being tokenized is being used to determine what
tokens to recognize.

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

The character streams I was talking about don't.

Character stream:  tab tab tab "foo" newline tab "bar".  This is, as you
say, *usually* two dedents, but it could be one.  Same exact stream of
bytes, and yet the newline/tab may be either one or two dedents, or four
if you're working on code where someone has been using four-space indents
but someone happened to convert sets of eight spaces to tabs.

> That difference depends on the context,

My point exactly.  Dedents are constructed from a combination of the current
character stream and information about characters that could easily be
hundreds of tokens back.  That means that they are not explicit in the part
of the character stream where they occur, but are implied by the combination
of that stream of characters with the rest of the stream.

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

#11445

On 8/15/2011 12:28 AM, Seebs wrote:

To repeat again: you are free to put in explicit dedent markers that 
will let you re-indent code should all indents be removed.

-- 
Terry Jan Reedy

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

#11474

On Aug 15, 2:31 am, Terry Reedy <tjre...@udel.edu> wrote:
> On 8/15/2011 12:28 AM, Seebs wrote:
>
> To repeat again: you are free to put in explicit dedent markers that
> will let you re-indent code should all indents be removed.


As Terry has been trying to say for a while now, use the following
methods to quell your eye pain.

------------------------------------------------------------
 Use pass statement:
------------------------------------------------------------

if foo:
    if bar:
        baz
    else:
        pass
else:
    quux

------------------------------------------------------------
 Use comments:
------------------------------------------------------------

if foo:
    if bar:
        baz
    #else bar (or endif or whatever you like)
else:
    quux

------------------------------------------------------------
 Use road signs: :-)
------------------------------------------------------------

# [Warning: Curves Ahead: Eyeball Parse limit 35 WPM!]
if foo: # [Exit 266: "foo"] -->
    # [Right Curve Ahead: slow eyeball parsing to 15 WPM!]
    if bar:
        baz
    else:
        pass # <-- [Warning: Do not litter!]
else: # [Exit 267: "Not Foo"] -->
    # [Right Curve Ahead: slow eyeball parsing to 15 WPM!]
    quux
...
# [Eyeball Parse limit 55 WPM!]
...
# [PSA: Friends don't let friends write asinine code]
...
# [Next Rest Stop: NEVER!]

------------------------------------------------------------

Now you have the nice triangular shape that your eyes have been
trained to recognize! I would suggest to use comments whenever
possible. Of course there will be times when you cannot use a comment
and must use an else clause.

Now you have nothing to complain about :).

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

#11446

On Mon, Aug 15, 2011 at 5:28 AM, Seebs <usenet-nospam@seebs.net> wrote:
> Character stream:  tab tab tab "foo" newline tab "bar".  This is, as you
> say, *usually* two dedents, but it could be one.

I see your point, though I cannot imagine anyone who would use "tab
tab" as an indent level. But if you go from 16 spaces down to 8, it's
possible that the script uses eight space indents, or four.

On Mon, Aug 15, 2011 at 8:31 AM, Terry Reedy <tjreedy@udel.edu> wrote:
> To repeat again: you are free to put in explicit dedent markers that will
> let you re-indent code should all indents be removed.
>

This would be a solution to the above, but it has the feeling of
syntactic salt. (I don't believe that braces are, because they afford
a different form of flexibility.) But sure, if you configure your
editor to do it for you.

I type: if (blah):
It puts:

if (blah):
    |
# << if

with the cursor at the | marker. I never really got used to editors
doing this for me, though. It didn't feel right. I prefer an editor
that deals with my indentation but lets me do the rest; when I hit
enter, it autoindents to either the current indent level or one
greater, depending on whether it "looks like" there ought to be an
indent (which mainly happens when I put a loose { on a line).
Similarly, when I put a } into the file, it removes an indent level
automatically.

Still, it wouldn't be hard to make an editor put those dedent comments
in, if you want them.

ChrisA

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

#11372

On Sun, Aug 14, 2011 at 8:10 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> Do you get worried by books if the last page doesn't include the phrase "The
> End"? These days, many movies include an extra clip following the credits.
> When the clip finishes, and the screen goes dark, how long do you sit
> waiting before you accept that the movie is over?
>
> *wink*
>

You wait for the house lights to come up. That's your ending signal.
As is often said in live theatre: "House lights, warmers, thank you
gentlemen, going off cans!" It still has an end marker.

On Sun, Aug 14, 2011 at 9:07 AM, Seebs <usenet-nospam@seebs.net> wrote:
> I actually really *like* that Ruby and Lua let pretty much everything just
> be an expression.  I was utterly dumbfounded when I found out that "print"
> in Python is a kind of statement, not a function or something comparable.
> (This seems to have changed recentlyish.)

Yes. Not everything's an expression; a block of code is not an
expression that returns a code object, and variable assignment is a
statement. Some day, I'd like to play around with a language where
everything's an expression and yet it doesn't look like LISP - just
for the fun of it. It probably won't be any more useful for real world
coding, but it'd be fun to tinker with.

ChrisA

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

#11377

Chris Angelico <rosuav@gmail.com> writes:

> On Sun, Aug 14, 2011 at 8:10 AM, Steven D'Aprano
> <steve+comp.lang.python@pearwood.info> wrote:

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

> You wait for the house lights to come up. That's your ending signal.

You mean people still watch movies in theatres?

The house lights need to be controlled by someone who knows when the
movie's end signal should be sent. What is our ending signal if we're
watching it from media in our home, and no-one in the house knows when
the movie ends?

-- 
 \          “The best way to get information on Usenet is not to ask a |
  `\               question, but to post the wrong information.” —Aahz |
_o__)                                                                  |
Ben Finney

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

#11379

Ben Finney wrote:
> Chris Angelico <rosuav@gmail.com> writes:
> 
>> On Sun, Aug 14, 2011 at 8:10 AM, Steven D'Aprano
>> <steve+comp.lang.python@pearwood.info> wrote:
> 
>>> Do you get worried by books if the last page doesn't include the
>>> phrase "The End"? These days, many movies include an extra clip
>>> following the credits. When the clip finishes, and the screen goes
>>> dark, how long do you sit waiting before you accept that the movie
>>> is over?
> 
>> You wait for the house lights to come up. That's your ending signal.
> 
> You mean people still watch movies in theatres?

Yup!  Not often, but it's fun once in a while.


> The house lights need to be controlled by someone who knows when the
> movie's end signal should be sent. What is our ending signal if we're
> watching it from media in our home, and no-one in the house knows when
> the movie ends?

If it's a tape, it'll stop, or start rewinding; if it's a DVD it'll go 
back to the open page.  :)

~Ethan~

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

#11417

On Sun, Aug 14, 2011 at 10:27 AM, Ben Finney <ben+python@benfinney.id.au> wrote:
> The house lights need to be controlled by someone who knows when the
> movie's end signal should be sent. What is our ending signal if we're
> watching it from media in our home, and no-one in the house knows when
> the movie ends?
>

If you're watching it from your own media, you'll come to the end of
the file/DVD/whatever and VLC will know. End-of-file is a well-known
condition with well-defined semantics. :)

And in the theatre, there's a definition of the end based on the
origin of the material (the stage manager's script/music score, or
something). Yep, there's always an end marker somewhere.

But we are now hopelessly off topic, I think!

ChrisA

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

#11378

* 2011-08-14T09:34:26+01:00 * Chris Angelico wrote:

> Some day, I'd like to play around with a language where everything's
> an expression and yet it doesn't look like LISP - just for the fun of
> it. It probably won't be any more useful for real world coding, but
> it'd be fun to tinker with.

Of course it's a useful feature. Basically you can put any Lisp code in
the world in the place of a Lisp expression.


    (setf variable (handler-case (some-code)
                     (foo-error () "value 1")
                     (bar-error () "value 2")))


is something like


    variable = try:
                   return some_code()
               except FooError:
                   return "value 1"
               except BarError:
                   return "value 2"


Sure, it's not a necessary feature. All we need is the machine language,
but other than that there are differences in how languages let
programmers express themselves. The above example emphasizes that
"'variable' is being assigned". The "how" part gets less weight. If we
put the assignment inside the handler-case or try-except forms we get
the same result technically but the variable assignment becomes more
hidden and is repeated, possibly several times.

I understand that Python philosophy does not value freedom of expression
that much. It values a general Pythonic rule which must obeyed and is
called "readability". Other languages give too little or too much
freedom. :-)

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

#11411

On 2011-08-14, Teemu Likonen <tlikonen@iki.fi> wrote:
> I understand that Python philosophy does not value freedom of expression
> that much. It values a general Pythonic rule which must obeyed and is
> called "readability". Other languages give too little or too much
> freedom. :-)

There is an interesting tradeoff, there, because I tend to find stuff
like "variable = {fancy if expression}" to be much *more* readable, since
I immediately get the top-level information ("we're assigning variable")
and then I can look for details if I care.

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

#11409

On 2011-08-14, Chris Angelico <rosuav@gmail.com> wrote:
> Yes. Not everything's an expression; a block of code is not an
> expression that returns a code object, and variable assignment is a
> statement. Some day, I'd like to play around with a language where
> everything's an expression and yet it doesn't look like LISP - just
> for the fun of it. It probably won't be any more useful for real world
> coding, but it'd be fun to tinker with.

Ruby and Lua are both pretty close.  I'm not an expert in either, but I
can't think of anything I can write in Ruby which isn't an expression.

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

#11375

On Sun, Aug 14, 2011 at 1:34 AM, Chris Angelico <rosuav@gmail.com> wrote:
<snip>
> Yes. Not everything's an expression; a block of code is not an
> expression that returns a code object, and variable assignment is a
> statement. Some day, I'd like to play around with a language where
> everything's an expression and yet it doesn't look like LISP - just
> for the fun of it. It probably won't be any more useful for real world
> coding, but it'd be fun to tinker with.

I've heard that Dylan is supposedly Lisp, sans parens.
http://en.wikipedia.org/wiki/Dylan_(programming_language)

Cheers,
Chris

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

#11502

* 2011-08-14T01:44:05-07:00 * Chris Rebert wrote:

> I've heard that Dylan is supposedly Lisp, sans parens.
> http://en.wikipedia.org/wiki/Dylan_(programming_language)

It has copied/derived many features from Lisps but it's not a dialect of
Lisp because of the syntax and its consequences.

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

#11365

On Aug 12, 4:06 pm, Seebs <usenet-nos...@seebs.net> wrote:
> On 2011-08-12, Chris Angelico <ros...@gmail.com> wrote:
>
> > Why is left-to-right inherently more logical than
> > multiplication-before-addition?
>
> I'd say it's certainly "more Pythonic in a vacuum".
> Multiplication-before-addition, and all the related rules, require
> you to know a lot of special rules which are not visible in the
> code, and many of which have no real logical basis.  Left-to-right
> is, if nothing else, the way the majority of us read.
>
> The problem is that since everyone's used precedence before, not using
> it violates the principle of least astonishment.

And repeatedly propagating a foolish consistency is well, FOOLISH!

This problem invades every aspect of technology. Who was the idiot
that decided it was okay to close SOME html tag and NOT close others?
Since HTML is made to be read by machines why the hell would someone
knowingly induce disorder? Which then leads to needing more logic to
parse?

But even more insane is why HTML has been allowed to be so disorderly
for so long. Where is the need to be consistent? I tell you how to
solve this, you solve it with plagues. Plagues of syntax errors will
teach the unrighteous the err of their ways.

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

#11329

Chris Angelico wrote:

> But both of these violate XKCD 859.

For the benefit of all those who just went off to read
that strip, here's something to help you unwind:

)

There, you can relax now.

-- 
Greg

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

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

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

csiph-web