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

#11300

On Fri, Aug 12, 2011 at 4:33 PM, rantingrick <rantingrick@gmail.com> wrote:
> On Aug 12, 2:20 am, Chris Angelico <ros...@gmail.com> wrote:
>
>> Pike is very [snip]
>> Pike's purpose is [snip]
>> you go to Pike[snip]
>>
>> I hope I make myself clear, Josephine?
>
> The only thing that is clear to me is that you have a hidden agenda to
> incorporate pike's functionality into Python -- and this is not the
> first time!
>
> Chris, this incessant babbling about "pike this" and "pike that" is
> starting to get on my nerves. Why don't you go over to comp.lang.pike
> and gush to them about how wonderful the language is.

Yeah, it's something I've mentioned a few times. I think people have
mentioned C on this list a few times, too; also lisp. Of course, since
this is the Python mailing list (or newsgroup, depending where you
read it), we aren't allowed to mention any other languages at all. Mea
culpa.

I'm not seeking to add Pike's functionality into Python. I want the
two languages to be different, and I want the world to have different
languages. Diversity and choice promote quality in ways that you don't
seem to understand.

Chris Angelico

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

#11290

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

> Every language has its philosophy.

Yes.

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

I would argue that any pure syntactic-sugar change which can be done entirely
by a naive preprocessor does not constitute a significant shift in the
language itself.

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

#11265

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

> Question for y'all:
>
> Has anyone here ever ACTUALLY encountered a case where braces -- not
> indentation -- did not match intent in a C-like language?  I'm talking
> only about cases where braces are *actually present*.

What a strange limitation. Why are you not comparing apples with apples?

The correct comparison would be “getting the braces to match the
intended structure” compared with “getting the indentation to match the
intended structure”.

> The Python community, as a whole, seems particularly dogmatic about
> the indentation thing. And coming here as someone who doesn't much
> like it, and has been bitten by it a few times...

As you say, the data is thin on the ground for this issue. Would you
accept the charge that you're being just as dogmatic about the
superiority of braces-as-block-syntax?

If so, good for you; we're all equally dogmatic by your definition.
Let's move on.

If not, what makes your position less dogmatic than ours?

