Compare source code
steve-REMOVE-THIS at cybersource.com.au
Thu Nov 4 08:33:14 CET 2010
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>
>> 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
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
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
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
> 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
if condition: true_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
# 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
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:
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.
More information about the Python-list