do {
c = getNextChar()
} while c != ‘\0’ {
processChar(c)
}
I'd prefer:
loop {
c = getNextChar()
break if c == ‘\0’
processChar(c)
}
The eyesight rationale for curly braces (screen readers) is something I had never considered. But it would be nice if they were optional. I've been writing Python for 14 years and have never had a problem with mis-indenting.
Edit: I had to correct my post because Tabs were used in the original, so alignment was all wrong.
As someone who has some difficulty with reading sometimes, I find Python's way of doing things to be a genuine readability challenge. Python's the language I get paid to write, but, if I thought I could get away with it at work, I might try advocating we try out Hy simply so I could return to a world of having visible, non-whitespace delimiters to aid me in reading code.
I don't want to make too much hay about my challenges because I'm not sure they realistically qualify as a disability. But my own meager experience in this department does demonstrate to me first-hand that "it would be nice if accessibility affordances were optional" largely defeats the purpose of accessibility.
Arguments about what's easy to do in any editor lose a bit of their shine in the post-GitHub era. Barring the development of a really good language-aware semantic diff algorithm that I'm guessing doesn't exist yet, you really do need to have a consistent coding standard everywhere if you want to avoid injecting unnecessary chaos (and, in this case, accessibility challenges) into exactly the parts of the modern software development lifecycle where code readability is most important.
Edit: I had to correct my post because Tabs were used in the original, so alignment was all wrong.