-- 
 \       “We jealously reserve the right to be mistaken in our view of |
  `\      what exists, given that theories often change under pressure |
_o__)              from further investigation.” —Thomas W. Clark, 2009 |
Ben Finney

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

#11287

On Fri, Aug 12, 2011 at 3:39 AM, Ben Finney <ben+python@benfinney.id.au> wrote:
> Seebs <usenet-nospam@seebs.net> writes:
>
>> Question for y'all:
>>
>> Has anyone here ever ACTUALLY encountered a case where braces -- not
>> indentation -- did not match intent in a C-like language?  I'm talking
>> only about cases where braces are *actually present*.
>
> What a strange limitation. Why are you not comparing apples with apples?
>
> The correct comparison would be “getting the braces to match the
> intended structure” compared with “getting the indentation to match the
> intended structure”.

One argument I've heard from braces fans is that sometimes they want
their own structure, which does not match the actual block structure.
Example:

FILE* f = fopen(...);
    // do stuff with f
    // at this indent level
fclose(f);
// back to normal

But really this is just working around other limitations in the
language (i.e. lack of a with-statement equivalent).

Cheers,
Chris
--
http://rebertia.com

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

#11299

On 2011-08-12, Chris Rebert <clp2@rebertia.com> wrote:
> One argument I've heard from braces fans is that sometimes they want
> their own structure, which does not match the actual block structure.

EWW!

> Example:
>
> FILE* f = fopen(...);
>     // do stuff with f
>     // at this indent level
> fclose(f);
> // back to normal
>
> But really this is just working around other limitations in the
> language (i.e. lack of a with-statement equivalent).

That's horrid.

FWIW, the C idiom is:

	{
		FILE *f = ...
		...
		fclose(f);
	}

It isn't used all that widely, but it is a lot less horrible than
random indenting would be.

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

#11289

On 2011-08-12, Ben Finney <ben+python@benfinney.id.au> wrote:
> Seebs <usenet-nospam@seebs.net> writes:
>> Question for y'all:
>>
>> Has anyone here ever ACTUALLY encountered a case where braces -- not
>> indentation -- did not match intent in a C-like language?  I'm talking
>> only about cases where braces are *actually present*.

> What a strange limitation. Why are you not comparing apples with apples?

I am trying to.  I'm trying to compare C-like languages, with braces, to
Python, with indentation.

> The correct comparison would be ???getting the braces to match the
> intended structure??? compared with ???getting the indentation to match the
> intended structure???.

Right.

I have seen Python programs in which indentation, while it obviously matched
what actually happened, did not match intent.  It is (at least in principle)
easier to debug because you can see that, but...

I've seen people in C do stuff like:

	for (i = 0; i < N; ++i);
		a[i] = 0;

This is clearly a case where indentation matches intent, but doesn't match
functionality, because C allows indentation to not-match functionality; this
is the famous problem Python is solving.

However, I've never, ever, seen a problem like that *when people were using
braces*.

An apples-to-apples comparison between indentation and braces should be a
comparison *to braces*, not to people who "cleverly" omit braces.

(If you are looking for a debate on whether C's optional-braces are a good
idea, I'm afraid you will have to look elsewhere; if it were up to me, I
would totally approve a language change making them mandatory.)

> As you say, the data is thin on the ground for this issue. Would you
> accept the charge that you're being just as dogmatic about the
> superiority of braces-as-block-syntax?

I don't think so.

> If not, what makes your position less dogmatic than ours?

A couple of things.

1.  I do assert that people who are happy with an editor and have been using
it for twenty years ought to change their editor to accommodate a language
which uses braces.
2.  I will happily grant that braces, written legibly, cost you an extra
line per block, and that this space cost can make it harder to see all the
code at once.
3.  I don't have a problem agreeing that there certainly appear to be people
for whom the Python syntax is easier to read.

I think #1 is the real point at which I think there's a dogmatism problem.
Maybe editors shouldn't "helpfully" convert spaces to tabs, but that feature
has been nearly entirely beneficial to me in everything else I've edited
for a long time, and I don't *want* to learn a new editor just for one
language.

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

#11302

On Fri, Aug 12, 2011 at 5:33 PM, Seebs <usenet-nospam@seebs.net> wrote:
> I've seen people in C do stuff like:
>
>        for (i = 0; i < N; ++i);
>                a[i] = 0;
>
> This is clearly a case where indentation matches intent, but doesn't match
> functionality, because C allows indentation to not-match functionality; this
> is the famous problem Python is solving.
>

There's several solutions to this. One is linting utilities that
detect unexpectedly-indented code, which is the concept that Python
took to the logical extent of syntactic errors. Another is (again
linting) to disallow a direct trailing semicolon; if you want an empty
body, you put whitespace before the semicolon.

But that wasn't your point, I realise :)

ChrisA

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

#11310

On 2011-08-12, Chris Angelico <rosuav@gmail.com> wrote:
> On Fri, Aug 12, 2011 at 5:33 PM, Seebs <usenet-nospam@seebs.net> wrote:
>> I've seen people in C do stuff like:

>> ? ? ? ?for (i = 0; i < N; ++i);
>> ? ? ? ? ? ? ? ?a[i] = 0;

>> This is clearly a case where indentation matches intent, but doesn't match
>> functionality, because C allows indentation to not-match functionality; this
>> is the famous problem Python is solving.

> There's several solutions to this. One is linting utilities that
> detect unexpectedly-indented code, which is the concept that Python
> took to the logical extent of syntactic errors. Another is (again
> linting) to disallow a direct trailing semicolon; if you want an empty
> body, you put whitespace before the semicolon.
>
> But that wasn't your point, I realise :)

I think it sort of is.  My current preference would be that C-like languages
would simply absolutely eliminate optional-braces.  Then the whole category
of errors would partially-go-away.  You could still have code which didn't
do what you meant, but it would be reliably easy to see what it did, and
so on.  But it's interesting to note that there are many ways to address
this.

Most of the C I've done has been in circumstances where misindented code
was in fact a thing that would fail reviews.

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

#11280

On Aug 12, 1:34 am, Seebs <usenet-nos...@seebs.net> wrote:
>
> And part of this really is personal taste.  I *LIKE* having a matching outdent
> for everything.  I like to look at code and see
>         blah
>                 blah
>                         blah
>                 blah
>         blah
>
> because then I know it's balanced.  If one of them is missing, *something is
> wrong*.

What is with you guys and this need to have your hand held to read
code. Out-dents are noise and nothing more. When you're driving on a
two lane highway that becomes one lane, would you forget to merge
(OUTDENT) simply because the "merge sign" was missing? If you did then
i would say you need to keep your eyes on the road (CODE) instead of
looking for signs on the side of the road. In other words; you need to
start acting like an intelligent agent instead of a zombie.

> In other language communities, when I find things about the language
> troublesome, I usually find people offering suggestions for ways to improve
> things, or workarounds, or acknowledging that, yes, that can be annoying.
> But for some reason, in this one, that's apparently against a local taboo.
> So instead of acknowledging that it is conceivably possible for people to
> prefer different things, people say things like "oh, once you've done it a
> bit you'll realize how much better it is and then you'll love it".
> Condescending, smug, and, at least so far, *totally untrue* for me.

Well for indention there is no alternatives. There is either indent/
dendent, or suffer the syntax error.

> I am also weirded out by the claim that a Python which used braces would no
> longer be Python in any way, shape, or form.  If you were to make a C
> derivative which used indentation instead of braces (this should be trivial
> to do with a preprocessor), I can't imagine C programmers claiming it's
> "not C".  Of course it's C; it has the C type system, the C operators, the
> C promotion rules, C linkage and scope and so on... That's C.  It's just a C
> variant which tweaks the punctuation.

Hmm, Python's exclusive use of indent/dedent for denoting blocks is
rather unique in a world of braces (barring a few other less known
languages). Removing that feature and replacing it with braces (or
tags or whatever) would change the language significantly!

Likewise allowing a directive like "use braces = True" would also be
detrimental to our code bases. A language must always strive to remove
ambiguities and multiplicity. Having more than one way to mark blocks
is insanity. You never want to induce more overhead than necessary
because such things are detrimental to work flow and language
evolution.

> If Python with braces wouldn't be Python at all, why on earth does the
> language even exist?  If all you want is indentation-which-matters, it's
> super easy to write a preprocessor for ANY language to do that, and you could
> have every last positive feature, benefit, or valuable trait of Python by
> doing that to any other language.

This statement leads me to believe you have very little experience
with the Python language. Python has many wonderful attributes and
design philosophies. Significant indentation is just ONE of many.

> Unless, of course, there are *other* things that are significant
> about Python.  In which case, a language which preserved all of
> those, but used braces, would still be a kind of Python after all.

I don't understand this need for braces. You yearn so badly to be
dominated by them. Is this a psychological disorder, a Helsinki
syndrome that you cannot shake? There is life after braces my friend,
and the future is bright!

> Long story short:  I think the dismissiveness and hostility I've seen from
> people in the Python community towards people who, for *whatever* reason,
> find the indentation-flow-control thing annoying, is not really helping the
> Python community win converts.  

As much as we love people getting on board we are not about to
sacrifice our strong beliefs in clean source code just so you and
other hardwired C programmers will come along. Indentation is at the
very heart of Pythons philosophy. A philosophy that breaks free from
decades old language design build on the detrimental ideals of multi-
stylism. Good languages do not care about your singularly instinctual
emotion needs for bondage, no, they care about productivity and
readability from a community perspective.

PS: I will admit that a few of our community members can be rather
acerbic at times.

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

#11291

On 2011-08-12, rantingrick <rantingrick@gmail.com> wrote:
> What is with you guys and this need to have your hand held to read
> code.

Good question!  Great to see that the helpful and welcoming community
is living up to its reputation.

My brain has quirks.  Some people call them defects, some don't, but it
really doesn't matter; there are things about which my brain is just plain
unreliable and I rely moderately heavily on extra visual cues to reduce
the frequency with which I get things wrong when skimming.

> Out-dents are noise and nothing more.

Not for me.

> When you're driving on a
> two lane highway that becomes one lane, would you forget to merge
> (OUTDENT) simply because the "merge sign" was missing?

No, because the *LANE BOUNDARIES* would move.

> If you did then
> i would say you need to keep your eyes on the road (CODE) instead of
> looking for signs on the side of the road. In other words; you need to
> start acting like an intelligent agent instead of a zombie.

Interesting theory.

I propose we extend it to expression processing in general.  Instead
of writing
	a = (x + y) * z
let's just write
	a = (x + y * z
It's obvious that no one would have needed to introduce parentheses here
unless they wanted to bind the + more closely than the *, so the ) is
just noise and not needed.

> Hmm, Python's exclusive use of indent/dedent for denoting blocks is
> rather unique in a world of braces (barring a few other less known
> languages). Removing that feature and replacing it with braces (or
> tags or whatever) would change the language significantly!

It would, but unless that's the only distinctive trait of the language,
I don't think it would make the language cease to be Python.

> Likewise allowing a directive like "use braces = True" would also be
> detrimental to our code bases. A language must always strive to remove
> ambiguities and multiplicity. Having more than one way to mark blocks
> is insanity. You never want to induce more overhead than necessary
> because such things are detrimental to work flow and language
> evolution.

Agreed.

> This statement leads me to believe you have very little experience
> with the Python language. Python has many wonderful attributes and
> design philosophies. Significant indentation is just ONE of many.

It was a reductio-ad-absurdum.

> I don't understand this need for braces. You yearn so badly to be
> dominated by them. Is this a psychological disorder, a Helsinki
> syndrome that you cannot shake? There is life after braces my friend,
> and the future is bright!

Man, you really love pushing them buttons, don't you?

You don't understand a thing.  Therefore... there is no such thing, anyone
who experiences life differently from you needs to be insulted?

> As much as we love people getting on board we are not about to
> sacrifice our strong beliefs in clean source code just so you and
> other hardwired C programmers will come along.

But you will happily insult people and call them names in order to
keep them from having anything to listen to?

> PS: I will admit that a few of our community members can be rather
> acerbic at times.

Yeah.  And the thing is...  This can't possibly lead to convincing people of
your position, so presumably the purpose is that you don't want anyone who
didn't start out agreeing with you to ever come to agree with you?  Why's
that?

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

#11295

On Aug 12, 11:33 am, Seebs <usenet-nos...@seebs.net> wrote:
>
> My brain has quirks.  Some people call them defects, some don't, but it
> really doesn't matter; there are things about which my brain is just plain
> unreliable and I rely moderately heavily on extra visual cues to reduce
> the frequency with which I get things wrong when skimming.

I think that really boils down to you refusing to open your eyes up to
new ways of doing things. You are clutching the past and it is taking
you down with it. Pry your lips from Ritchie's left teet and stop
slurping that "brace" milk; because it is polluting your mind!

> > When you're driving on a
> > two lane highway that becomes one lane, would you forget to merge
> > (OUTDENT) simply because the "merge sign" was missing?
>
> No, because the *LANE BOUNDARIES* would move.

The "lane boundaries" will also move whilst reading code that uses the
indent/dedent paradigm. Are you honestly telling me that you will skip
over a four spaced dedent without seeing it however you can easily
spot a single closing brace and instantly "know" which corresponding
opener brace to which it referrers without looking, and counting, and
wasting time? Sorry, i just don't believe you.

> I propose we extend it to expression processing in general.  Instead
> of writing
>         a = (x + y) * z
> let's just write
>         a = (x + y * z

I'm glad you brought this up! How about this instead:

    a = x + y * z

...where the calculation is NOT subject to operator precedence? I
always hated using parenthesis in mathematical calculations. All math
should resolve in a linear fashion. 3+3*2 should always be 12 and NOT
9!

> It's obvious that no one would have needed to introduce parentheses here
> unless they wanted to bind the + more closely than the *, so the ) is
> just noise and not needed.

I would even go as far to use a special set of brackets for linear
calculations before using only one, or playing the precedence game.

> > As much as we love people getting on board we are not about to
> > sacrifice our strong beliefs in clean source code just so you and
> > other hardwired C programmers will come along.
>
> But you will happily insult people and call them names in order to
> keep them from having anything to listen to?

I am not trying to discredit you simply by disagreeing with you. I
have offered facts as to why significant indention is far superior to
braces and yet you continue to use the same emotionally charged babble
in your defense. When you offer some real facts then i will give then
just consideration, until then i will "try" to enlighten you of the
merits of significant indentation.

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

#11303

On Fri, Aug 12, 2011 at 6:57 PM, rantingrick <rantingrick@gmail.com> wrote:
> I'm glad you brought this up! How about this instead:
>
>    a = x + y * z
>
> ...where the calculation is NOT subject to operator precedence? I
> always hated using parenthesis in mathematical calculations. All math
> should resolve in a linear fashion. 3+3*2 should always be 12 and NOT
> 9!

Why is left-to-right inherently more logical than
multiplication-before-addition? Why is it more logical than
right-to-left? And why is changing people's expectations more logical
than fulfilling them? Python uses the + and - symbols to mean addition
and subtraction for good reason. Let's not alienate the mathematical
mind by violating this rule. It would be far safer to go the other way
and demand parentheses on everything.

Incidentally, in the original expression, it would be slightly more
sane to write it as:

a = x + y) * z

borrowing from the musical concept that a repeat sign with no
corresponding begin-repeat means to repeat from the beginning. But
both of these violate XKCD 859.

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

#11309

On 2011-08-12, Chris Angelico <rosuav@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.

... Hmm.  There is a thought; I think it may be useful to distinguish
between "Pythonic" and "Pythonic in a vacuum".  That is to say, there
are things which would fit the basic philosophy of Python very well
if previous programming languages and tools were not widespread, and
there are other things which fit anyway.  Using a simple left-to-right
evaluation would probably be easier for people to understand, and
more self-explanatory, *IF* there were no prior art.

> Why is it more logical than
> right-to-left? And why is changing people's expectations more logical
> than fulfilling them?

Well, playing devil's advocate's advocate here... You could argue that
switching from braces to indentation might be "changing" peoples'
expectations, or might be fulfilling them, depending on the people.

I think there's certainly cases where it is probably better to say
"that expectation proves to make it impossible to build a clean
language, so we're going to ask you to do things this way", and cases
where it is probably better to say "that expectation is very deeply
established, and doesn't really hurt the language, so we'll adapt
to you".

> Python uses the + and - symbols to mean addition
> and subtraction for good reason. Let's not alienate the mathematical
> mind by violating this rule. It would be far safer to go the other way
> and demand parentheses on everything.

I wouldn't mind that.

> Incidentally, in the original expression, it would be slightly more
> sane to write it as:
>
> a = x + y) * z
>
> borrowing from the musical concept that a repeat sign with no
> corresponding begin-repeat means to repeat from the beginning. But
> both of these violate XKCD 859.

Yes, yes they do.

Huh.

You know, that's why the outdents-without-symbols bug me; I have a
thing with a colon on it introducing something, and then there's nothing
ending it.  I want that match so I can let the naive stack-depth-counter
off somewhere in my brain do its thing without leaving me with a huge
feeling of unclosed blocks.

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

#11317

Seebs wrote:

> You know, that's why the outdents-without-symbols bug me; I have a
> thing with a colon on it introducing something, and then there's nothing
> ending it.

But there is something ending it: a change in indentation level.

Python's parser explicitly pushes INDENT and OUTDENT tokens into the stream.
They're just a change of state in indentation level, which is much more
easily seen without the need for counting braces. Python's parser may need
to count tokens, but for the human reader merely needs to use its intuitive
and highly accurate ability to notice when things line up.

(Aside: this is why I dislike two-space indents. That's narrow enough to
make the "does this line up" detector subject to too many false positives.)

> I want that match so I can let the naive stack-depth-counter 
> off somewhere in my brain do its thing without leaving me with a huge
> feeling of unclosed blocks.

Yet another reason to consider brace languages harmful: they spoil the
user's intuitive grasp of intuition as grouping.

And it really is intuitive[1]:

http://okasaki.blogspot.com/2008/02/in-praise-of-mandatory-indentation-for.html

Historically, nearly all languages with braces pre-date the widespread
adoption of tools that think they can mangle whitespace with impunity. (I
would say that the reasons that the tools are broken is *because*
programmers have trained themselves to think that whitespace doesn't
matter -- ask most writers or artists and they would say *of course*
whitespace matters. The separation between elements is important -- perhaps
not quite as important as the elements themselves, but still important.)
Explicit BEGIN/END tokens exist to make the job of the parser easier, not
that of the programmer. But the human brain is a funny thing: you can train
it to expect to do more work than is necessary, and it will complain when
you make its job easier.



[1] For some definition of intuition.

-- 
Steven

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

#11318

On Fri, Aug 12, 2011 at 11:39 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> ask most writers or artists and they would say *of course*
> whitespace matters.

You can write Perl code in the shape of a camel. Can you do that in Python?

Okay. Open challenge to anyone. Write a Python script that outputs
"Just another Python hacker" or some such message, and is shaped in
some way appropriately. And no fair doing all the shaping in comments
:)

(Has it already been done?)

ChrisA

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

#11320

Chris Angelico <rosuav@gmail.com> writes:

> On Fri, Aug 12, 2011 at 11:39 PM, Steven D'Aprano
> <steve+comp.lang.python@pearwood.info> wrote:
> > ask most writers or artists and they would say *of course*
> > whitespace matters.
>
> You can write Perl code in the shape of a camel. Can you do that in
> Python?

I'm glad to be using a language where that sort of hard to-read code is
not encouraged by the syntax.

Art is wonderful, if you don't want to communicate clearly. I'll thank
the people who write the programs in my life to save their artistic
expression for areas where clear communication is optional.

-- 
 \       “My business is to teach my aspirations to conform themselves |
  `\              to fact, not to try and make facts harmonise with my |
