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

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

New to Python - block grouping (spaces)

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

Contents

  New to Python - block grouping (spaces) Blake McBride <blake1024@gmail.com> - 2015-04-15 21:07 -0700
    Re: New to Python - block grouping (spaces) Paul Rubin <no.email@nospam.invalid> - 2015-04-15 21:48 -0700
    Re: New to Python - block grouping (spaces) Chris Angelico <rosuav@gmail.com> - 2015-04-16 14:51 +1000
    Re: New to Python - block grouping (spaces) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-04-16 15:49 +1000
      Re: New to Python - block grouping (spaces) Paul Rubin <no.email@nospam.invalid> - 2015-04-15 23:11 -0700
        Re: New to Python - block grouping (spaces) William Ray Wing <wrw@mac.com> - 2015-04-16 09:00 -0400
      Re: New to Python - block grouping (spaces) BartC <bc@freeuk.com> - 2015-04-16 11:51 +0100
        Re: New to Python - block grouping (spaces) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-04-17 03:10 +1000
          Re: New to Python - block grouping (spaces) Tim Chase <python.list@tim.thechases.com> - 2015-04-16 12:49 -0500
          Re: New to Python - block grouping (spaces) BartC <bc@freeuk.com> - 2015-04-16 22:04 +0100
          Re: New to Python - block grouping (spaces) Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-04-17 11:37 +0200
      Re: New to Python - block grouping (spaces) Serhiy Storchaka <storchaka@gmail.com> - 2015-04-16 22:14 +0300
    Re: New to Python - block grouping (spaces) alister <alister.nospam.ware@ntlworld.com> - 2015-04-16 07:46 +0000
      Re: New to Python - block grouping (spaces) Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-04-16 10:47 +0200
      Re: New to Python - block grouping (spaces) Chris Angelico <rosuav@gmail.com> - 2015-04-16 19:34 +1000
      Re: New to Python - block grouping (spaces) Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-04-16 12:09 +0200
        Re: New to Python - block grouping (spaces) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-04-16 20:43 +1000
          Re: New to Python - block grouping (spaces) Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-04-16 13:07 +0200
            Re: New to Python - block grouping (spaces)yhoni alister <alister.nospam.ware@ntlworld.com> - 2015-04-16 13:18 +0000
              Re: New to Python - block grouping (spaces)yhoni BartC <bc@freeuk.com> - 2015-04-16 14:44 +0100
                Re: New to Python - block grouping (spaces)yhoni Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-04-16 18:46 +0100
                Re: New to Python - block grouping (spaces)yhoni alister <alister.nospam.ware@ntlworld.com> - 2015-04-16 18:03 +0000
              Re: New to Python - block grouping (spaces)yhoni Chris Angelico <rosuav@gmail.com> - 2015-04-16 23:50 +1000
              Re: New to Python - block grouping (spaces)yhoni Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-04-16 16:09 +0200
                Re: New to Python - block grouping (spaces)yhoni alister <alister.nospam.ware@ntlworld.com> - 2015-04-16 18:04 +0000
          Re: New to Python - block grouping (spaces) Chris Angelico <rosuav@gmail.com> - 2015-04-16 23:41 +1000
          Re: New to Python - block grouping (spaces) Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-04-16 15:57 +0200
    Re: New to Python - block grouping (spaces) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-04-16 13:17 +0100
    Re: New to Python - block grouping (spaces) Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-04-16 14:48 +0200
    Re: New to Python - block grouping (spaces) Simmo <square.steve@gmail.com> - 2015-04-16 14:37 +0100
    Re: New to Python - block grouping (spaces) Blake McBride <blake1024@gmail.com> - 2015-04-16 07:52 -0700
      Re: New to Python - block grouping (spaces) Blake McBride <blake1024@gmail.com> - 2015-04-16 08:01 -0700
        Re: New to Python - block grouping (spaces) alister <alister.nospam.ware@ntlworld.com> - 2015-04-16 18:08 +0000
          Re: New to Python - block grouping (spaces) memilanuk <memilanuk@gmail.com> - 2015-04-16 11:28 -0700
      Re: New to Python - block grouping (spaces) Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2015-04-16 15:05 +0000
        Re: New to Python - block grouping (spaces) edmondo.giovannozzi@gmail.com - 2015-04-20 03:00 -0700
      Re: New to Python - block grouping (spaces) memilanuk <memilanuk@gmail.com> - 2015-04-16 08:05 -0700
      Re: New to Python - block grouping (spaces) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-04-16 16:05 +0100
        Re: New to Python - block grouping (spaces) CHIN Dihedral <dihedral88888@gmail.com> - 2015-04-19 11:46 -0700
      Re: New to Python - block grouping (spaces) Chris Angelico <rosuav@gmail.com> - 2015-04-17 01:03 +1000
      Re: New to Python - block grouping (spaces) Grant Edwards <invalid@invalid.invalid> - 2015-04-16 15:21 +0000
      Re: New to Python - block grouping (spaces) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-04-17 03:41 +1000
        Re: New to Python - block grouping (spaces) Ron Adam <ron3200@gmail.com> - 2015-04-16 14:54 -0400
      EditorConfig for cross-editor consistent code style (was: New to Python - block grouping (spaces)) Ben Finney <ben+python@benfinney.id.au> - 2015-04-17 06:10 +1000
      Re: New to Python - block grouping (spaces) Michael Torrie <torriem@gmail.com> - 2015-04-17 09:44 -0600
        Re: New to Python - block grouping (spaces) Grant Edwards <invalid@invalid.invalid> - 2015-04-17 16:28 +0000
          Re: New to Python - block grouping (spaces) BartC <bc@freeuk.com> - 2015-04-17 18:05 +0100
            Re: New to Python - block grouping (spaces) Rustom Mody <rustompmody@gmail.com> - 2015-04-17 10:13 -0700
            Re: New to Python - block grouping (spaces) sohcahtoa82@gmail.com - 2015-04-17 11:13 -0700
              Re: New to Python - block grouping (spaces) Marko Rauhamaa <marko@pacujo.net> - 2015-04-17 23:28 +0300
            Re: New to Python - block grouping (spaces) Chris Angelico <rosuav@gmail.com> - 2015-04-18 07:10 +1000
            Re: New to Python - block grouping (spaces) Dan Sommers <dan@tombstonezero.net> - 2015-04-18 01:18 +0000
              Re: New to Python - block grouping (spaces) Rustom Mody <rustompmody@gmail.com> - 2015-04-17 19:22 -0700
                Re: New to Python - block grouping (spaces) BartC <bc@freeuk.com> - 2015-04-19 12:44 +0100
                  Re: New to Python - block grouping (spaces) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-04-19 23:23 +1000
                    Re: New to Python - block grouping (spaces) wxjmfauth@gmail.com - 2015-04-19 07:22 -0700
                  Re: New to Python - block grouping (spaces) Rustom Mody <rustompmody@gmail.com> - 2015-04-19 07:01 -0700
            Re: New to Python - block grouping (spaces) Michael Torrie <torriem@gmail.com> - 2015-04-17 20:14 -0600
              Re: New to Python - block grouping (spaces) Marko Rauhamaa <marko@pacujo.net> - 2015-04-18 09:53 +0300
            Re: New to Python - block grouping (spaces) Ben Finney <ben+python@benfinney.id.au> - 2015-04-18 12:22 +1000
              Re: New to Python - block grouping (spaces) Larry Hudson <orgnut@yahoo.com> - 2015-04-17 22:28 -0700
              Re: New to Python - block grouping (spaces) Marko Rauhamaa <marko@pacujo.net> - 2015-04-18 10:00 +0300
                Re: New to Python - block grouping (spaces) Rustom Mody <rustompmody@gmail.com> - 2015-04-18 00:13 -0700
                  Re: New to Python - block grouping (spaces) Marko Rauhamaa <marko@pacujo.net> - 2015-04-18 10:42 +0300
                Re: New to Python - block grouping (spaces) Michael Torrie <torriem@gmail.com> - 2015-04-19 11:15 -0600
                  Re: New to Python - block grouping (spaces) Marko Rauhamaa <marko@pacujo.net> - 2015-04-19 23:41 +0300
                    Re: New to Python - block grouping (spaces) Rustom Mody <rustompmody@gmail.com> - 2015-04-19 19:00 -0700
                    Re: New to Python - block grouping (spaces) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-04-20 12:54 +1000
                      Re: New to Python - block grouping (spaces) Chris Angelico <rosuav@gmail.com> - 2015-04-20 13:05 +1000
                        Re: New to Python - block grouping (spaces) Marko Rauhamaa <marko@pacujo.net> - 2015-04-20 08:09 +0300
              Re: New to Python - block grouping (spaces) BartC <bc@freeuk.com> - 2015-04-19 12:38 +0100
                Re: New to Python - block grouping (spaces) Ben Finney <ben+python@benfinney.id.au> - 2015-04-19 22:59 +1000
                  Re: New to Python - block grouping (spaces) BartC <bc@freeuk.com> - 2015-04-19 22:42 +0100
                    Re: New to Python - block grouping (spaces) Ron Adam <ron3200@gmail.com> - 2015-04-19 19:28 -0400
                    Re: New to Python - block grouping (spaces) Ben Finney <ben+python@benfinney.id.au> - 2015-04-20 09:59 +1000
                      Re: New to Python - block grouping (spaces) BartC <bc@freeuk.com> - 2015-04-20 01:30 +0100
                Re: New to Python - block grouping (spaces) Dave Angel <davea@davea.name> - 2015-04-19 09:18 -0400
                Re: New to Python - block grouping (spaces) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-04-19 23:22 +1000
                Re: New to Python - block grouping (spaces) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-04-19 14:30 +0100
                Re: New to Python - block grouping (spaces) Chris Angelico <rosuav@gmail.com> - 2015-04-20 01:15 +1000
                  Re: New to Python - block grouping (spaces) Rustom Mody <rustompmody@gmail.com> - 2015-04-19 09:03 -0700
                    Re: New to Python - block grouping (spaces) Mel Wilson <mwilson@the-wire.com> - 2015-04-19 17:38 +0000
                    Re: New to Python - block grouping (spaces) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-04-20 03:53 +1000
                      Re: New to Python - block grouping (spaces) Mel Wilson <mwilson@the-wire.com> - 2015-04-19 18:25 +0000
                      Re: New to Python - block grouping (spaces) Rustom Mody <rustompmody@gmail.com> - 2015-04-19 19:08 -0700
                        Re: New to Python - block grouping (spaces) Chris Angelico <rosuav@gmail.com> - 2015-04-20 12:24 +1000
                          Re: New to Python - block grouping (spaces) Rustom Mody <rustompmody@gmail.com> - 2015-04-19 19:43 -0700
                            Re: New to Python - block grouping (spaces) Chris Angelico <rosuav@gmail.com> - 2015-04-20 13:03 +1000
                              Re: New to Python - block grouping (spaces) Rustom Mody <rustompmody@gmail.com> - 2015-04-19 20:28 -0700
                                Re: New to Python - block grouping (spaces) Chris Angelico <rosuav@gmail.com> - 2015-04-20 13:44 +1000
                                  Re: New to Python - block grouping (spaces) Rustom Mody <rustompmody@gmail.com> - 2015-04-20 19:18 -0700
                            Re: New to Python - block grouping (spaces) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-04-20 20:30 +1000
                              Re: New to Python - block grouping (spaces) Rustom Mody <rustompmody@gmail.com> - 2015-04-20 04:51 -0700
                                Re: New to Python - block grouping (spaces) albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-25 17:42 +0000
                              Re: New to Python - block grouping (spaces) BartC <bc@freeuk.com> - 2015-04-20 13:05 +0100
                              Re: New to Python - block grouping (spaces) wxjmfauth@gmail.com - 2015-04-24 01:50 -0700
                        Re: New to Python - block grouping (spaces) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-04-20 03:38 +0100
                        Re: New to Python - block grouping (spaces) llanitedave <llanitedave@birdandflower.com> - 2015-04-21 08:29 -0700
                          Re: New to Python - block grouping (spaces) Rustom Mody <rustompmody@gmail.com> - 2015-04-21 10:49 -0700
                            Re: New to Python - block grouping (spaces) llanitedave <llanitedave@birdandflower.com> - 2015-04-21 14:35 -0700
                              Re: New to Python - block grouping (spaces) Rustom Mody <rustompmody@gmail.com> - 2015-04-21 20:11 -0700
                                Re: New to Python - block grouping (spaces) llanitedave <llanitedave@birdandflower.com> - 2015-04-21 21:05 -0700
                                  Re: New to Python - block grouping (spaces) Rustom Mody <rustompmody@gmail.com> - 2015-04-22 04:37 -0700
                                    Re: New to Python - block grouping (spaces) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-04-22 13:05 +0100
                      Re: New to Python - block grouping (spaces) Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-04-20 20:38 +1200
                        Re: New to Python - block grouping (spaces) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-04-20 20:15 +1000
                    Re: New to Python - block grouping (spaces) Dan Sommers <dan@tombstonezero.net> - 2015-04-19 18:07 +0000
                      Re: New to Python - block grouping (spaces) Chris Angelico <rosuav@gmail.com> - 2015-04-20 06:03 +1000
                      Re: New to Python - block grouping (spaces) Rustom Mody <rustompmody@gmail.com> - 2015-04-19 18:46 -0700
                      Re: New to Python - block grouping (spaces) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-04-20 12:42 +1000
                Re: New to Python - block grouping (spaces) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-04-20 03:46 +1000
                  Re: New to Python - block grouping (spaces) Paul Rubin <no.email@nospam.invalid> - 2015-04-19 13:36 -0700
            Re: New to Python - block grouping (spaces) Rustom Mody <rustompmody@gmail.com> - 2015-04-24 22:06 -0700
              Re: New to Python - block grouping (spaces) Marko Rauhamaa <marko@pacujo.net> - 2015-04-25 10:27 +0300
                Re: New to Python - block grouping (spaces) Rustom Mody <rustompmody@gmail.com> - 2015-04-25 09:52 -0700
      Re: New to Python - block grouping (spaces) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-04-24 08:31 +0100
      Re: New to Python - block grouping (spaces) Michael Torrie <torriem@gmail.com> - 2015-04-24 08:03 -0600
    Re: New to Python - block grouping (spaces) Rustom Mody <rustompmody@gmail.com> - 2015-04-16 10:59 -0700
      Re: New to Python - block grouping (spaces) Rob Gaddi <rgaddi@technologyhighland.invalid> - 2015-04-16 18:45 +0000

