Blocks that are normally indented now have to be closed explicitly with an end keyword.
I see what they did there.
Highly un-Python-ic: a new keyword to close the if/for/etc statements.
But it is a confirmation of my own conclusion that with the vanilla Python syntax that is impossible to accomplish.
Python support for me wasn't as important. I simply wanted to see and compare use of different languages in such context. And see whether a generic, language-neutral preprocessor makes any sense. (Here it is, btw.)
(Source: personal experience. I work on a Python IDE that has to deal with lots of that kind of stuff for e.g. implementation of refactoring. Once we had our whitespace-preserving AST, the rest was and remains easy.)
You have different use case, which is 100% controlled code. IOW, you can rely on the original indentation to create the AST.
My use case is:
{user-start-code}
{generated-code}
{user-finish-code}
where "user-*-code" is an arbitrary user supplied string.
If the user start/finish code is just a function call, then it is all fine.
But if the user code is "if something:{CR}{TAB}aaaa", then the user intent simply can't be made clear from the Python's syntax: (A) is it "if (something) { aaaa }" or (B) it is "if (something) { aaaa" (and the closing "bracket" is in the finish code).
I've spent few hours tinkering, but there is simply no way to tell A from B definitively in the Python's syntax.
P.S. It is a sort of preprocessor, which allows to mix plain text with an arbitrary language. In generated output, the plain text is simply replaced with the print statements.
Oh this is just a load of.
On C/C++/Java code you can always run an formatter, and reformat it to your reading pleasure.
Ever wondered why there is no such tools for Python?
And I have seen enough of the crappy Python code too. It looks different from the C-like languages, but the shitty OOP is a shitty OOP in any OO language.
Different syntax is not a solution to any problem.
Wow.
Removing the ability to screw things up is NOT a bad thing
Can you please elaborate how use of whitespaces for defining control flow is "removing the ability to screw things up"?
If nothing else, use of the invisible characters for something as important as control flow is actively helping "the ability to screw things up".
But does that mean I'm going to poo-poo those languages or try to pretend they're inferior?
The problem is, Python is inferior. Because it provides less tools to its developers.
It's not like C lets you change which brackets do what, does it?
But C does have at least some brackets.
It does have clear visual clues and delimiters in its syntax.
Haha, here you all complain that Java is too fluffy, but if a language reduces the fluff it is also not good?
Oh this hipster coders.
Syntax is not fluff.
Wrappers for wrapper for adapters for wrappers - commonly found in the huge, so called "enterprise" software, is fluff.
In the case of Python, instead of intro/outro curled brackets or begin/end statements AND REDUNDANTLY indenting, using only one of the two was chosen. Why do it twice.
Language is a tool.
It should give me, the developer, the choice - not take it away from me.
As I have recently found out, that also affects the code generation.
It is hard to generate Python code, without actually analyzing what's precisely is being generated. If source is 100% generated - it is doable, relatively easy. But generally generated code also contains pieces of user code, which might/might not require its own indentation and also reindentation to make it proper part of the generated code.
If Python at least allowed optional block statement - curly brackets or begin/end or whatever. But nope. It is appears to be sort of a religious issue for the language creator and some of his followers.
I personally do not like Python for that reason. I prefer to have a visual marker that block is closed. You know, like a dot at the end of the sentence.
Honestly, to this day, as books concerned, I do not know the difference between "fiction" and "non-fiction".
On more than one occasion I was told that the "fiction" is a genre of its own, not related to the sci-fi and the fantasy, which I read the most.
P.S. Since it is a
... it is unclear...
But that would have made a pretty poor headline or summary.
Can't read past the headline?
The bigger message that Samsung is going to make most of the bloatware uninstallable and optionally downloadable has been completely ignored here.
Instead of praising Samsung for the move, everybody jumped on the hate train as soon as they have seen word "Microsoft" in the headline.
It's not like any blog hosting/software would be different. One still have to register to leave a comment - as it always was.
But they also probably are not slaving 8-5 in the office, suffer no daily commute and no fast-food treatment due to the periodic emergencies in the office.
Apples to oranges.
It is the same as with the fight against smoking.
Some science heads, beyound their health effect studies, are simply incapable of seeing the simple primitive truth of the smoking: it is a *social* habit.
It is not about smoking per se, it is about a short break from the daily routine and a chance of sharing five minutes with your buddies.
A study in the British Medical Journal shows that consuming alcohol — any volume, any type — does not increase life expectancy.
That is the type of conclusions you get when you entrust research to the "scientitsts" types who never leave the lab.
Alcohol helps overcome stress, which otherwise would cause more harm to health than the alcohol
Alcohol helps to "loosen" up, which these days seems to be the only reason why western civilization is still procreating. Being born is the biggest health benefit a human can experience in their life.
And of course it would fail, because every OEM claiming to support the spec, in cost-cutting attempts, would cripple their implementations.
ARM is all about being cheap. And Linux is cheap too. Sadly that also attracts manufacturers who are cheap too. With all the consequences.
Understanding is always the understanding of a smaller problem in relation to a bigger problem. -- P.D. Ouspensky
