What’s One Python Practice You See That Should Be Illegal?

[jztchl]

So I’ve been learning Python for a while now, and I’ve started to notice something…
Some Python code out there is STRAIGHT-UP ILLEGAL (or at least it should be).

I’ve seen things like:

• from something import * (I still don’t know where anything’s coming from 😭)
• Mixing tabs and spaces (my editor exploded)
• People using eval() for literally no reason
• Or stuffing 300 lines into one single function 😵

I get that everyone writes code differently, but some patterns just feel cursed.

💬 So I wanna ask:
What’s one Python practice you’ve seen that should be straight-up banned?

Doesn’t matter if you’re a beginner or a pro if you’ve ever looked at some Python and thought “Nah, that ain’t right,” drop it below:

• Share code horror stories
• Tell me what not to do
• And if you’ve got better ways to write it, I’m all ears

I’m learning, and I wanna learn the right way minus the code crimes 😂
Let’s air out the dirty Python laundry 🧼🐍

[jztchl]

I’ll go first.

So picture this: I was in full “10x dev” cosplay hoodie up, lo-fi beats on, terminal dark as my sense of test coverage. I wrote two API functions that were so identical they could've filed taxes jointly.

Did I refactor?
Absolutely not.
I went full send Ctrl+C/Ctrl+V, like a rogue script kiddie with no concept of shame or DRY principles.

Then my senior rolled up on the code review like Gordon Ramsay inspecting a microwave steak.

“You do know functions exist, right?”

Bro said it so calm, but I felt it in my ancestral Git commits.

Anyway, I pulled myself outta tutorial brain mode, refactored the logic into a nice helper function, sprinkled in some type hints, maybe even threw in a docstring for ✨vibes✨. Felt like I just unlocked the Pythonic Sharingan.

…until I ran it.
And realized.
I forgot. To pass.
The QuerySet.

Instead of reusing the one I already had, I summoned a fresh ORM query inside the helper. Like I was trying to DDOS my own database just for funsies.

Round 2 of code review:

“So you refactored it… and somehow made it worse?”

At that point, even Git was like “nah bro this one’s on you.”
I tried to amend the commit, but turns out you can't --amend poor life choices.

Moral of the story:

• DRY doesn’t mean Duplicate Repeatedly, You clown.
• Refactor like you’re being watched by your future self.
• And never forget every ORM call you spawn unnecessarily, a DBA cries in SQL.

Your turn.
Tell me the dumbest dev moment you survived. Let's laugh the pain away like true backend survivors.

[rootsom]

Lmao 💀 been there! Nothing scars you like opening a repo and finding a 500-line function named process_data_final_final2().

One thing I will ban from my projects — from module import *. Absolute chaos. It's like inviting strangers into your namespace with no name tags. Suddenly you're using a function and have no idea where it came from. Debugging turns into detective work 🕵️‍♂️.

Also, mixing tabs and spaces? That’s not just a bad habit — that’s Python heresy. Your code might look fine, but then throws errors like it’s haunted 👻. Set your editor to show invisible characters. Trust me, future-you will thank you.

Worst offender I saw: someone used eval() inside a loop to dynamically run stringified user input. Like, bro… are we building a calculator or writing malware?
Golden rule: Write code you can read three months from now without crying.
What’s the worst you’ve seen? Let’s build the official “Python crimes to avoid” list 😂🐍

[JBurrell999]

One time I wrote a Python script for a project and, genuinely not sure what I was thinking, I put the entire thing into one giant function. I’m talking hundreds of lines. No structure, no helper functions, just this endless scroll of logic with variables popping in and out like it was normal.

Debugging it was a nightmare. I’d fix something at the top, and five minutes later I’d realize I broke something 200 lines down. At some point I added from module import * because I was “trying to keep it clean,” which somehow made everything less clear.

The worst part is, I remember proudly submitting it thinking it was clean because “it worked.”

I’ve started breaking things into smaller functions now and being way more intentional with what I import. Still learning, but that experience taught me fast that just because Python lets you write messy code… doesn’t mean you should.

[mr-adonis-jimenez]

Hard coding secrets directly into Python source code can cause numerous security vulnerabilities that can corrupt your IDE.

[UtsavKash19]

So I’ve been learning Python for a while now, and I’ve started to notice something… Some Python code out there is STRAIGHT-UP ILLEGAL (or at least it should be).

