• Steve (unregistered)

    whitespace is syntactically significant in Python

    And there, ladies and gentlemen, is TRWTF

  • Robin (unregistered) in reply to Steve

    I have this argument a lot with people - but I never understand the argument. Since we surely all want consistent indentation in our code, and in many cases have linters to enforce it - what's wrong with having the language itself enforce it? Particularly when it means you can remove syntactic "noise" like curly braces and semicolons.

    (Please note that I'm not one of these Python fanboys that excuses everything about it - I can tell you plenty in Python that I dislike. But the "significant whitespace is evil" argument is certainly rubbish, imo.)

  • trainbrain27 (unregistered)

    "<abbr title="continuous integration>CI server"

    Failing at your own markdown is TRWTF.

  • NoLand (unregistered)

    Integration test failed: runaway string at <abbr title="continuous integration>.

    However, great to see some hand-coded HTML. ;-)

  • (author)

    We tend to format the articles in Markdown, but where Markdown doesn't have styling, we fallback to HTML. Yes, our article edit box is just plaintext (we had a fancy "rich text" edit box years ago, but it was honestly way worse).

  • WTFGuy (unregistered)

    It's a shame somebody like Edgar doesn't have a license that can be revoked. Between incompetence and deliberate sabotage there are no excuses for him to ever be allowed near the production code for a hotdog pushcart, much less a real product at a real company.

    And yet it's a virtual certainty Edgar is happily (for him at least) employed slinging code at some other similar business.

  • Deplatforming Food Fight (unregistered)

    License? Where's the fun in that?

    Ship Edgar overseas, where he's kept as an onsite hostage.

  • Dnrb (unregistered) in reply to WTFGuy

    Where I live you could make sure it becomes present on his V.O.G. (Conduct Decleration). Most large IT companies will ask you or your employer (detachment) to provide one. These declerations are issued by the ministery of justice.

  • Axcsje (unregistered) in reply to Dnrb

    To all non-dutch: sorry for the Dutch discussion.

    @Dnrb: It is VERY unlikely that such an action would lead to legal repercussions and therefore it will not show up on a VOG any time soon. A part of the department of justice issues those declarations and they specifically note that you will always get one if you have no criminal record.

  • Anonymous') OR 1=1; DROP TABLE wtf; -- (unregistered) 
    #define true (rand() % 1000 == 0)
  • Anonymous') OR 1=1; DROP TABLE wtf; -- (unregistered) in reply to Anonymous') OR 1=1; DROP TABLE wtf; --

    Aargh, I did it backwards. That's what I get for failing to proofread. Just pretend I wrote != instead of ==.

  • 516052 (unregistered) in reply to Robin

    The problem is that you are taking an element of the program that exists for the purposes of readability and usability and turning it into something of syntaxic importmance to the compiler. And the two aren't always in alignment.

    It's equivalent to having the paint scheme on your car effect the driving characteristics. What happens when you have to choose between it looking pretty and running at all? And it does happen.

    And of course that's before we get into the technical issues inherent with using not one but a whole array of potentially variable width characters as your syntaxic element. Is space-space-tab the same as tab-tab-space? Could be. Could not be. They "might" look identical within a text editor when looking at the code or god forbit coppying lines between two code files. But will it work?

    The whole thing must makes it incredibly easy to make tiny little mistakes, often literally invisible without counting characters using a hex editor that can wreck your entire program. That's why I much prefer properly delimited {} code blocks and keeping my "pretty" away from my "working".

  • (nodebb) in reply to Robin

    I have this argument a lot with people - but I never understand the argument. Since we surely all want consistent indentation in our code, and in many cases have linters to enforce it - what's wrong with having the language itself enforce it?

    I guess it's the difference between "it looks better if it's aligned correctly" and "it breaks horribly in weird ways if it isn't aligned correctly".

  • (nodebb) in reply to Steve_The_Cynic
    I guess it's the difference between "it looks better if it's aligned correctly" and "it breaks horribly in weird ways if it isn't aligned correctly".
    A hundred time this . When I'm writing code I want it to run regardless of what I may have copypasted. I can prettify it later.
  • (nodebb) in reply to cellocgw

    A hundred time this . When I'm writing code I want it to run regardless of what I may have copypasted. I can prettify it later.

    I code with prettier. My indentation has gotten lazier the more I know that it'll get automatically taken care of.

    I'd probably be a walking, talking menace to code if I switched to Python right now. (For a while, anyway.)

  • Dave (unregistered) in reply to WTFGuy

    I'd be astonished if there's any jurisdiction in which Edgar's actions aren't criminal, and quite seriously so given the costs incurred in rectifying the damage.

    Here, e.g.

    https://www.cps.gov.uk/legal-guidance/computer-misuse-act#_Toc532920182

  • Robin (unregistered)

    OK, the space vs tabs thing would be legitimate criticism, if it weren't so easy to configure your editor to just use one or the other (typically spaces), and a linter to forbid the other, and then just forget about it.

    (Please don't use this to get into a tabs vs spaces war, I'm actually quite unusual in that I don't much care as long as a project is consistent. Except that with Python or other "whitespace languages", spaces do make more sense.)

    So it seems the argument against basically boils down to "I prefer to write messy code while getting it to work, and only tidy it up just before I check it in". To which my reaction is, I guess, "well fine, if that's how you want it", but it seems a really weak reason to me.

    Because for me, even when working in a "braces language" - I write almost entirely Javascript in my day job - I find code I've just written to be much more understandable (and easier to spot bracketing errors in, which isn't uncommon when moving code about) when I can just look at the indentation, rather than having to count braces. (Yes, I know a simple keyboard shortcut can take you to the matching brace, but still, it's unneeded mental effort. It's not hard to use tools that "prettify" as you go, at which point the whole argument seems to me to go away.)

    And as for what seems to me to be an attempt at a "separation of concerns" style of argument, it seems to me that this could be used against several acknowledged good coding practices, like (in a compiled language) treating warnings as errors. Fundamentally, if we agree something - like inconsistent indentation - is a bad practice, I would prefer my code not to run when the bad practice is attempted. This after all is the main reason many - including me! - prefer statically typed languages, and prefer compile time errors to runtime ones.

    Sorry for the essay, I will happily agree to disagree and leave this now. I'm just surprised that those who claim significant whitespace is somehow inherently bad don't have better arguments.

  • Daniel Mercer (unregistered) in reply to Steve

    Exactly. I evaluated Python for our teams use and rejected it for just that reason. It seemed to me to be a bizarre choice for a programming language where mistakes would actually be HIDDEN from being seen.

  • (nodebb)

    The biggest practical issue with using whitespace for structure in Python is actually that it's very easy to get things mixed up when moving code around, especially between different programs (such as your IDE, browser and chat client). It also bites a bit in interactive code editing.

    The biggest related language design issue is that Python doesn't use whitespace in the same way for lists, tuples, sets and dictionaries. All those values have to have their correct initial and terminal decorations. That seems like a massive missed opportunity and lack of vision.

  • Hasseman (unregistered)

    You should chose language for the problem-domain at hand. Every language comes with pro's and con's. Some languages have ben forgotten or abandoned, new ones have come. Languages have come to make some parts easier but made other things more confusing.

    Same as computer OS. They have similarities and differences. Windows, IOS, Linux, Tops-20, MPE/IX, VMS etc all have/had their place and moved other things forward as does different languages.

    Literate Programming by Donald Knuth anyone?

  • clewis (unregistered)

    The best counter example of why the language shouldn't force the indentation I've come across: Sometimes I want the indentation to match the data structure, not the code structure.

    A long time ago, in a different life, I had to generate some complex XML. The code was pretty straight forward,

    $xml->openTag( 'foo');