Page 1 of 6  [1] 2 3 4 5 6  Next page →

#89005 — New to Python - block grouping (spaces)

Greetings,

I am new to Python.  I am sorry for beating what is probably a dead horse but I checked the net and couldn't find the answer to my question.

I like a lot of what I've seen in Python, however, after 35 years and probably a dozen languages under my belt, I very strongly disagree with the notion of using white space to delimit blocks.  Not wanting to beat what I believe is probably a dead horse, I have one question.  

Is there a utility that will allow me to write Python-like code that includes some block delimiter that I can see, that converts the code into runnable Python code?  If so, where can I find it?

Thanks!

Blake McBride

[toc] | [next] | [standalone]

#89007

Blake McBride <blake1024@gmail.com> writes:
> probably a dozen languages under my belt, I very strongly disagree
> with the notion of using white space to delimit blocks. 

I suggest giving it a try before deciding something like that.  I don't
guarantee you'll come around, but a lot of people decide after a while
that they like it after all.

> Is there a utility that will allow me to write Python-like code that
> includes some block delimiter that I can see, that converts the code
> into runnable Python code?  If so, where can I find it?

I'm not aware of one.  People who don't like Python's indentation syntax
tend to choose other languages.

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

#89008

On Thu, Apr 16, 2015 at 2:07 PM, Blake McBride <blake1024@gmail.com> wrote:
> I like a lot of what I've seen in Python, however, after 35 years and probably a dozen languages under my belt, I very strongly disagree with the notion of using white space to delimit blocks.  Not wanting to beat what I believe is probably a dead horse, I have one question.
>
> Is there a utility that will allow me to write Python-like code that includes some block delimiter that I can see, that converts the code into runnable Python code?  If so, where can I find it?
>

