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

[Donald Stufft]

I don't always post to python-dev, but when I do I ask for braces.

On Friday, December 9, 2011 at 4:43 PM, Antoine Pitrou wrote:

>  
> Dear Cedric,
>  
> I'm guessing you drank too much (perhaps you are training for New Year's
> Eve), ate some bad sausages or are simply very self-complacent.
> python-dev is not the place where to post long unstructured ramblings
> with no practical value. Consider writing on your personal blog
> instead.
>  
> Thank you
>  
> Antoine.
>  
>  
>  
> On Fri, 9 Dec 2011 21:26:29 +0100
> Cedric Sodhi <manday at gmx.net (mailto:manday at gmx.net)> 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/donald.stufft%40gmail.com
>  
>  


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20111209/6c5be866/attachment-0001.html>