Compare source code

[Steven D'Aprano]

On Wed, 03 Nov 2010 23:09:10 +0000, Seebs wrote:

> On 2010-11-03, Steven D'Aprano <steve-REMOVE-THIS at cybersource.com.au>
> wrote:
>> Yes. How does that contradict what I said?
> 
> Once you understand that you do have to break the rules occasionally, it
> is a good idea to design things that will be robust when the rules are
> broken.

That does not follow.

As a general rule, one should not expect that electronic equipment should 
be safe to operate under water. But there are exceptional cases. So what 
should we do?

(1) Insist that all consumer electronic equipment is designed to operate 
under water? (All blocks need redundant START/END tags just in case 
you're operating in an environment where indentation can't be trusted.)

(2) Tell people not to drop their toaster into the bath tub, and leave it 
up to the exceptional cases to deal with the need for water-proof 
electronics in whatever way they see fit? (Trust the indentation, tell 
people not to mangle their source files with dodgy mail servers, and if 
you need redundant tags, build your own solution.)



>> Ah, argument by misunderstanding the Zen!
> 
> I see.  So explicit boundaries are a good thing, except when they are
> one specific special case.

INDENT/OUTDENT is an explicit boundary.


> Let us imagine a hypothetical mirror-universe person, who is otherwise
> like you, but:
> 
> 1.  Has a goatee.
> 2.  Actually hates the indentation rules, wishes Python had braces, but
> has become emotionally invested in defending the status quo because if
> he had to suffer, dammit, everyone else should have to suffer too.

I had to suffer?

Funny, I hardly noticed.


 
> You have not yet made a single argument that he wouldn't have made too.

The arguments Evil-Steven would make would be your arguments:

* redundant BEGIN/END tags make blocks robust in environments where 
indentation can't be trusted;

* there are tools out there that assume that indentation is meaningless, 
and some people want to use those tools, so the language is poorly 
designed;

I *understand* your arguments, I just don't value them. But in fact, non-
evil Steven made the opposite arguments:

Re extra redundancy: you aren't going to need it often enough to make up 
for the extra effort of dealing with BEGIN/END tags that can contradict 
the indentation.

Re tools: if the tools don't fit your use-case, your tools are broken, 
and you should change your tools.



>>> It is *better* to explicitly mark the ends of things than to have it
>>> be implicit in dropping indentation. That's not a burden, it's good
>>> engineering practice.
> 
>> Python does explicitly mark blocks. It does it by changes in
>> indentation. An indent is an explicit start-block. An outdent is an
>> explicit end- block. There is nothing implicit in a change in indent
>> level.
> 
> What's the token that marks the end of a block, corresponding to the
> colon used to introduce it?

Your assumption is incorrect. Blocks are introduced by an increase in 
indentation level, not by a colon. The colon is enforced, but it's there 
for the benefit of readability rather than to mark a new block. You can 
write:

if condition: true_clause()
else: false_clause()

No blocks are started, the clauses are limited to a single line, but the 
colons are still required.

To end the block, you need a decrease in indentation limit. In fact, the 
Python parser actually places overt INDENT/OUTDENT tokens into the token 
stream.

# From token.py:
INDENT = 5
DEDENT = 6


>> It simply isn't possible to have implicit start/end block markers,
>> unless you restrict your language in ways that exclude most blocks.
>> E.g. if all if blocks were restricted to a single statement, then you
>> could have an implicit block -- the block in one statement. Stating
>> that Python uses implicit block markers is simply wrong.
> 
> No, it isn't.  There's no token telling you where the block ended.

I disagree, but for the sake of the argument let's suppose you are 
correct. So what?

x = 123+456

There's no tokens telling you where the ints 123 and 456 begin and end 
either. So where's the problem?

Signals, or tokens if you like, can be explicitly made either by placing 
a distinct marker (a delimiter or separator), or by a change of state. In 
the case of ints, the explicit end-of-token is a change of state, not a 
marker:

digit digit digit non-digit

There's no need for a distinct End Of Int marker, because the change of 
state is explicit enough. But this is not the case for strings, which you 
mentioned in an earlier post. Strings require a special BEGIN/END tag 
because they may be terms in expressions and you can't assume they will 
end at the end of the line (a change of state).

If you have an environment where strings do end at the end of the line, 
such as INI files, you can avoid the delimiters:

[section]
x = Hello world.
y = Goodnight Gracie!


but in a general purpose programming language where strings can be terms 
in expressions, you need delimiters.

Blocks are more like ints than strings. They don't need delimiters, 
because they start and end according to an explicit change of state.


-- 
Steven