yet another indentation proposal

[Aaron]

Hello all.

I realize that proposals dealing with alternatives to indentation have been
brought up (and shot down) before, but I would like to take another stab at
it, because it is rather important to me.

I am totally blind, and somewhat new to Python. I put off learning Python
for a long time, simply because of the indentation issue. There is no easy
way for a screenreader user, such as my self, to figure out how much a
particular line of code is indented. A sited person simply looks down the
column to make sure that everything lines up. I, on the other hand,
generally find my self counting a lot of spaces.

Naturally, there are many other special circumstances in which depending on
whitespace is impractical, but they have already been mentioned in previous
threads on the topic, so I won't bother rehashing them.

Borrowing from another proposal, I would submit that the opening block and
closing block markers could be _{ and }_ respectively. If it seems that
there is even a modicum of support, I'll write up a more complete proposal.
But in short, an _{ will signify to the interpreter that one level of
indentation is to be added to the current level, that all the statements
that follow (until the closing _}) are to be understood to be at that level,
and that all whitespace at the beginning of lines, or lack there of, is to
be ignored.

I realize that this would result in some esthetically ugly code, and so
naturally a simple tool to convert this type of block indication back to
"normal indented format" should also be developed.

Any thoughts or suggestions?

I sincerely hope that this proposal can be given some serious consideration,
and not simply dismissed as sacrilege. There are many blind programmers,
and I would hate to see them opt to learn other languages simply because of
this one issue.

Thanks.

Aaron

 

[Paddy]

Hello all.

I realize that proposals dealing with alternatives to indentation have been
brought up (and shot down) before, but I would like to take another stab at
it, because it is rather important to me.

I am totally blind, and somewhat new to Python. I put off learning Python
for a long time, simply because of the indentation issue. There is no easy
way for a screenreader user, such as my self, to figure out how much a
particular line of code is indented. A sited person simply looks down the
column to make sure that everything lines up. I, on the other hand,
generally find my self counting a lot of spaces.

Naturally, there are many other special circumstances in which depending on
whitespace is impractical, but they have already been mentioned in previous
threads on the topic, so I won't bother rehashing them.

Borrowing from another proposal, I would submit that the opening block and
closing block markers could be _{ and }_ respectively. If it seems that
there is even a modicum of support, I'll write up a more complete proposal.
But in short, an _{ will signify to the interpreter that one level of
indentation is to be added to the current level, that all the statements
that follow (until the closing _}) are to be understood to be at that level,
and that all whitespace at the beginning of lines, or lack there of, is to
be ignored.

I realize that this would result in some esthetically ugly code, and so
naturally a simple tool to convert this type of block indication back to
"normal indented format" should also be developed.

Any thoughts or suggestions?

I sincerely hope that this proposal can be given some serious consideration,
and not simply dismissed as sacrilege. There are many blind programmers,
and I would hate to see them opt to learn other languages simply because of
this one issue.

Thanks.

Aaron

Oh wow. it never crossed my mind...

Can screen reaaderss be customized?
Maybe their is a way to get the screen reader to say indent and dedent
at thee appropriate places?
Or maybe a filter to put those wordds into the source?

- Paddy.

 

[Alex Martelli]

Can screen reaaderss be customized?

Open-source ones surely can (e.g., NVDA is an open-source reader for
Windows written in Python, <http://www.nvda-project.org/> -- alas, if
you search for NVDA Google appears to be totally convinced you mean
NVidia instead, making searches pretty useless, sigh).

Maybe their is a way to get the screen reader to say indent and dedent
at thee appropriate places?

There definitely should be.

Or maybe a filter to put those wordds into the source?

..../Tools/scripts/pindent.py (comes with the Python source distribution,
and I hope that, like the whole Tools directory, it would also come with
any sensible packaged Python distribution) should already be sufficient
for this particular task. The "indent" always happens (in correct
Python sources) on the next line after one ending with a colon;
pindent.py can add or remove "block-closing comments" at each dedent
(e.g., "# end for" if the dedent is terminating a for-statement), and
can adjust the indentation to make it correct if given a Python source
with such block-closing comments but messed-up indentation.


Alex

 

[Aaron]

