[Python-Dev] [PATCH] Adding braces to __future__

[Cedric Sodhi]

IF YOU THINK YOU MUST REPLY SOMETHING WITTY, ITERATE THAT THIS HAD BEEN
DISCUSSED BEFORE, REPLY THAT "IT'S SIMPLY NOT GO'NNA HAPPEN", THAT "WHO
DOESN'T LIKE IT IS FREE TO CHOOSE ANOTHER LANGUAGE" OR SOMETHING
SIMILAR, JUST DON'T.

Otherwise, read on.

I know very well that this topic has been discussed before. On forums.
Mailing lists. IRC. Blogs. From person to person, even.

And I know equally well, from all those years experiencing
argument-turned-debates on the internet, how a (minor|major) fraction of
participants make up for their inability to lead a proper debate by
speaking the loudest of all, so that eventually quantity triumphs over
quality and logic.

That ahead; I hope you can try not to fall in that category. Let instead
reason prevail over sentimentalism, mislead purism, elitism, and all
other sorts of isms which hinder advancement in the greater context.

Python has surprised once already: The changes from 2 to 3 were not
downwards compatible because the core developers realized there is more
to a sustainable language than constantly patching it up until it comes
apart like the roman empire.

Let's keep that spirit for a second and let us discuss braces, again,
with the clear goal of improving the language.

End of disclaimer?

End of disclaimer!

Whitespace-Blocking (WSB) as opposed to Delimiter-Blocking (DB) has
reasons. What are those reasons? Well, primarily, it forces the
programmer to maintain well readable code. Then, some might argue, it is
quicker to type.

Two reasons, but of what importance are they? And are they actually
reasons?

You may guessed it from the questions themselves that I'm about to
question that.

I don't intend to connote brazen implications, so let me spell out what
I just implied: I think anyone who thinks that exclusive WSB is a good
alternative or even preferable to DB is actually deluding themselves for
some personal version of one of those isms mentioned above.

Let's examine these alleged advantages objectively one for one. But
before that, just to calm troubled waters a little, allow me bring
forward the conclusion:

Absolutely no intentions to remowe WSB from Python. Although one might
have gotten that impression from the early paragraphs, no intentions to
break downwards compatibility, either.

What Python needs is an alternative to WSB and can stay Python by still
offering WSB to all those who happen to like it.

Readable code, is it really an advantage?

Two linebreaks, just for the suspense, then:

Of course it is.

Forcing the programmer to write readable code, is that an advantage? No
suspense, the answer is Of course not.

Python may have started off as the casual scripting language for casual
people. People, who may not even have known programming. And perhaps it
has made sense to force -- or shall we say motivate, since you can still
produce perfectly obfuscated code with Python -- them to write readably.

But Python has matured and so has its clientele. Python does not become
a better language, neither for beginners nor for experienced programmers
who also frequently use Python these days, by patronizing them and
restricting them in their freedom.

Readable code? Yes. Forcing people to write readable code by artificial
means? No.

Practice is evidence for the mischief of this policy: Does the FOSS
community suffer from a notorious lack of proper indention or
readability of code? Of course we don't.

I'm not a native speaker, but dict.cc tells me that what we call "mit
Kanonen auf Spatzen schießen" (firing cannons at sparrows) is called
breaking a fly on the wheel in English.

I may lack the analogy for the fly on the wheel, which, if I'm not
mistaken, used to be a device for torture in the Middle Ages, but I can
tell you that the cannon ball which might have struck the sparrows,
coincidently caused havoc in the hinterlands.

For the wide-spread and professional language Python is today, the idea
of forcing people to indent is misguided. These days, it may address a
neglible minority of absolute beginners who barely started programming
and would not listen to the simple advice of indenting properly, but on
the other hand it hurts/annoys/deters a great community of typical
programmers for whom DB has long become a de facto standard.

For them, it's not a mere inconsistency without, for them, any apparent
reason. It's more than the inconvenience not being able to follow ones
long time practices, using the scripts one wrote for delimiters, the
shortcuts that are usually offered by editor, etc.

It also brings about a whole class of new problems which may be
anticipated and prevent, yet bear a great potential for new, even
hard-to-find bugs (just in case anyone would respond that we had
eventually successfully redeemed the mismatched parenthesis problem - at
what cost?!).

Not just difficult to find, near to impossible would be the right word
for anyone who has to review someone else's patch.

It is widely known among the programmer's community that spaces and tabs
are remarkably similar to eachother. So similar even, that people fight
wars about which to use in a non-py context. It might strike one as an
equally remarkably nonsensical idea to give them programmatic meaning -
two DIFFERENT meanings, to make things even worse.

While it becomes a practical impossibility to spot these kind of bugs
while reviewing code -- optionally mangled through a medium which
expands tabs to whitespace, not so much of a rarity -- it is still a
time-consuming and tedious job to find them in a local situation.

More or less easily rectified, but once you spent a while trying to
figure something like that out, you inevitably have the urge to ask: Why?

Last of all, some might argue that it's convenient to not to have type
delimiters. Well, be my guest. I also appreciate single lined
conditional or loops once in a while. I understand how not having to
type delimiters if you don't want them lifts a burden. Hence I would not
want rid Python of them. WSB may come in handy. But equally, it may not.

Proposing the actual changes that would have to be made to accomodate
both, WSB and DB is beyond the scope of this script. It is the
CONCLUSION that the current situation is undesirable and Python,
although not apparent at the first glance, suffers from exclusive WSB,
which is the goal of this thread.

Discussing has its etymological roots in Discourse, which connotes a
loosely guided conversation about a topic. Therefore, I conclude with a 

DEBATE!!!111

kind regards,
-- MD

(not proof-read)