I hope we never share a project, that looks very annoying.
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.)
A+ trolling
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 end
s 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.
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.
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.
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.
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.
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
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
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).
# apt install time-machine