Python has a mechanic for handling syntax changes in a
backward-compatible way: the __future__ module. Some handy reading:

https://docs.python.org/3/library/__future__.html
https://www.python.org/dev/peps/pep-0236/
https://docs.python.org/3/reference/simple_stmts.html#future

To make use of this, put this line at the top of your program:

from __future__ import braces

Give it a try, I'll wait for you. Or paste that in at the interactive
interpreter prompt.

Done it?

Okay. Now you understand how Python's developers feel about this kind
of thing :)

What you may want to consider is a Python-like language that uses a
different syntax: Pike. It's semantically very similar to Python, but
syntactically similar to C. Learn both, and then you'll understand a
bit more of the debate. I used to be firmly on the side of braces, but
not so much now; Python's use of indentation eliminates some
redundancy (since, after all, you're probably going to be indenting
correctly anyway). Yes, it's using something syntactically that you
might think of as pure formatting (leading whitespace on a line), but
it's not fundamentally illogical or anything.

You can, of course, come up with a syntax for a "brace-blocked
Python", and precompile it into actual runnable Python code. That'd be
fairly straight-forward. But the question is, why do it? You wouldn't
be able to take much advantage of it without making a whole lot of
other changes, which would basically mean turning it into a completely
different language, and then there's not a lot of point using Python
behind the scenes. For instance, Python has declared mutable globals,
whereas bracey languages usually have declared locals, or in the case
of PHP, declared globals (mutable or read-only). Which way would you
do it? And what about semicolons? If you're going to allow blocks of
code to be defined by visible characters instead of whitespace,
wouldn't it make sense to do the same with statements? In Python, for
instance, you can't do this:

