Why not allow empty code blocks?

[Jonathan Hayward]

I might point out something that captures something about pass: it is made
to do extra duty in web2py, which is meant to shield students from some of
the more preventable complexities of a LUM CLI, and you don't easily indent
code the way that Vim and Emacs, let alone a full IDE besides the IDE
nature of web2py, forces people to deal with. People getting up to speed
with Vim or Emacs, for anything that is usually indented, find and/or seek
out how to maintain indentation without hitting the space bar 4/8/12/...
times at the beginning of the next line.

And it works. It was probably not intended or even anticipated in the
design of Python, but my understanding is that the adapted usage works well.

And if I may put on asbestos longjohns, there is no reason I am aware of
why syntactic sugar, in the style of Python-influenced Coffeescript, could
not be modified to make "from __future__ import braces" represent a live
and active feature. The net effect of significant whitespace in Python is
that it provides one model to "say what you mean and mean what you say",
and everybody who understands the language recognizes the beginning and end
of a block, the end of a statement, a noop, etc. And this is pretty much
the job description of C-family language syntax etc. Now there are
advantages, namely no braces and no brace holy wars either, fewer Perlish
sigils as even a statement is usually ended by line break, and so on. But
Python-style and C-style syntax alike provide an unambiguous tool to
specify what you want, and an unambiguous means of interpreting what was
actually said. The non-C-style syntax was the biggest "steaming pile of
dinosaur dung" hurdle before ESR appreciated the language, but Python
syntax and C-style syntax are both adequate. They may or may not be equal,
but every instance of code which unambiguous Pythonic syntax is underscored
is an effect that should usually be equally easy to implement with C-style
syntax.

On Sun, Jul 24, 2016 at 1:14 PM, BartC <bc at freeuk.com> wrote:

> On 24/07/2016 15:51, Chris Angelico wrote:
>
>> On Mon, Jul 25, 2016 at 12:44 AM, BartC <bc at freeuk.com> wrote:
>>
>>> Your attention is diverted, you're doing something on your desk, but you
>>> hit
>>> one of the keys by mistake. You might have pressed Delete or you might
>>> not.
>>> You look at the screen which has a 5000-line program open, and you see
>>> this
>>> (borrowing your example and with the cursor at "_"):
>>>
>>>  def f():
>>>      for x in seq:
>>>          do_this()
>>>          do_that()
>>>  _   do_more()
>>>
>>> Did you just unindent do_more(), or is that where it's meant to be? Undo
>>> may
>>> or may not help (or it may undo something is needed).
>>>
>>
>> Undo, redo. See what happened. Easy.
>>
>> Also, if you're regularly committing to source control, you can always
>> check the diff. Before you 'git commit', check what 'gitk' shows, or
>> before 'hg commit', have a glance at 'hg diff'. Make sure what you're
>> seeing is what you intend to change. Remember, code doesn't just
>> accidentally change; everything should have purpose, including
>> (especially) any indent/unindent.
>>
>> Source control protects you from everything other than multiple
>> changes since the last commit. So commit often. It'll save you a lot
>> of time - if not coding time, then debating-on-python-list time. :)
>>
>
> OK. I understand that it is not possible to point out any kind of weakness
> of a language (any language not just Python!) because the counter-argument
> is always going to be about:
>
> Use syntax highlighting, use a smart editor, use a version control system,
> use a linter, use 'tabnanny', use tool X, Y or Z to get around the
> problems, use obscure language options..
>
> The thing is, if everyone does depend more on such tools, then it really
> doesn't matter exactly what the language does - the tools will take care of
> such details. So the language could delimit blocks using any scheme it
> likes, including use 'end', 'else' and so on.
>
> It only becomes important to people like me who use plain editors.
>
> --
> Bartc
>
>
> --
> Bartc
> --
> https://mail.python.org/mailman/listinfo/python-list
>



-- 
[image: Christos Jonathan Seth Hayward] <https://cjshayward.com/>
*Jonathan Hayward*, a User Experience professional.

Email <cjsh at cjshayward.com> • Flagship  <https://cjshayward.com/>Website
<https://cjshayward.com/> • Github
<https://github.com/jonathanhayward> • *LinkedIn
<http://www.linkedin.com/in/jonathanhayward>* • Portfolio + More
<http://jonathanhayward.com/> • *Recent Title
<https://www.packtpub.com/application-development/reactive-programming-javascript>*
 • Skills <http://jsh.name/>

Loads of talent and a thorough grounding in all major academic disciplines
supporting User Experience.