Is there an easy way to control indents in Python

[Ian Kelly]

On Mon, Oct 20, 2014 at 11:54 AM, Ian Kelly <ian.g.kelly at gmail.com> wrote:
> On Mon, Oct 20, 2014 at 9:54 AM, Simon Kennedy <sffjunkie at gmail.com> wrote:
>> Not having ever attempted to go beyond even the basics of Perl, the aspect that causes me to refer to Perl 'dismissively' as well comment in this thread, is that I don't find Perl to be an aesthetically pleasing language and I consider Python functions which have no blank lines in them to be a small step towards Perl.
>>
>> Some people do not like Python's indentation rules but for me it's a large part of what draws me to program in Python. Spaces for indentation and blank lines are both aspects of how I like to program.
>>
>> I write in Python because I like to, not because I have to.
>>
>> I think the only reason I might code a function with no blank lines was if I was programming in a language that using blank lines caused it to run too slowly.
>
> So to be clear, I'm not talking about taking a function like this
> (contrived) example and just removing the blank line:
>
> def find_path(graphdata, start, end):
>     edges = map(str.split, lines)
>     graph = collections.defaultdict(list)
>     for node1, node2, weight in edges:
>         graph[node1].append((node[2], int(weight)))
>         graph[node2].append((node[1], int(weight)))
>
>     open_heap = [(0, (start,))]
>     closed_set = set()
>     while open_heap:
>         cost, path = heapq.heappop(open_heap)
>         current_node = path[-1]
>         if current_node == end:
>             return path
>         if current_node in closed_set:
>             continue
>         for next_node, weight in graph[current_node]:
>             heapq.heappush((cost + weight, path + (next_node,)))
>         closed_set.add(current_node)
>     else:
>         raise ValueError("No path from start to end")
>
> Rather, I'm saying that where the blank line is should be the start of
> a new function. There would still be a blank line, just no longer
> inside the function.
>
> Now, maybe you think there should be more blank lines in the above, in
> which case we'll just have to disagree on that point.

By the way, I didn't test that at all, which is why I've spotted at
least two bugs in it since sending the message.