if x==1: for i in range(3): print(i)

but you can do this:

if x==1: print(1); print(2);

and they'll both be governed by the 'if'.

I strongly recommend NOT doing a half-way change like this, just
adding braces and nothing more. All you'll end up doing is wishing
that Python were like C in some other way, and then another, and then
another, and you'll find yourself hating Python. Learn Python the way
Python is meant to be, and learn a different language if you like its
semantics but not its syntax.

And I'm happy to talk to you off-list about Pike. In my opinion, it
and Python are the two best programming languages in the world.

ChrisA

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

#89009

On Thursday 16 April 2015 14:07, Blake McBride wrote:

> Greetings,
> 
> I am new to Python.  I am sorry for beating what is probably a dead horse
> but I checked the net and couldn't find the answer to my question.
> 
> I like a lot of what I've seen in Python, however, after 35 years and
> probably a dozen languages under my belt, I very strongly disagree with
> the notion of using white space to delimit blocks.  Not wanting to beat
> what I believe is probably a dead horse, I have one question.
> 
> Is there a utility that will allow me to write Python-like code that
> includes some block delimiter that I can see, that converts the code into
> runnable Python code?  If so, where can I find it?

Python already supports this with the optional "block delimiter" sigil. For 
example, if you like braces, you can write:


def function(x):
#{
    if x > 1:
        #{
        print "x bigger than 1"
        #}
    else:
    #{
        print "x smaller than or equal to 1"
        while x <= 1:  #{
            x += 1  #}
        #}
    return x
#}

Notice that Python is clever enough to allow many brace styles, or even 
allow you to invent your own style.

If you prefer Pascal style, Python supports that too:

def function(x):
    # BEGIN
    return x
    # END

You can even localise it:

def function(x):  # ANFANGEN
    return x
    # BEENDEN


Best of all, Python's parser includes an advanced "Do What I Mean" expert 
system which can infer the intended block grouping from the indentation 
alone, even when braces are missing or in the wrong position. Unlike C, 
Python will do the right thing here:


if condition:
    do_this()
    do_that()


No more bugs from accidentally forgetting to use optional braces!



Sorry for the flippant response, but it's 2015, not 1995, and the question 
about the Offside Rule is not just a dead horse but it is positively 
fossilized.

https://en.wikipedia.org/wiki/Off-side_rule