_o__)                   aspirations.“ —Thomas Henry Huxley, 1860-09-23 |
Ben Finney

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

#11321

On 08/12/2011 05:50 PM, Chris Angelico wrote:
> You can write Perl code in the shape of a camel. Can you do that in Python?
>
> Okay. Open challenge to anyone. Write a Python script that outputs
> "Just another Python hacker" or some such message, and is shaped in
> some way appropriately. And no fair doing all the shaping in comments

Okay, my entry:

   print("Just another Python hacker")

That lovely one-line shape resembles a straight & narrow snake ;-)

-tkc

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

#11324

On 2011-08-12, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:
> Seebs wrote:
>> You know, that's why the outdents-without-symbols bug me; I have a
>> thing with a colon on it introducing something, and then there's nothing
>> ending it.

> But there is something ending it: a change in indentation level.

Hmm.

Okay, here's what I'm not getting.  Consider this:

	if foo:
		blah
		if bar:
			blah
	blah

	if baz:
			blah
	blah

> Python's parser explicitly pushes INDENT and OUTDENT tokens into the stream.

What's being pushed into the stream to indicate that the first outdent
is two outdents and the second is one?

I guess... The parser is explicitly pushing those tokens, but I can't
*SEE* those tokens.  If I am looking at the end of a really long
thing, and I see:

			blah
	blah

