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. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
