[Python-Dev] [PATCH] Adding braces to __future__
python-dev at masklinn.net
Fri Dec 9 22:02:54 CET 2011
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
> 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
> 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.
More information about the Python-Dev