I'm not aware of any pre-processor tools for Python that will syntactically 
check that added braces match the indentation. Such a tool would be 
unPythonic: if they match, the braces are redundant and are not needed, and 
if they do not match, then the compiler (or preprocessor) should not guess 
whether the indentation is right or the braces are right. But if you enforce 
the rule that braces must match indentation, then the braces are redundant!

If you find such a preprocessor, or write your own, feel free to use it. But 
you won't get any respect from experienced Python programmers: we use Python 
in part to get away from braces, we're not chomping at the bit to put them 
back in.

I'm aware that Coffeescript provides a brace-free wrapper around Javascript; 
I'm not aware of any wrapper that *adds* braces to a language without them. 
I suspect such a thing would be of limited use and even less popularity. But 
feel free to try developing one, I could be wrong!



-- 
Steve

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

#89010

Steven D'Aprano <steve+comp.lang.python@pearwood.info> writes:
> I'm aware that Coffeescript provides a brace-free wrapper around Javascript; 
> I'm not aware of any wrapper that *adds* braces to a language without them. 

You're not old enough to remember Ratfor ;-)

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

#89028

> On Apr 16, 2015, at 2:11 AM, Paul Rubin <no.email@nospam.invalid> wrote:
> 
> Steven D'Aprano <steve+comp.lang.python@pearwood.info> writes:
>> I'm aware that Coffeescript provides a brace-free wrapper around Javascript; 
>> I'm not aware of any wrapper that *adds* braces to a language without them. 
> 
> You're not old enough to remember Ratfor ;-)
> -- 
> https://mail.python.org/mailman/listinfo/python-list

HO Boy - Rational FORTRAN!  Right up there with WatFOR (Waterloo FORTRAN for you youngsters).  It was interpreted FORTRAN.  Used teaching new programmers back in the day because it kept them from crashing the system.

Bill

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

#89016

On 16/04/2015 06:49, Steven D'Aprano wrote:
> On Thursday 16 April 2015 14:07, Blake McBride wrote:

>> Is there a utility that will allow me to write Python-like code that
>> includes some block delimiter that I can see, that converts the code into
>> runnable Python code?  If so, where can I find it?

> No more bugs from accidentally forgetting to use optional braces!

You get bugs instead from mistakenly using the wrong indentation or 
losing the correct indentation (accidentally pressing the wrong key for 
example).

> If you find such a preprocessor, or write your own, feel free to use it. But
> you won't get any respect from experienced Python programmers: we use Python
> in part to get away from braces, we're not chomping at the bit to put them
> back in.
>
> I'm aware that Coffeescript provides a brace-free wrapper around Javascript;
> I'm not aware of any wrapper that *adds* braces to a language without them.
> I suspect such a thing would be of limited use and even less popularity. But
> feel free to try developing one, I could be wrong!

I used a wrapper a couple of years ago that allowed me to write in my 
own Algol68-style syntax and produce Python as output. A short example 
might have this as input:

proc start=
   to 10 do
     println "Hello World"
   od
end

and produced:

import sys
import math
import copy

def start():
     _tmp1=10
     while _tmp1>0:
         sys.stdout.write(str("Hello World"))
         sys.stdout.write("\n")
         _tmp1=_tmp1-1

start()

(It actually worked quite well, for small programs, and I managed to get 
the same input converted to Lisp and Lua too. Also, for very simple 
programs, to C, but this requires static type declarations which are 
ignored for Python output.

However the main problem was that Python was too semantically different 
from the way I normally used the input language, and now that language 
is self-contained and does its own thing.)

This wrapper took the form of a proper parser for the input, producing 
an abstract syntax tree, which was then written out in the output syntax 
of choice.

Where the input is already nearly Python, then it can much simpler, but 
it can't do so much checking. If there is a 1:1 correspondence between 
line numbers of input and output, then it makes it easier to match any 
Python errors with the original not-quite-Python source code.

I've used this approach to add Algol-68 block delimiters (and change a 
few other things I found annoying) to C code.

-- 
Bartc

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

#89038

On Thu, 16 Apr 2015 08:51 pm, BartC wrote:

> On 16/04/2015 06:49, Steven D'Aprano wrote:
>> On Thursday 16 April 2015 14:07, Blake McBride wrote:
> 
>>> Is there a utility that will allow me to write Python-like code that
>>> includes some block delimiter that I can see, that converts the code
>>> into
>>> runnable Python code?  If so, where can I find it?
> 
>> No more bugs from accidentally forgetting to use optional braces!
> 
> You get bugs instead from mistakenly using the wrong indentation or
> losing the correct indentation (accidentally pressing the wrong key for
> example).

That's nothing! Python gives you absolutely no protection from accidentally
typing:


    x += 1

when you actually wanted:

   y -= 2


And there there was the time I edited some code written by my boss. I
intended to write a comment:

    # FIXME: this function is a little slow and should be optimized.

but I hit the wrong key a couple of times and wrote:

    # This is a steaming pile of guano written by a drooling
    # moron who shouldn't be allowed near a computer. It needs 
    # to be deleted with prejudice, and the hard drive and all 
    # backup tapes set on fire just to be sure.


As I'm sure you will agree, it is an easy mistake to make.