Oh wow. it never crossed my mind...

Can screen reaaderss be customized?
Maybe their is a way to get the screen reader to say indent and dedent
at thee appropriate places?
Or maybe a filter to put those wordds into the source?

- Paddy.

Interestingly enough, there is a feature in my screenreader that purports to
do just that, but it has proven unreliable at best. I think a filter to
insert an indent indicator at the beginning of each line would not be too
practical, as it would make copy and paste operations from one indentation
level to another rather tedious (you'd have to add or remove one or more
indicators from each line of code).

Finally, just to be clear, I do not want to change the way 99.9% of Python
code is written. I feel that the indentation model is a good one for 99.9%
of users. What I do want to do is simply give the Python interpreter a tiny
bit more flexibility to handle code from users or environments where
indentation is not possible or practical.

Aaron

 

[O.R.Senthil Kumaran]

Hi Aaron,

Finally, just to be clear, I do not want to change the way 99.9% of Python
code is written. I feel that the indentation model is a good one for 99.9%
of users. What I do want to do is simply give the Python interpreter a tiny
bit more flexibility to handle code from users or environments where
indentation is not possible or practical.

It never crossed my mind about the problem you have mentioned.
The indentation proposal that you have put forth is infact a beaten up one, and I think, python gurus did not subscribe to it. Your requirement, in fact requests to look at it from a new perspective.
We got to figure out what the different ways in which this issue can be handled.a) Screen Reader Clients. Can Screen Reader have a plugin, that will overlay a brackets to the indented code. ?
b) How does software like voicecode handle the scenario?
c) Have you spoken to other python programmers like you? I can remember 'Peter Lundblad' who works on 'svn' and I kind of feel that he must have worked on Python as well. They will be your best guide, IMHO.

 

[Dennis Lee Bieber]

column to make sure that everything lines up. I, on the other hand,
generally find my self counting a lot of spaces.

Forgive me, but that sounds like a valid excuse for me to suggest
near heresy... and that TABS should be the standard indent mechanism,
not spaces...

I'd much rather hear: tab tab tab print
than: space space space space space space space space space space space
space space space space space space space space space space space space
space print
(that many as the Python definition of a tab is eight spaces)
--
Wulfraed Dennis Lee Bieber KD6MOG
(e-mail address removed) (e-mail address removed)
HTTP://wlfraed.home.netcom.com/
(Bestiaria Support Staff: (e-mail address removed))
HTTP://www.bestiaria.com/

 

[James Stroud]

Forgive me, but that sounds like a valid excuse for me to suggest
near heresy... and that TABS should be the standard indent mechanism,
not spaces...

I'd much rather hear: tab tab tab print
than: space space space space space space space space space space space
space space space space space space space space space space space space
space print
(that many as the Python definition of a tab is eight spaces)

What's wrong with just saying the current indent level? I'd much rather
hear "indent 4" than "tab tab tab tab".

James

 

[Michael Tobis]

What's wrong with just saying the current indent level? I'd much rather
hear "indent 4" than "tab tab tab tab".

Alternatively, you might also consider writing a simple pre and
postprocessor so that you could read and write python the way you
would prefer

In that you could cope with the existing code base and the existing
compiler could cope with code you write.

mt

 

[Jakub Stolarski]

Why not just use comments and some filter. Just write # _{ at the
beginning and # _} at the end. Then filter just before runing
indenting with those control sequences? Then there's no need to change
interpreter.

 

[Aaron]

Alternatively, you might also consider writing a simple pre and
postprocessor so that you could read and write python the way you
would prefer

In that you could cope with the existing code base and the existing
compiler could cope with code you write.

mt

Hi.

That's probably what I'll end up doing. The only drawback to that is that
it solves the problem for me only. Perhaps I will open source the scripts
and write up some documentation so that other folks in a similar situation
don't have to reinvent the wheel. The only unfortunate aspect to that is
that blind newbies to the language will have to figure out setting up a
shell script or batch file to pipe the output of the filter into Python on
top of learning the language. I admit, it's probably not that much work,
but it is one more stumblingblock that blind newcomers will have to
overcome.

Aaron

 

[Terry Reedy]

