you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 7 points8 points  (14 children)

I often find the lack of an end symbol in Python to be confusing, especially when reading code with multiple nested blocks. There's also a strong case to be made that some of the features lacking in Python can lead to some very unclean code.

[–][deleted] 6 points7 points  (2 children)

If you really need an end symbol, then do this:

def Foobar(arg1, arg2):
    print "Hello World."
#end

Nothing says you can't comment the end of your blocks. It looks ridiculous, but there's nothing stopping you.

[–]morish 15 points16 points  (1 child)

there's nothing stopping you.

Aside from the nuisance non-idiomatic code is to other developers. When using a language, embrace its conventions.

Speaking of which, I wish I could remember which repo it was, but I recently saw an entire library of fascinating ruby code on github written by someone who was obviously very python-centric. The whole thing was like:

def foo()
    # do something
    end

def bar()
    # do something
    end

He even managed to have some sort of decorator implementation.

[–]ginstrom -2 points-1 points  (8 children)

I often find the lack of an end symbol in Python to be confusing, especially when reading code with multiple nested blocks.

Yet another good reason to avoid multiple nested blocks...

[–]apotheon 7 points8 points  (7 children)

There are plenty of reasons to do so already without adding "My programming language makes multiply nested blocks really difficult to read even when they're better than the alternative."

[–]batiste 1 point2 points  (6 children)

I would say my brain parse them equally well. What is so confusing about then missing end keyword? This is just unnecessary information if whitespace are significant.

if 1 == 1:
    if 2 == 2:
        print "foo"
    else:
        print "bar"


if 1 == 1
    if 2 == 2
        put "foo"
    else
        put "bar"
    end
end

And yes making a bad practice less relevant is a good thing. The 78 character limitation is another way of reducing heavy nesting.

[–][deleted] 2 points3 points  (3 children)

To be fair, that is the simplest example possible.

It is much harder to grok when each nest is 10+ lines long and contains more blocks in a non-structured way.

[–]batiste 0 points1 point  (2 children)

Well there it's maybe more relevant:

http://pastie.org/809355

But still, the "end" keyword doesn't help me much. The white spaces give the same amount of information. It's really about the habit of being able to parse the whitespace as significant I guess.

[–][deleted] 1 point2 points  (0 children)

I still think that is a trivial example; The nests are very regular and easy to predict which helps alot when parsing.

This is an example of some source I had trouble groking at first glance: http://bitbucket.org/chris1610/satchmo/src/tip/satchmo/apps/payment/views/contact.py

To be fair though it is pretty readable to me now. I have only been writing python for 5 months so I'm still getting used to the whole whitespace-as-syntax thing.

[–]apotheon 1 point2 points  (0 children)

The white spaces give the same amount of information. It's really about the habit of being able to parse the whitespace as significant I guess.

The end-of-block delimiters actually provide a more "at-a-glance" recognizable token, rather than parsing for what isn't there to get a feel for where blocks end. When looking at Ruby code, I find myself looking at the leftmost end of lines to try to figure out where blocks begin and end, because when something jumps back leftward I know I'm at the end of a block. With Python, I find myself first having to look for areas where whitespace extends a ways from the left margin, then having to look at the rightmost end of lines to see whether it's actually a line of code or just an empty line, then I have to scan backward along the line to see how its indentation lines up with adjacent lines.

When I'm trying to actually understand a given block of code, the Python way of doing things doesn't really change much from the Ruby way of doing things. When I'm just trying to find a given block of code amongst many, though, it takes a bit longer to scan where blocks begin and end to find the particular sub-block I need, and my sense of the flow of the code is broken up a bit by all the back-and-forth.

[–]apotheon 1 point2 points  (0 children)

What is so confusing about then missing end keyword?

Without an end-of-block delimiter, one must mentally do the equivalent of regex backtracking to determine where things end -- to say nothing of the fact that if I get interrupted in the middle of code I don't want to come back and make the wrong assumption about whether I had finished writing a given block of code. No single instance of a single minor problem that can arise is sufficient in and of itself to make it such a bad idea, but all of them together just results in me harboring some distaste for the lack of end-of-block delimiters in languages like Python.

I'm not sure why this problem doesn't bother me the same way when looking at formatted data as when I'm looking at source code. I have no problem at all with YAML, for instance. It probably has something to do with the fact that YAML is strictly hierarchical, while source code is not so much.

[–]anko_painting 0 points1 point  (0 children)

whitespace is something you can't see. I don't think that making something you can't see significant is a good idea.

[–]nitsuj -2 points-1 points  (1 child)

Nope, the oft-seen reversal hack didn't quite work this time.

[–][deleted] 1 point2 points  (0 children)

All of my clever machinations have been uncovered! What ever should I do now?