Indentation and the end statement

I hope we never share a project, that looks very annoying.

9 Likes

Julia does have string macros, so in theory, anybody can write a package that implements any syntax they want. For example, the Julia parser would accept the following without complaining:

using indentation
indented"""
for i in 1:10
   if i < 5
      print(i)
   else
      print(i*i)

function f(x,y)
   return(x+y) 
"""

For this to work, the “indentation” package should contain a macro named indented_str, which would parse the indented code (perhaps using a modified version of CSTParser.jl) and return the resulting expression.

This would be very easy to do, (but even if somebody did it, I doubt that the package would get much use.)

6 Likes

A+ trolling

5 Likes

I didn’t even notice the missing . till you pointed it out, and . aren’t even redundant with good indentation like end is (often). Our viscera react so differently.

I have deleted my offending post. I was definitely NOT intending to troll this discussion. I misinterpreted what kind of comments would be appropriate here. Sorry!

Disclaimer: I really doubt what I’m about to show is best practice, but I almost never need to do this anyway.

In PEP 572, Python’s walrus operator is introduced, and one of the justifications was to enable an assignment in an if/elif line with a conditional operation so one didn’t have to indent for each condition, like so:

match1 = pattern1.match(data)
if match1:
    result = match1.group(1)
else:
    match2 = pattern2.match(data)
    if match2:
        result = match2.group(2)
    else:
        result = None

# could be replaced with- elif (match2 := pattern2.match(data))

Incidentally, Julia’s assignments can also be used like a walrus operator, but both only work in one-liners. If I needed more lines to calculate match2, I either have to indent or refactor the lines as a separate function, which may be too small for me to think it’s worth separating. Since Julia doesn’t force indentation, I can just move all the result-calculating sections to the same indentation column.:

match1 = match(pattern1, data)
if match1
    result = group(match1, 1)
else
# a few more lines here
if ( match2 = match(pattern2, data) )
    result = group(match2, 2)
else
    result = nothing
end end

Obviously the multiple trailing ends are annoying, but it unambiguously expresses where the outermost if-else statement starts and ends, which is made necessary by how I tampered with indentation.

I wasn’t offended! On the contrary, I thought it was excellent and humorous trolling.

5 Likes

To me another approach could be a julia equivalent to parinfer for various lisps:

but with autoinserting nested ends instead of ) if the indentation was right.

I don’t think that code actually works? Julia doesn’t really have “truthy” values (usually a good thing, though a bit less concise in this case) so you can’t use a regex match in a conditional. However, nearly everything in Julia is an expression, so you can just use a block with semicolon in the conditional as follows:

julia> str = "baaac"
       if (m = match(r"(a+)", str); !isnothing(m))
           @info "Matched first clause" m[1]
       elseif (m = match(r"(c+)", str); !isnothing(m))
           @info "Matched second clause" m[1]
       end
┌ Info: Matched first clause
└   m[1] = "aaa"

This isn’t exactly pretty, but is a fairly concise way to express this kind of pattern.

4 Likes

Right, I should’ve specified it’s just a rough Julia-looking pseudocode mirroring the Python snippet from PEP 572.
That is actually a really good tip. I could write multiple lines that way, and I could also write it as a begin block, which would save me the trouble of closing the parentheses and adding semicolons. For immediate visual clarity, I could indent the condition code differently from the branch code. Don’t have to worry about counting trailing ends anymore.

1 Like

Yes exactly. Formatting those begin ... end blocks in a readable way might be challenging but there’s a very neat consistency in embracing “everything is an expression”.

I didn’t care about this until I had to debug a piece of python code that had a wrongly indented return statement. It took me over half a day to spot.

3 Likes

Ideally the editor should highlight such issues, making the process simpler.

That might not be possible, if the indentation change alters the meaning of the code, without causing an error.

2 Likes

It was something along these lines:

def f(n):
  s = 0
  for i in range(n):
    s += 1
    return s

After that I have started to add

  #endfor

everywhere :slight_smile:

We’ve had problems with python going throught Git and coming out the otherside with messed up indentations

Python itself will often simply not compile your script.

Sure, VSCode will also tell you which lines are badly indented.

but two people mixing tabs and spaces on the same line, everything working on one of their merges

and suddenly - boom - indent chaos

“you should have done something different before you got to that point”

yes, choose a langage with braces / end

1 Like

Or install a git commit hook that disallows any .py files that use tabs for indenting (or at the very least disallow files mixing spaces and tabs).

3 Likes

# apt install time-machine