If there is not one already, a page for blind and visually impaired
programmers on the Python site would be a good addition.

 

[Alex Martelli]

Why not just use comments and some filter. Just write # _{ at the
beginning and # _} at the end. Then filter just before runing
indenting with those control sequences? Then there's no need to change
interpreter.

As I pointed out in another post to this thread, that's essentially what
Tools/scripts/pindent.py (part of the Python source distribution) does
(no need to comment the beginning of a block since it's always a colon
followed by newline; block-end comments in pindent.py are more
informative). Just use and/or adapt that...


Alex

 

[Alex Martelli]

That's probably what I'll end up doing. The only drawback to that is that
it solves the problem for me only. Perhaps I will open source the scripts
and write up some documentation so that other folks in a similar situation
don't have to reinvent the wheel.

As I pointed out in another post to this thread,
Tools/scripts/pindent.py IS open-source, indeed it's part of the Python
source distribution. Why not use and/or adapt that?

The only unfortunate aspect to that is
that blind newbies to the language will have to figure out setting up a
shell script or batch file to pipe the output of the filter into Python on
top of learning the language. I admit, it's probably not that much work,
but it is one more stumblingblock that blind newcomers will have to
overcome.

pindent.py's approach ensures that the tool's output is also entirely
valid Python (as it only adds comments to mark and "explain" block
ends!) so no "piping the output into Python" is at all needed; you only
need (editor-dependent) to ensure pindent.py is run when you LOAD a
Python source file into your editor. If anything, pindent.py and/or the
screen reader of choice might be tweaked to "read out" Python sources
more clearly (e.g. by recognizing block-end comments and reading them
differently than other comments are read).


Alex

 

[Alex Martelli]

Alternatively, you might also consider writing a simple pre and
postprocessor so that you could read and write python the way you
would prefer

As I pointed out in another post to this thread, that's essentially what
Tools/scripts/pindent.py (part of the Python source distribution) does.
Just use and/or adapt that...


Alex

 

[Paddy]

...


Open-source ones surely can (e.g., NVDA is an open-source reader for
Windows written in Python, <http://www.nvda-project.org/> -- alas, if
you search for NVDA Google appears to be totally convinced you mean
NVidia instead, making searches pretty useless, sigh).


There definitely should be.


.../Tools/scripts/pindent.py (comes with the Python source distribution,
and I hope that, like the whole Tools directory, it would also come with
any sensible packaged Python distribution) should already be sufficient
for this particular task. The "indent" always happens (in correct
Python sources) on the next line after one ending with a colon;
pindent.py can add or remove "block-closing comments" at each dedent
(e.g., "# end for" if the dedent is terminating a for-statement), and
can adjust the indentation to make it correct if given a Python source
with such block-closing comments but messed-up indentation.

Alex

Aaron, here's the comment at the beginning of the script. Would it
work for you?

# This file contains a class and a main program that perform three
# related (though complimentary) formatting operations on Python
# programs. When called as "pindent -c", it takes a valid Python
# program as input and outputs a version augmented with block-closing
# comments. When called as "pindent -d", it assumes its input is a
# Python program with block-closing comments and outputs a commentless
# version. When called as "pindent -r" it assumes its input is a
# Python program with block-closing comments but with its indentation
# messed up, and outputs a properly indented version.

# A "block-closing comment" is a comment of the form '# end <keyword>'
# where <keyword> is the keyword that opened the block. If the
# opening keyword is 'def' or 'class', the function or class name may
# be repeated in the block-closing comment as well. Here is an
# example of a program fully augmented with block-closing comments:

# def foobar(a, b):
# if a == b:
# a = a+1
# elif a < b:
# b = b-1
# if b > a: a = a-1
# # end if
# else:
# print 'oops!'
# # end if
# # end def foobar

# Note that only the last part of an if...elif...else... block needs a
# block-closing comment; the same is true for other compound
# statements (e.g. try...except). Also note that "short-form" blocks
# like the second 'if' in the example must be closed as well;
# otherwise the 'else' in the example would be ambiguous (remember
# that indentation is not significant when interpreting block-closing
# comments).

