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

[Xavier Morel]

On 2011-12-09, at 21:26 , Cedric Sodhi wrote:
> 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
You do know braces are already in __future__ right?

Also, why did you feel the need to post eleven thousand (1100) words on a topic settled more than a decade ago (Wed Feb 28 17:47:12 2001 +0000).

As far as I can see, you also don't provide any argument towards making the language more complex beyond you not liking its current state. Your whole email is word-salad circling around that, and your finding insufficient tooling a reason to alter the language to fit the tool instead.

PS: Haskell's core syntax is defined through braces and semicolons, and "layout" (also called "off-side rule") is added to allow getting rid of these when writing code.

I do not remember *ever* seeing Haskell code written by a human which used braces. Not in repositories, not in blogs, not in forums, not in mailing lists, not anywhere.

If the issues of indentation-based blocks were as dire as you seem to believe, this would not be possible, as developers would flock towards "safer" delimiter-block syntax, but facts belie your assertions, and explicit braces are instead relegated to generated code.

Which could be a defense of adding braces to Python, but really, if you're generating Python code I think you should generate bytecode directly to ensure nobody will go editing generated code. Hence the issue of having to generate indentation is not an issue.