Suggestion: add "end" as a keyword for marking end of blocks

Ideas
21

I would seriously recommend just getting used to how python actually works.

At best you are going to come up with a solution that confuses every other person that ever needs to look at your code.

Millions of people have learned the existing syntax. I’m sure you can do it too.

13 Likes
22

That is exactly equivalent to doing it with a string constant. Any value is a value.

Are you sure of that? Why wouldn’t it?

That’s not how it works. You didn’t put a literal there; you put a name. So it’s just like any other name, and has to be looked up.

(By the way, it’s unlikely Python will optimize away name lookups, since deliberately triggering a NameError is one of the easiest ways to test whether you’re on a Python version that provides some feature.)

If you really need trainer wheels while you get familiar with Python, use #end and move on. That way, everyone knows that it’s just trainer wheels, and won’t wonder if it has some greater purpose. But you would do well to get accustomed to Python’s style.

2 Likes
23

Well, because I tested it. Asking would’ve been a lot nicer, BTW. No need to be rude.

$ cat ejemplo4.py 
end = pass

def print_even(limit):
        for x in range(limit):
                if x % 2 == 0:
                        print(x)
                end
        end
end

print_even(20)

$ python ejemplo4.py 
  File "/home/baltasarq/Downloads/ejemplo4.py", line 1
    end = pass
          ^^^^
SyntaxError: invalid syntax

I don’t need “trainer wheels”: I’ve been using Python since around 2012. I clearly stated the objective in the first message of this thread: improving readability. Clearly this improvement in readability is not shared by most people in this forum, but there is no need for such demeanor behaviour.

2 Likes
24

Ah, I thought you meant using “pass” instead of “end”, which absolutely WOULD work. But since “pass” is not a value, it can’t be put into a variable.

I didn’t know that, and frankly, these sorts of ideas usually come from those who are looking for trainer wheels, not people who have a decade of experience with it. Forgive me for misinterpreting your experience level here.

1 Like
25

Just my 2 cents, I usually use comments to mark the end of a block while brainstorming. The code is being modified too much, and it helps avoid mixing indentation:

But, I wouldn’t use just “end.” To me, it seems too verbose in production code. I’m just noting that I also use many code preprocessing scripts to help in faster coding, but I wouldn’t want these in the final production code.

26

ideas comes to mind. Maybe it would allow experimenting with this.

27

I see that your comments carry more information than just the end of the block.

That’s another scenario in which it would be beneficial.

Interesting. This reminds of Basic and many of its derivatives. For instance, one can find wend to end a while block, or more recently (Visual Basic), End If, End While, etc.

Too verbose? I guess that would discard endif, and such if existed. Am I wrong? Or do you somehow mean the generated code?

28

Yes, the code that has passed the debugging (and testing) phase is cleaned automatically. I strive for it to be readable, less code is more readable.

So, in the end, I would say that simply a comment would suffice. I wouldn’t want to see traces of the struggles that the developer has endured to create the final code. Everyone has their own tools and behaviors.

Let’s make an analogy. We use whatever tools make writing easier for us, e.g., dictionaries, grammar checkers, phraseological books, etc. But none of these are part of the final article.

29

It would be great if there is a way to define a new keyword that is treated as a comment. For an “if() :” statement I use “#endif”, for a loop eg “for J in range(1,5) :” I use “#next J” .

The resulting code is very readable for programmers familiar with Fortran or Basic or other scientific programming languages. With a missing end of block marking it is difficult to know which line ends the block, expecially with blank lines. I’ll pass on using the word pass. It is not descriptive enough when terminating a block.

30

But you haven’t explained why you need a new keyword that is treated as a comment when you can already make a comment that is treated as a comment.

The only plausible reason I can think of is for an organization that prefers such a coding style to enforce such a keyword at the end of every block with a custom linter rule. With a regular comment it would be slightly uglier to implement such a check.

1 Like
31

I wouldn’t approve this in a PR but you could just do;

end = 'noop'

Then just put it where you want it. It wouldn’t do anything but would be there.

3 Likes
32

That was my first thought of a workaround too but I then pondered on what to do if someone needs the “keyword” to be followed by something that describes what kind of block it’s ending.

It now occurred to me that a possibly “better” workaround is to abuse type hints instead:

for i in range(5):
    ...
endfor: i

if 1 == 1:
    ...
endif: 1 == 1

Your workaround would produce bytecodes of LOAD_GLOBAL and POP_TOP (optimization opportunity?) whereas a type hint would not produce any bytecode.

3 Likes
33

Thanks for the end=‘noop’ suggestion. It can have lots of uses to make code more readable.

Pierre

34

No, they’re not optimized out. They still get loaded (and immediately pop’d) at runtime:

I’m surprised that Python doesn’t optimize this away. Can it / should it? Has this been discussed?

35

I believe that end should be aliased to braces in __future__ imports.

2 Likes