I only know what's happening if I have absolute confidence that the
indentation is always by the same amount, etectera.

> They're just a change of state in indentation level, which is much more
> easily seen without the need for counting braces. Python's parser may need
> to count tokens, but for the human reader merely needs to use its intuitive
> and highly accurate ability to notice when things line up.

Well, that's the thing.

In a case like:

	if foo:
		if bar:
			blah
	blah

I notice that *NOTHING* lines up with "if bar:".  And that affects me
about the way unmatched brackets do.

> (Aside: this is why I dislike two-space indents. That's narrow enough to
> make the "does this line up" detector subject to too many false positives.)

Yeah.

>> I want that match so I can let the naive stack-depth-counter 
>> off somewhere in my brain do its thing without leaving me with a huge
>> feeling of unclosed blocks.

> Yet another reason to consider brace languages harmful: they spoil the
> user's intuitive grasp of intuition as grouping.

I assume you mean "indentation as grouping".

I'm... not sold on this.  It's not that I don't see indentation as a kind
of grouping.  It's just that I really, really, want groups to have ends.

Consider the hypothetical array syntax:

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

This *bugs* me.  It's perfectly legible, and if you define it that way, it's
unambiguous and everything, but... It bugs me.  I want beginnings to have
an actual corresponding end.

> But the human brain is a funny thing: you can train
> it to expect to do more work than is necessary, and it will complain when
> you make its job easier.

