Deprecate semicolons

I think semicolons should be deprecated because they have little genuine use and often are a way to hide code (bad code) or create messy/misleading code (bad code)

Hiding code

Simply put a lot of whitespace then a semicolon and now you can run whatever you want

It’s hard to notice without visible whitespace or looking at the smallish size of the scrollbar handle

Lots of fishy GH repos use it

Messy code

if False: print(1); print(2)

Is misleading as to whether print(2) runs

for i in range(5): print(i); print(i**2); print("---")
def add(a, b): result = a + b; return result
x = 10; y = 20; z = x + y; print(z)

The same applies to any sort of mixed statements, conditionals and loops

a = 3; b = 4; c = 5

Is readable enough when it’s short, I think this is the only valid use of ;

Bonus: Makes one liners really uninteresting

I used to be really into making things in one liners, and semi colons made it really really boring. You can easily import things, define functions and variables, etc, instead of having to use crazy recursive lambdas, lists and the like.

Autoformatters format code and highlight trailing semicolons.

a = 3;
b = 4;
c = 5

oh wow those repos look nasty.

But I do value having ; available.

One use case is putting a print statement into a lambda for debugging.

2 Likes

Remember that Python is a scripting language. People write use-once scripts in a linux shell that might use python -c '...', where you often cram the most functionality in the least space. That semicolon may save a newline, and when writing a tcsh script, it’s the least of your troubles :slight_smile:
People, (like me), still do stuff on the linux bash shell, and when you need sets…

Another use I’ve heard of, (It’s never me guv’); inserting a print(...); breakpoint() on one line so it is easy to comment-out/insert/delete whilst debugging.

13 Likes

Malicious people will ALWAYS find a way to hide their payloads. Some are more obvious than others. The semicolon is barely relevant here.

Sloppy code is also always going to exist, again regardless of any specific problem. Is this good code?

try: obj.func()
except AttributeError: pass

Not really, no; but it doesn’t use a semicolon.

Oh, sorry. You don’t want semicolons. Lemme rephrase.

Not really, no.

Still, it doesn’t use a semicolon.

The semicolon has a perfectly reasonable use both in English and in Python. The fact that you don’t OFTEN see it does not mean that it is unimportant.

In addition, you won’t solve anything by deprecation. Malicious users aren’t going to be stopped by deprecation. Sloppy code won’t be bothered by anything until there’s at least a warning, and even then, there’ll need to be a way to silence the warning since legit code will need to still use this. So people will just slap that warning-silencer at the top of their code and move on.

How do I know this? Search the web for “pip environment is externally managed” and see how many posts explain how to override the check, usually after first suggesting a venv, but not always. We had a discussion of the problem here on Discourse a few months back. When you put artificial pain into something to try to force people to act differently, most people’s response will be “what’s the easiest way to stop the pain”. And that’s true even when there’s a legit reason to make the change, as with the pip example.

Deprecating the semicolon is a waste of time. It won’t achieve anything.

6 Likes

That really seems like it shouldn’t work? A lambda contains one expression only, while semi-colons are used to separate statements?

you’re right, it doesn’t actually work the way I remember it working. Oops. Shows you how often I use semicolons.

All in all, I don’t think semicolons is a good idea in any production code living in “*.py” file.

Don’t think it is valid in production code either. Rather:

a, b, c = 3, 4, 5


But they are useful for situations such as python -c, code golfs, scribblings and similar.

I mostly use them with python -c. E.g.:

echo '1' | python -c 'import sys; print(sys.stdin.read().replace("1", "2"))'

Very convenient.
Multiline input can often be awkward or even require additional utilities such as dedent.



All in all, I think removing these would be a net loss.

2 Likes

FWIW PEP-8 includes the following snippet marked as “correct” in the Pet Peeves section:

# Correct:
if x == 4: print(x, y); x, y = y, x

Granted that the snippet is really meant to address the issue of extraneous whitespaces rather than the use of semicolons, but the fact that this “correct” snippet exists at all in PEP-8 implies that it is an officially accepted coding style.

4 Likes

often are a way to hide code (bad code) or create messy/misleading code (bad code)

If you were arguing to deprecate exec and eval, then I couldn’t agree more.

But semi-colons are widespread in programming languages other than Python.

You can hide code without semicolon:

x = 1                                                                           or dangerous_code()

Not to detract from putting a python incantation on one line in a
script, but someone in another thread presented this formi, which I have
come to love:

 python -c 'if 1:
                indentable code
                goes here'

which avoids clumsy dedent()ing. Very nice!

Not every GH repo that uses it should be classified as fishy though:

Look pretty clear to me what the codes intend to do despite the semicolons as long as the lines are short.

4 Likes