On 04/16/2015 01:41 PM, Steven D'Aprano wrote:
>2. Having been an employer, it is difficult to force programmers to use
>any particular editor or style. Different editors handle tabs and spaces
>differently. This is all a bloody nightmare with Python.
Do you really expect us to believe for a microsecond that the choice
between "4 spaces" or "tab" is worse than the C brace wars?
You know I've never thought braces where the problem in a language, and in
python, not having them isn't a problem either.
The reason I dislike C is due to the amount of boiler plate and the low
level of code, which requires managing memory, declaring prototypes and
including headers. All of which I think are much more troublesome and
harder to get right than any amount of braces.
Both sides have advantages, but Python's design is meant to represent code
in an easier to see and read way. Representing blocks by indention is
consistent with that. (And so is outlines in written language.)
I could equally like a language where blocks are literal code objects that
can be assigned to names. In that case the block delimiters would be
consistent with that language design and that would be perfectly fine to
me. The code would be representing what it does in an expected and useful way.
block = {statement_1; statement_2; ...}
The cases in between seem a bit unclean to me however. Where braces are
used to define blocks that aren't exposed. I think it's ok, but it also
seems a bit unclean to me. Adding more noise than necessary to the code.
But I understand at some time, when a language was designed it may have
been that it made parsing the language simpler. (it does.) Or it may have
just been the language designers preference at that time. <shrug>
But still, I think the whole braces are good/evil is over stated. There
are lots of more important things in languages to consider.
Cheers,
Ron
--
https://mail.python.org/mailman/listinfo/python-list