$xml->addValue( $bar);
$xml->closeTag( 'foo');

    The tooling was crap, but the code was simple. So in an effort to make XML errors more obvious, I indented the code to match the data structure. It saved me a ton of time.

  • FORTRAN (unregistered) in reply to Steve

    Whitespace is syntactically significant in almost all languages after FORTRAN.

    Because FORTRAN was the language where whitespace was not syntactically significant. for clarity, I'll take examples from c, and note the FORTRAN behaviour "int K" was the same as "intK" and "else printf(K)" was the same as "elseprintf(K)"

    This was enough of a problem that /almost all subsequent languages have had syntactically significant whitespace/.

  • Josh (unregistered)

    My biggest issue with whitespace & python is this. I always write code indented where it belongs... with only two exceptions... and python prevents these.

    1. Development-only code to not be committed. I write this without any indents, right on the gutter. Sticks out like a sore thumb when reading through the code, and likewise when running git commit -p so I never miss it and therefore don't ever accidentally commit it.

    2. Adding or removing a depth (e.g. an IF statement) for a large block of code, I often commit this twice -- once as the IF statement change and other changes, but without the indent, and then a second indent-only commit. Only when the blocks are large. This makes reading the git log A LOT easier as you can see the actual change in the first commit easily, and you can also see (and fairly quickly verify) the indent change in the second commit.

  • Foo AKA Fooo (unregistered) in reply to Robin

    I agree about compile-checks as much as possible. I also use warnings about inconsistent indentation in C++ where possible (and turn them into errors like all warnings).

    However, the difference in Python is that wrongly indented code doesn't necessarily fail to run, but may run with different meaning. That, combined with the indentation being hard to impossible to see (as others mentioned) makes me uneasy about that. (Though I don't completely discard Python because of it.)

  • Foo AKA Fooo (unregistered) in reply to FORTRAN

    Not quite the same. You won't find "whitespace" in the grammar of most languages other than Python. Most languages use whitespace (or, often alteenatively, comments etc.) as token separator, but that's it.

    That's not nitpicking. It's a bug difference in compiler design (where token separation is done at the lowest level, but syntactical whitespace must be carried to the parser, counted exactly etc.), and when writing or copying or especially auto-generating code (where you can always just add another space to ensure token-separation as long as it's not syntactically relevant).

  • Foo AKA Fooo (unregistered) in reply to Foo AKA Fooo

    *big

  • Erk (unregistered)

    I'm not really fond of the "you should sue" mentality, but if I had an ex-colleague that left these kinds of surprises, I'd suggest it.

    And there's precedence for it. (Just google for "is it criminal to willfully sabotage your employer's program code?")

    On the other hand, I once consulted at a bank. They told me about some people that had been let go previously. The first thing they heard about it was when they tried to pass through the reception in the morning, and then security would pack up their things. A bit harsh. But having an Edgar lose in banking code might excuse it...

  • (nodebb)

    I'll just leave this here: if you for some reason use python, may lord love your soul and forgive all your sins, yes you have to use spaces. But if it's any other language, C- style, SQL, XML, etc., please use tabs. They allow each programmer to configure their IDE / text editor to have the tab size of their liking. Version control doesn't have to deal with determining the significance of check ins with changed leading spaces just because the editor reformatted the file. Please please please use tabs. (Except for Python)

  • 516052 (unregistered) in reply to Robin

    Quite the contrary. Not only should code be pretty from the instant you type it but that is exactly why separation of concerns is critical. Having pretty separate from functional means you can do it without fearing that your code might break. There are a million examples for this but I'll give you the lowest hanging fruit possible.

    Imagine a very long line of code. So long that it stretches far out to the right of any reasonable monitor. Now as much as we hate these they happen. LongClassName.EvenlongerMedhodName(longerClassName.StupidLongPropertyName, whyOhWhyWithTheAPI.DidYouMakeSuchLongNames,....) && .... || ... < ... Repeat the above a couple times and you are in a world of eye strain.

    So what do you do? Well in a normal language anything. You could add a newline anywhere you want and indent it any way you want to achieve good looking code. You might want to just keep all your lines the same width. Or the code might be a long condition with a bunch of logical operators between long parameter names so you just break at each operator. Or it might be a long query so you turn it into a nice indented block of code that resembles something readale. Again infinite options. And you can do any of them precisely because you know that what ever you pick won't break the code you are writing.

    The entire idea of making indentation and newlines sintaxically significant is an ugly cludge designed to force bad developers to write passably readable code. And like all ugly cludges all it ends up doing is trip everyone off, including those that it was supposedly designed to help. It's equivalent to a warning light on your dashboard that glows when ever you go past the allowed traffic velocity but does so with such brightness that it blinds you causing you to crash.

  • 516052 (unregistered)

    Over text limit:

    The proper solution to forcing developers to write petty code is to include automatic formatting tools into your IDE. And all modern IDEs do that. When ever I close a brace or add a ; in visual studio the IDE instantly makes the line or block pretty for me right than and there. And than I just have to go back and tweak it if I really, really have to like in the above long line example.

    That is how you make sure code is pretty. Not the python way.

  • Prime Mover (unregistered)

    I'm reminded of when I was asked to help debug some ugly javascript a colleague had just written. It was all over the place. No consistency in indentation or linefeeding at al, just randomly positioned and spaced lines. First thing I did (this was in Notepad++, my colleague (TRWTF) had not got a proper developer IDE even installed on her machine) was reformat it: putting spaces consistently, putting newlines consistently with respect to the braces, tabbing consistently etc. etc. and the first thing I said to her, because it was not immediately obvious, was "You're missing a curly." Her indignant reply: "Why did you have to do that to my code?" I left her to it because she made it clear that she was obviously far more clever than I was.

  • Prime Mover (unregistered)

    ... in that last rant, I should have written "because it was now immediately obvious".

  • Officer Johnny Holzkopf (unregistered)

    While any decent editor or IDE can deal with tabs, being shown as a variable whitespace amount selected by the user (4 or 8 is common, but 2 is also possible), the Python language, depending on the version (v2 or v3) will have a different opinion. Mixing tabs and spaces is a TabError in Python 3. The PEP suggests to always use 4 spaces (and therefore, editors and IDEs with automatic replacement can turn a tab keypress into 4 spaces easily, either right away during code entry or at a later code post-processing stage). But that is not a problem as big as it might seem. The fun starts when you start using non-ASCII spaces which are visually indistinguishable from spaces expected by the interpreter, but only a hex editor will reveal their true nature. (See also: Global replacement of semicolons with greek question marks throughout your whole C# codebase for more entertainment.)

  • WTFGuy (unregistered)

    As to semantic whitespace ...

    In general, if most languages used it, we'd all accept that feature as just the way it is. But since it's a rarity among languages, it amounts to an accident-prone misfeature among those languages that do use it. Back in Ye Olden Dayes, one could go a career working in a single language for a single employer. Needless to elaborate that that just ain't true these days. Consistency is a virtue, even if what's consistent isn't optimal.

    As to tabs vs spaces, etc. I'm given to suspect that Robin above works alone. The idea of enforcing a standard on tabs vs 2 spaces vs 4 spaces on a large codebase maintained by a bunch of people is ... implausible. Any shop will have enough Edgars who, even if not saboteurs, are remarkably resistant to guidance. Some of whom are unfireable for ... reasons.

    Yes, you could install a filter on your check-ins. But only if you're willing to buy for the next few years that every time a source file is first touched, there's a change needing code review on nearly every line.

  • (nodebb)

    On whitespace ... I have only a couple years experience with Python and the indentation sometimes drives me crazy when adding or removing a level, but its whitespace requirements hearken back to one of the first languages I learned... TUTOR https://en.wikipedia.org/wiki/TUTOR#Control_structures Nothing new under the sun.

    But at least the space/tab checking was made inconsistent with the rest of Python....it could have been a runtime check.

  • Robin (unregistered) in reply to WTFGuy

    Actually, you're wrong. I do work on a team, although not a huge one. Not using Python, admittedly - I'm one of about 5 or 6 front end developers on a product, working in Javascript. And I don't recognise the difficulties you allude to. We use ESLint, and amongst many other rules, it checks indentation. We have a build step that says, if your code doesn't pass lint, it doesn't get checked in. It seems to mostly work well as far as I can see - we certainly don't have the messes you seem to expect.

    I admit I'm relatively inexperienced in the industry - I've only been a professional developer for 3 years, this is my third job, and in both the others, even though there were a few other developers, everyone could just commit whatever they wanted, and code reviews were unheard of (unlike where I am now where they are very much part of the culture). And yes, that's one of several related reasons why I wanted to leave both of those jobs :) But anyway, none of the setup I described about my current job strikes me as unusual for a half decent company.

  • Worf (unregistered)

    The Apple "goto fail" bug was a result of bad merging, but it wouldn't have mattered if it was Python because the indentation automatically ensured "the right thing" happened, that is, it was tied to the preceding if conditional and not an unconditionally executed statement.

    Of course, the right thing to do in C is to always brace and never rely on single statements.

    Granted a compiler warning is generally emitted in these case, but in large code bases, 0 warnings or warnings as errors seem to be exception, not the rule.

  • dan (unregistered)

    The biggest reason I've always had a strong negative reaction to Python's syntactic indentation is how often I've seen the internet eat leading white space. I've spent most of my professional career using one C style language or another; and when looking for examples on the internet have found a large minority of old programming blogs/etc are owned by people who managed to break their CSS at some point (often it looked like they changed how they represented code, added CSS for the new layout and then applied it to everything including old content that didn't have its markup changed) and ended up with their leading whitespace deleted and all code slammed to the left margin.

    In any language that uses {}'s, begin/end's, etc to define code blocks that's at worst a minor nuisance. For smaller snippets following structure by counting them as you read isn't hard. For larger chunks, you can just copy/paste into your editor of choice and use the automatic format fixer tool. With syntactic indents though, you've lost the structure entirely and would have to try and reverse engineer it by figuring out how the code should work and semi-rewriting it.

  • MiserableOldGit (unregistered)

    We can't assume it's sabotage (or even mischief) and automatically apply apply criminal sanctions, or even adverse references based on this alone. VOG is equivalent to CRB in the UK, criminal records check, usually accompanied with a basic counter terrorism scan. Companies shouldn't be using them unless an employee has access to sensitive personal or financial data, or government/police security stuff. Misconduct like this (if that's what it is) is what references are for, even if they are generally a massive WTF.

    It could be misguided stupidity, some attempt to jiffle the test or fool the compiler to work around some perceived inconvenience, even if complete nonsense, you have to get beyond plausible deniability, as they hadn't really got control of him they can't know ... and while the implementation smells a bit of malicious activity, the actual impact doesn't look to be wreaking vengeance on a hated target. Unless he left some incriminating comments or emails lying around you can't go beyond "doesn't play nicely with others" and it would be wrong to do so. He may well have had some legitimate gripes to justify his generally bad attitude, who of us doesn't?

    The guy may have been a PITA, but that doesn't happen overnight, become immediately obvious one day when it wasn't before. Sounds a like a company that isn't very good at dealing with staff, I'm surprised there aren't more little Easter eggs hiding for them, and it reads rather like the author is too.

  • Harris Mirza (unregistered) in reply to 516052

    You are going to hate this, but you could just do:

    a = LongClassName b = a.EvenlongerMedhodName [sic]

  • Bob Geary (unregistered)

    DEFINITELY not gonna wade into any style wars OR offer bad legal advice, because...

    The REAL TRWTF is that somebody (never mind an Edgar) was able to check in a change to the CD pipeline without a peer review.

    The code that builds and deploys your code IS code, and code gets reviewed before it gets checked in. This would have been a way-less-interesting story if Edgar had just done something dumb instead of something malicious, but the impact would have been the same: hours wasted after the fact to find something that shouldn't have passed review.

  • Dave, from Oz (unregistered)

    Edgar, go directly to jail. Do not pass Go, do not collect $200.

  • radarbob (unregistered)

    holy typo, Batman! Your code review process is harsh.

  • (nodebb) in reply to Dave

    [second verse, same as the first]

    Holy typo, Batman! Your code review process is harsh

  • Greg (unregistered)

    The last pre-python language I've seen which had indention requirements were old 1960's era COBOL and FORTRAN... Even those ancient relics have evolved from 'area A' and 'area B' and 'to continue a statement place a non-blank character in column 7...'.

  • candipharm (unregistered)
    Comment held for moderation.
  • Morristix (unregistered)
    Comment held for moderation.
  • (nodebb)

    so dope

    Addendum 2023-11-30 17:09: Discover a range of EGR Delete solutions designed to optimize your vehicle's performance. At egr valve delete kit , our EGR Delete kits are crafted to remove exhaust gas recirculation restrictions, unlocking the true potential of your engine. Explore our collection today and choose the kit that suits your vehicle's needs. Click the link to get started!

Leave a comment on “It's a Gift”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article