I’ve seen things like:

• from something import * (I still don’t know where anything’s coming from 😭)
• Mixing tabs and spaces (my editor exploded)
• People using eval() for literally no reason
• Or stuffing 300 lines into one single function 😵

I get that everyone writes code differently, but some patterns just feel cursed.

💬 So I wanna ask: What’s one Python practice you’ve seen that should be straight-up banned?

Doesn’t matter if you’re a beginner or a pro if you’ve ever looked at some Python and thought “Nah, that ain’t right,” drop it below:

• Share code horror stories
• Tell me what not to do
• And if you’ve got better ways to write it, I’m all ears

I’m learning, and I wanna learn the right way minus the code crimes 😂 Let’s air out the dirty Python laundry 🧼🐍

Love this question 😂 — every Python developer eventually discovers some truly cursed code patterns.

Here’s one practice I’d nominate as “should be illegal”:

---

USING eval() ON USER INPUT 😱

Example of the crime:

user_code = input("Enter something: ")
result = eval(user_code)
print(result)

Why this is terrible:

• Massive security risk → users can run any Python code on your system.
• Can delete files, access secrets, or crash the program.
• Almost always unnecessary.

Safer alternatives:

• Use int(), float(), json.loads(), or ast.literal_eval() depending on the need.
• Validate input instead of executing it.

---

HONORABLE MENTIONS (ALSO ILLEGAL)

1) from module import *

• No idea where variables/functions come from.
• Breaks readability and debugging.

Better:

from module import useful_function

---

2) One 500-line function

• Impossible to test or understand.
• Violates separation of concerns.

Better:
Split into small functions with clear responsibilities.

---

3) Catching every exception blindly

try:
    do_something()
except:
    pass

• Silences real bugs.
• Makes debugging a nightmare.

Better:

except ValueError as e:
    print(e)

---

4) Mixing tabs and spaces

• The classic chaos generator.
• Causes mysterious indentation errors.

Better:
Use 4 spaces only (PEP 8 standard).

---

SHORT RULE OF THUMB 🐍

If code is:

• Hard to read
• Hard to debug
• Or dangerous to run

…it’s probably a Python crime.

Clean, simple, readable code will always win.

---

Curious to hear others’ horror stories too — Python has no shortage of creative chaos 😄

[3riy]

🚫 The 'Illegal' Practice: Bare 'except' in try-except statement

This is when someone wraps a massive block of code in a try/except block but doesn't specify which error they are looking for.

# DO NOT DO THIS
try:
    user_input = get_data_from_api()
    process_calculation(user_input)
    save_to_database(user_input)
except:
    print("Something went wrong!") # But what? And where? 

Why it should be "illegal":

• It hides real bugs: If you have a typo (like calling prnt() instead of print()), Python would normally throw a NameError. With a bare except, that error is caught and silenced. You’ll be staring at your screen wondering why the data didn't save, while the code just whispers, "Something went wrong."

• It stops you from quitting: A bare except: catches everything, including KeyboardInterrupt (Ctrl+C). If you try to kill a running script in your terminal, a bare except might catch that signal and refuse to let the program die.

• It violates the Zen of Python: "Errors should never pass silently. Unless explicitly silenced."

✅ The "Legal" Way: Specificity

You should always catch the specific exception you expect. If you are worried about a connection issue, catch the ConnectionError. If it’s a math issue, catch ZeroDivisionError.

try:
    value = 10 / 0
except ZeroDivisionError as e:
    logging.error(f"Math fail: {e}")
except Exception as e:
    # This is the "Safety Net" - it catches most errors but 
    # still lets SystemExit and KeyboardInterrupt through.
    logging.error(f"Unexpected error: {e}")

[Dieg0arc]

One practice I find particularly harmful is using mutable default arguments:

pythondef add_item(item, lst=[]):
    lst.append(item)
    return lst

This is a hidden trap — the list is created once and shared across all calls. For example:

pythonadd_item(1)  # [1]
add_item(2)  # [1, 2]  ← unexpected!

The correct way:

pythondef add_item(item, lst=None):
    if lst is None:
        lst = []
    lst.append(item)
    return lst

Another practice that should be illegal: using except: pass to silently ignore all errors — it hides bugs and makes debugging a nightmare.

[nishantxraghav]

Using mutable default arguments:

def add_item(item, lst=[]):
    lst.append(item)
    return lst