I'm not impressed by arguments "braces protect you from accidentally hitting
tab too many times (or too few)". Um, okay. Don't people read their own
code? How do you not notice that you've indented it wrongly?

To my mind, the argument from "hitting tab too many times" is like tying a
double-bed mattress to your head in case an eagle flying overhead drops a
tortoise on your head.


The great thing about Off-side rule languages like Python is that the
structure of code is easy to see:


code code code code code code code 
    code 
code code code 
    code code code 
        code code code 
    code 
        code
            code
                code code code 
                    code code
                code code 
                    code code
    code
code


while braces without indentation are horribly opaque:

code code code code code code code { code } code code code { code 
code code { code code code } code { code { code { code code code
{ code code } code code { code code } } } } code } code



It's true that if a tool mangles your source code and deletes all your
indentation, you cannot mechanically fix the problem without understanding
the intent of the source code. But if a tool mangles your source code by
deleting words starting with "w", the same applies. Don't use broken tools.



-- 
Steven

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

#89042

On 2015-04-17 03:10, Steven D'Aprano wrote:
> And there there was the time I edited some code written by my boss.
> I intended to write a comment:
> 
>     # FIXME: this function is a little slow and should be optimized.
> 
> but I hit the wrong key a couple of times and wrote:
> 
>     # This is a steaming pile of guano written by a drooling
>     # moron who shouldn't be allowed near a computer. It needs 
>     # to be deleted with prejudice, and the hard drive and all 
>     # backup tapes set on fire just to be sure.
> 
> As I'm sure you will agree, it is an easy mistake to make.

Phew, glad I'm not the only one to do that.  Fortunately, I had one
of those code-reformatters the OP talks about, and it fixed the
mistake for me. :-)

-tkc

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

#89051

On 16/04/2015 18:10, Steven D'Aprano wrote:
> On Thu, 16 Apr 2015 08:51 pm, BartC wrote:
>
>> On 16/04/2015 06:49, Steven D'Aprano wrote:
>>> On Thursday 16 April 2015 14:07, Blake McBride wrote:
>>
>>>> Is there a utility that will allow me to write Python-like code that
>>>> includes some block delimiter that I can see, that converts the code
>>>> into
>>>> runnable Python code?  If so, where can I find it?
>>
>>> No more bugs from accidentally forgetting to use optional braces!
>>
>> You get bugs instead from mistakenly using the wrong indentation or
>> losing the correct indentation (accidentally pressing the wrong key for
>> example).
>
> That's nothing! Python gives you absolutely no protection from accidentally
> typing:
>
>
>      x += 1
>
> when you actually wanted:
>
>     y -= 2

>
> As I'm sure you will agree, it is an easy mistake to make.

I meant hitting Backspace or Delete.

But also, sometimes you post code to Usenet and you find leading tabs 
have been stripped out. With Python code, that's problematical.

> I'm not impressed by arguments "braces protect you from accidentally hitting
> tab too many times (or too few)". Um, okay. Don't people read their own
> code? How do you not notice that you've indented it wrongly?

Take:

  if cond:
     stmt1
     stmt2
     stmt3

and:

  if cond:
     stmt1
     stmt2
  stmt3

which one is correct? Is there a tab too many, or one too few? Or two 
too many? Now, much as I dislike C-style braces, at least it is a little 
more resilient:

  if (cond) {
     stmt1;
     stmt2;
  stmt3;
  }

or:

  if (cond) {
     stmt1;
     stmt2;
  }
     stmt3;

One 'if' clearly has three statements, and the other has two, and you 
are confident enough to fix the tabbing errors without consequences.

> while braces without indentation are horribly opaque:
>
> code code code code code code code { code } code code code { code
> code code { code code code } code { code { code { code code code
> { code code } code code { code code } } } } code } code

It seems to work well enough with expressions:

  x = (a * (b+c) * d) / e

-- 
Bartc

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

#89058

Op 16-04-15 om 19:10 schreef Steven D'Aprano:
> On Thu, 16 Apr 2015 08:51 pm, BartC wrote:
>
>> On 16/04/2015 06:49, Steven D'Aprano wrote:
>>> On Thursday 16 April 2015 14:07, Blake McBride wrote:
>>>> Is there a utility that will allow me to write Python-like code that
>>>> includes some block delimiter that I can see, that converts the code
>>>> into
>>>> runnable Python code?  If so, where can I find it?
>>> No more bugs from accidentally forgetting to use optional braces!
>> You get bugs instead from mistakenly using the wrong indentation or
>> losing the correct indentation (accidentally pressing the wrong key for
>> example).
> That's nothing! Python gives you absolutely no protection from accidentally
> typing:
>
>
>     x += 1
>
> when you actually wanted:
>
>    y -= 2

I find this a bit disingenuous. Each time assignment as an expression comes
up, so that it would be possible to have an assignment in a if or while
condition, few of the regulars seem to have a problem with the argument that
the current choice protects against a particular kind of bug.

The fact that braces protect against a kind of bug you care less about,
is just your preference. That doesn't mean a different preference is
somehow worthy of ridicule.

Mistakes of all kinds happen and I see no reason to ridicule someone for
wishing protect against one kind of mistake, while yourself having the
protection you like.