# The operations are idempotent (i.e. applied to their own output
# they yield an identical result). Running first "pindent -c" and
# then "pindent -r" on a valid Python program produces a program that
# is semantically identical to the input (though its indentation may
# be different). Running "pindent -e" on that output produces a
# program that only differs from the original in indentation.

# Other options:
# -s stepsize: set the indentation step size (default 8)
# -t tabsize : set the number of spaces a tab character is worth
(default 8)
# -e : expand TABs into spaces
# file ... : input file(s) (default standard input)
# The results always go to standard output

# Caveats:
# - comments ending in a backslash will be mistaken for continued
lines
# - continuations using backslash are always left unchanged
# - continuations inside parentheses are not extra indented by -r
# but must be indented for -c to work correctly (this breaks
# idempotency!)
# - continued lines inside triple-quoted strings are totally garbled

# Secret feature:
# - On input, a block may also be closed with an "end statement" --
# this is a block-closing comment without the '#' sign.

# Possible improvements:
# - check syntax based on transitions in 'next' table
# - better error reporting
# - better error recovery
# - check identifier after class/def

# The following wishes need a more complete tokenization of the
source:
# - Don't get fooled by comments ending in backslash
# - reindent continuation lines indicated by backslash
# - handle continuation lines inside parentheses/braces/brackets
# - handle triple quoted strings spanning lines
# - realign comments
# - optionally do much more thorough reformatting, a la C indent

-Paddy

 

[Dennis Lee Bieber]

What's wrong with just saying the current indent level? I'd much rather
hear "indent 4" than "tab tab tab tab".

Well... the latter doesn't require a Python aware vocalizer... <G>

Though yes... something that would report on repeated "whitespace"
would be nicer... "four-tabs" vs "32-spaces" <G>

--
Wulfraed Dennis Lee Bieber KD6MOG
(e-mail address removed) (e-mail address removed)
HTTP://wlfraed.home.netcom.com/
(Bestiaria Support Staff: (e-mail address removed))
HTTP://www.bestiaria.com/

 

[proteusguy]

Hello all.

I realize that proposals dealing with alternatives to indentation have been
brought up (and shot down) before, but I would like to take another stab at
it, because it is rather important to me.

I am totally blind, and somewhat new to Python. I put off learning Python
for a long time, simply because of the indentation issue. There is no easy
way for a screenreader user, such as my self, to figure out how much a
particular line of code is indented. A sited person simply looks down the
column to make sure that everything lines up. I, on the other hand,
generally find my self counting a lot of spaces.

<snip>

Very interesting 'reading' code verbally. I would think this would
be far less efficient than using a braille line display, especially if
there were a multi-line display which I'm not sure exists (but
should). Anyway, as someone who is a very fond of python's use of
indentation for flow control, I also see that it is not always
appropriate for EVERY form of computing I'd like to apply python too
and I wish there were an alternative control flow form which was
considered valid in all respects but frowned upon when not used in the
exception cases intended. Also it should be a form in which a parser
could easily convert back and forth from at ease so you could code in
one format and deploy in another.

Besides your excellent example, the context that I have in mind is
embedded python running in a web browser ala javascript. You
absolutely cannot count on whitespace when your code is going through
the parser/converter gauntlet that the typical html page must go
through before being delivered to its requestor. As a student of
language design I find javascript an abomination and have long
wondered whether or not this dependency on whitespace hasn't taken
python out of the running from being a very popular and appropriate
contender. (I realize that the restricted execution environment of old
python was abandoned but maybe browser python is a strict subset?)

I really am not at the point of making this a proposal. Really I'm
just curious as to whether or not I'm the only person who thinks this
and would like to see if the concept has any traction. This is no low
impact concept so I'm not holding my breath. I will say, however, that
the web browser would be a far more pleasant development environment
if it spoke python rather than javascript. I feel strongly that its
the best internet service language (wonderful std libs) and its OO and
functional paradigm would play nicely in a browser environment. I have
python on all my computers regardless of operating system and cpu. I
have python embedded in C++ apps and C++ apps embedded in python.
Python runs on my phone! Python runs on the JVM and the CLR. Python
runs everywhere - except my browser.

...just dreaming...

-- Ben