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

[Jesse Noller]

On Friday, December 9, 2011 at 3:26 PM, 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 (http://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)
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org (mailto:Python-Dev at python.org)
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/jnoller%40gmail.com


+1