-- 
Antoon Pardon

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

#89049

On 16.04.15 08:49, Steven D'Aprano wrote:
> I'm not aware of any pre-processor tools for Python that will syntactically
> check that added braces match the indentation. Such a tool would be
> unPythonic: if they match, the braces are redundant and are not needed, and
> if they do not match, then the compiler (or preprocessor) should not guess
> whether the indentation is right or the braces are right. But if you enforce
> the rule that braces must match indentation, then the braces are redundant!
>
> If you find such a preprocessor, or write your own, feel free to use it. But
> you won't get any respect from experienced Python programmers: we use Python
> in part to get away from braces, we're not chomping at the bit to put them
> back in.

https://hg.python.org/cpython/raw-file/default/Tools/scripts/pindent.py

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

#89011

On Wed, 15 Apr 2015 21:07:45 -0700, Blake McBride wrote:

> Greetings,
> 
> I am new to Python.  I am sorry for beating what is probably a dead
> horse but I checked the net and couldn't find the answer to my question.
> 
> I like a lot of what I've seen in Python, however, after 35 years and
> probably a dozen languages under my belt, I very strongly disagree with
> the notion of using white space to delimit blocks.

as others have suggested this is a core to python as it enforces 
readability. Many new python programmes find it strange but usually take 
to it quite quickly.

what I find strange is that although these programmers initially disliked 
forced indentation they were voluntarily indenting there existing code 
anyway. Take a look at your existing code base & see if this would indeed 
be the case.

Stephens suggestion of using comments @ the start & end of your blocks 
may be useful during the learning phase.





-- 
Battle, n.:
	A method of untying with the teeth a political knot that
	will not yield to the tongue.
		-- Ambrose Bierce

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

#89012

On 04/16/2015 09:46 AM, alister wrote:

> what I find strange is that although these programmers initially disliked 
> forced indentation they were voluntarily indenting there existing code 
> anyway. Take a look at your existing code base & see if this would indeed 
> be the case.

The problem is that the logical structure one has in one's head is not always
the same as the physical structure one has to implement in. I prefer the
indentation of my program to reflect the former instead of the latter. That
is impossible in python.

This problem sometimes shows up when possible new programming structures are
discussed and the structure is discareded, not because it lacks merrit but
because it can't me made to fit into the forced indentation mold of python.

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

#89013

On Thu, Apr 16, 2015 at 6:47 PM, Antoon Pardon
<antoon.pardon@rece.vub.ac.be> wrote:
> On 04/16/2015 09:46 AM, alister wrote:
>
>> what I find strange is that although these programmers initially disliked
>> forced indentation they were voluntarily indenting there existing code
>> anyway. Take a look at your existing code base & see if this would indeed
>> be the case.
>
> The problem is that the logical structure one has in one's head is not always
> the same as the physical structure one has to implement in. I prefer the
> indentation of my program to reflect the former instead of the latter. That
> is impossible in python.

I agree, but as it turns out, the number of times when this actually
makes a difference are diminishingly few. The most warpedly correct
indentation I've ever done was in PHP, where I used a triply-nested
structure of switch/case blocks to simulate a logical structure that
in Python would simply be a series of top-level functions - or *maybe*
a series of class definitions with methods in them. So if I were doing
the same logical structure in Python, I wouldn't mind the indentation
matching the physical structure, because it'd be sufficiently close.

ChrisA

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

#89014

On 04/16/2015 11:34 AM, Chris Angelico wrote:
> On Thu, Apr 16, 2015 at 6:47 PM, Antoon Pardon
> <antoon.pardon@rece.vub.ac.be> wrote:
>> On 04/16/2015 09:46 AM, alister wrote:
>>
>>> what I find strange is that although these programmers initially disliked
>>> forced indentation they were voluntarily indenting there existing code
>>> anyway. Take a look at your existing code base & see if this would indeed
>>> be the case.
>> The problem is that the logical structure one has in one's head is not always
>> the same as the physical structure one has to implement in. I prefer the
>> indentation of my program to reflect the former instead of the latter. That
>> is impossible in python.
> I agree, but as it turns out, the number of times when this actually
> makes a difference are diminishingly few. 

I beg to differ. The most common occurence is a loop with a break condition
in the middle I would prefer such a loop to be written as follows:

repeat:
    some
    code
break_when condition:
    more
    code

Actually I would prefer a more elaborate scheme but would be contend with
a possibility like the above. IMO this is the most occuring pattern where
the logical structure doesn't match the physical structure and it is not
occuring relevantly less now.

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

#89015

On Thursday 16 April 2015 20:09, Antoon Pardon wrote:

> I beg to differ. The most common occurence is a loop with a break
> condition in the middle I would prefer such a loop to be written as
> follows:
> 
> repeat:
>     some
>     code
> break_when condition:
>     more
>     code


That structure makes no sense to me. Why is the "break_when" *outside* of 
the loop? Why does the "break_when condition" introduce a new block?



> Actually I would prefer a more elaborate scheme but would be contend with
> a possibility like the above. IMO this is the most occuring pattern where
> the logical structure doesn't match the physical structure and it is not
> occuring relevantly less now.


