Why not allow empty code blocks?

BartC bc at freeuk.com
Sun Jul 24 18:13:30 EDT 2016


On 24/07/2016 22:08, Chris Angelico wrote:
> On Mon, Jul 25, 2016 at 6:03 AM, BartC <bc at freeuk.com> wrote:

>> Perhaps because I prefer to use my own languages and I don't have anyone
>> writing the specialist tools for me that would be necessary.
>
> So because you've chosen to use your own languages, you are frustrated
> at Python because you're not using a decent editor?

My point is that with a bit more thought into the design of a language, 
clever tools would be less important. A language should stand by itself 
and not lean on specialist tools to be make it more usable.

A solid end-of-block symbol (as you get with 'else' and 'except' because 
then you KNOW that's the end of that block) would have been welcome with 
the Python indent scheme.

> Get yourself
> something nice and configurable, so that when you open a Python file
> it gives you the features you need. I use SciTE,

I have one big problem with most editors (including SciTE): they are not 
properly line-oriented. If you hold down Backspace in the middle of a 
line, it won't just delete until it hits the beginning of the line; it 
keeps going! I can't live with that: editing would be like walking on 
eggshells. I need hard line stops. (I can't touch type; I need to look 
at the keyboard a lot.)

(And SciTE won't support a custom language for highlighting and stuff. 
Maybe it's configurable, but there seems to be a lexer module that needs 
to be provided. Suddenly it seems a lot of work to do.)

> Why is this such a problem? Why is it so hard?

Who says it's a problem? I'm quite happy with the screen editors I use 
that are little changed since the early 80s (and before that I used line 
editors; now those /were/ horrible).

>> You might know that type declarations in C, as soon as you go beyond the
>> basics, become completely impossible and convoluted.

> When do you get those uber-convoluted declarations in C?

(They don't need to be elaborate to start being confusing. Take 'int 
*a[]' and 'int (*a)[]'; one of these is an array of pointers, the other 
a pointer to an array. Quite different! But which is which?

And when you start dealing with pointers to functions, now you're 
talking! And yes C++ takes this to a whole new dimension. What a 
language...)

>> And for block delimiting, it uses neither tabbed indents or braces!)
>
> Sure. You're most welcome to use that. But it doesn't mean that Python
> is unusable.

It's not unusable. Just a minor nuisance (working with Python using my 
editor). And troublesome pasting Python code from elsewhere which is 
always full of spaces rather than tabs. (Sometimes uneven mixes of 
spaces too.)

The Python indent thing isn't a big deal. But having 'end' after each 
(final) block would have made life just a bit simpler.

The whole topic is a trivial point of syntax. (My only issue with 'pass' 
is that, for some inexplicable reason, my fingers always type it is 
'#pass'.)

> Plus, I'd much rather trust Python in production than something
> custom-made, even by me. The performance, reliability, and security of
> a well-respected language far outstrip anything I could build.

Well, performance is where I usually have an edge at the minute (with my 
own interpreted language). But if I had to recommend a language, it 
would have to be Python (I can't be dealing with users and support and 
all that...)

-- 
Bartc



More information about the Python-list mailing list