Easier varies somewhat from person to person.  I need a LOT of parity checks
(speaking metaphorically) because my brain is fantastically prone to dropping
bits.  But I'm really fast.  So a thing with lots of parity checks is much
easier for me to actually *successfully* use than a thing which omits all
that extra stuff.

I was overjoyed when I saw that Ruby would let me write 1_048_576.  I can
read that with fewer errors than I can read 1048576.  (And yes, I could
also write "1<<20".)

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

#11327

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

> What's being pushed into the stream to indicate that the first outdent
> is two outdents and the second is one?

See <URL:http://docs.python.org/reference/lexical_analysis.html> for a
comprehensive discussion of the lexing done on Python source.

To examine the resulting code objects, see the ‘dis’ module in the
standard library <URL:http://docs.python.org/library/dis.html>.

-- 
 \         “[T]he question of whether machines can think … is about as |
  `\         relevant as the question of whether submarines can swim.” |
_o__)                                              —Edsger W. Dijkstra |
Ben Finney

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

#11330

On 2011-08-13, Ben Finney <ben+python@benfinney.id.au> wrote:
> Seebs <usenet-nospam@seebs.net> writes:
>> What's being pushed into the stream to indicate that the first outdent
>> is two outdents and the second is one?

> See <URL:http://docs.python.org/reference/lexical_analysis.html> for a
> comprehensive discussion of the lexing done on Python source.

Interesting, thanks.

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

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

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

csiph-web