Judging by the above example, I think it may be a good thing that Python 
doesn't allow "more elaborate" indentation schemes.

repeat:
    do this
    do that
                  do something else important
          and this
sometimes this
          also this
                             but don't do this
  unless today is Tuesday
               # end loop



Simplicity is a virtue.




-- 
Steve

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

#89017

On 04/16/2015 12:43 PM, Steven D'Aprano wrote:
> On Thursday 16 April 2015 20:09, Antoon Pardon wrote:
>
>> I beg to differ. The most common occurence is a loop with a break
>> condition in the middle I would prefer such a loop to be written as
>> follows:
>>
>> repeat:
>>     some
>>     code
>> break_when condition:
>>     more
>>     code
>
> That structure makes no sense to me. Why is the "break_when" *outside* of 
> the loop? Why does the "break_when condition" introduce a new block?

How do you mean outside the loop? Do you consider the "else" outside the
if statement?

>> Actually I would prefer a more elaborate scheme but would be contend with
>> a possibility like the above. IMO this is the most occuring pattern where
>> the logical structure doesn't match the physical structure and it is not
>> occuring relevantly less now.
>
> Judging by the above example, I think it may be a good thing that Python 
> doesn't allow "more elaborate" indentation schemes.
>
> repeat:
>     do this
>     do that
>                   do something else important
>           and this
> sometimes this
>           also this
>                              but don't do this
>   unless today is Tuesday
>                # end loop
>
>
>
> Simplicity is a virtue.

As is argueing against a real position instead of making something up.
Nobody is argueing for arbitrary indentation.

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

#89020 — Re: New to Python - block grouping (spaces)yhoni

On Thu, 16 Apr 2015 13:07:22 +0200, Antoon Pardon wrote:

> On 04/16/2015 12:43 PM, Steven D'Aprano wrote:
>> On Thursday 16 April 2015 20:09, Antoon Pardon wrote:
>>
>>> I beg to differ. The most common occurence is a loop with a break
>>> condition in the middle I would prefer such a loop to be written as
>>> follows:
>>>
>>> repeat:
>>>     some code
>>> break_when condition:
>>>     more code
>>
>> That structure makes no sense to me. Why is the "break_when" *outside*
>> of the loop? Why does the "break_when condition" introduce a new block?
> 
> How do you mean outside the loop? Do you consider the "else" outside the
> if statement?
> 
>>> Actually I would prefer a more elaborate scheme but would be contend
>>> with a possibility like the above. IMO this is the most occuring
>>> pattern where the logical structure doesn't match the physical
>>> structure and it is not occuring relevantly less now.
>>
>> Judging by the above example, I think it may be a good thing that
>> Python doesn't allow "more elaborate" indentation schemes.
>>
>> repeat:
>>     do this do that
>>                   do something else important
>>           and this
>> sometimes this
>>           also this
>>                              but don't do this
>>   unless today is Tuesday
>>                # end loop
>>
>>
>>
>> Simplicity is a virtue.
> 
> As is argueing against a real position instead of making something up.
> Nobody is argueing for arbitrary indentation.

May I suggest that you give it a try for a month, perhaps re-writing a 
small program you already have in a pythonic style (don't simply write c 
in python) & see if your opinion changes.


if not then other suggestions that python is not a language of choice for 
you may be appropriate.

be warned you may find it creates (or increases ) an extreme dislike for 
C & other languages that require braces & semicolons, it did for me 
(especially the semi-colon!)



-- 
If in any problem you find yourself doing an immense amount of work, the
answer can be obtained by simple inspection.

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

#89024 — Re: New to Python - block grouping (spaces)yhoni

On 16/04/2015 14:18, alister wrote:
> On Thu, 16 Apr 2015 13:07:22 +0200, Antoon Pardon wrote:

>> Nobody is argueing for arbitrary indentation.
>
> May I suggest that you give it a try for a month, perhaps re-writing a
> small program you already have in a pythonic style (don't simply write c
> in python) & see if your opinion changes.

You mean try writing pure Python for a month? Yes, you can get used to 
anything. But that doesn't take away from the issues that some people 
have with its indentation. In my case, that would be the following 
(apart from the extra fragility of the code which you can't argue with):

* I need some closure, some indication of where the end of a block is. 
Otherwise how do I know I'm looking at the last statement, or whether 
there is more on the next page or further down the screen?

Even when I can see what follows the block, I can only infer that this 
is the end of the block because I eventually hit some other arbitrary 
construct with less indentation, not something specifically signalling 
the end of /that/ block.

(This would come up when using copy&paste for example. If I've 
accidentally left out the last line of a block, I won't know about it 
until the code later doesn't work.)

* I modify code a lot, adding and removing extra nested blocks all the 
time. My editor can't indent or un-indent blocks without a lot of manual 
typing. With block-delimited schemes, this isn't an issue, as temporary 
lack of correct indentation isn't crucial.

(However, given a choice of only brace-delimited blocks, and Python 
style, I'd go for the latter! I have a longer list of complaints for 
C-style braces.)

-- 
Bartc

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

Page 1 of 6  [1] 2 3 4 5 6  Next page →

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

csiph-web