A few months ago, I published You're a Real JavaScript Developer Only If...
It was supposed to be a little post for fun.
You know, just a few thi...
For further actions, you may consider blocking this person and/or reporting abuse
Hahaha, thanks, Hadil, for the mention! I'm not a python developer, but it's still funny 🤣
I know you're into JavaScript 😄
I went through almost every trick of the list. I think I'm a real Python developer 😅
If you went through over 70% of these stages, so you're a real Python developer 😅
I am python developer i know,behind the scene of python code
Then you definitely know there's a whole world hiding behind those clean Python lines! 😄
The syntax makes it look so simple, but the real adventure is when you get into what's happening underneath.
yeah definitely,after knowing behind the scene,i laugh on statement like "python is easy" ,assume these are not real python developer
Now days who Writes code in hand .. this kind of things done by LLM only . But me thinking about interview hands on coding round .
That's an interesting point! 😄 LLMs can definitely speed up writing code, but understanding what's happening, catching bugs, and knowing when the generated code is wrong still matter a lot.
And hands-on coding interviews make that especially clear. You can have the best AI tools, but when you're asked to solve a problem and explain your thinking on the spot, your own understanding really counts.
If you don't understand the project not idea on that still you explain the project using LLM then also they explain only thing is that token will increase and significantly you price . still no need to write code in hand
I still write a lot of my code by hand so that I don't lose my coding skills. I lean on AI to clean up my code or help out with something that I'm stuck on. I also find it a timesaver to add some functionality to a code base that I've already created.
If you understand implicitly why a foolish consistency is the hobgoblin of little minds.
Bringing Emerson into a Python developer discussion! There's a line between keeping your code consistent and following a convention so blindly that you forget why it exists in the first place.
The hobgoblin admonishment in PEP 8 is a nice reminder that even the Python style guides themselves offer wisdom about when to use one's own best judgment! 🐍🙂
I am not a professional! 😅
It will just take a little time to work through the list, but you've got this! 😅
The part about 'turning a simple script into a tool' hits right at the core of Python's evolutionary trap.
You write a 15-line script to parse a malformed CSV on a Friday afternoon. By Monday, someone needs it to run on a schedule, so you add argparse. By Wednesday, someone feeds it an empty byte stream, so you wrap it in custom exception hierarchies. By Friday, you've added type annotations, pydantic models, logging with structured JSON output, and you find yourself writing a pyproject.toml and debating whether to switch from setuptools to flit or hatch. Python's gentle learning curve is essentially an onboarding funnel designed to turn script kiddies into systems architects without their prior consent.
And let’s not forget the canonical right of passage: mutable default arguments. Every Python developer remembers the exact day they wrote def process_batch(items, cache=[]) and spent three hours discovering that function definitions are executed once at import time, turning their innocent default list into a permanent, module-scoped shared memory leak across every subsequent invocation.
There are only 10 types of people in the world: those who understand binary, and those who spend their morning debugging why is evaluated to False on an integer larger than 256.
Mine is a sequel to the wrong-environment one.
We built a before/after comparison to prove a refactoring didn't change behavior. The top-level package came from the old checkout. But an editable-install finder in sys.meta_path quietly loaded some submodules from the new one. So for those modules we compared new code with new code. Hard to find differences that way.
Now I check where every loaded submodule comes from, not just the root package's file.
That's a sneaky one! 😂 You think you're comparing two different versions, only to discover that Python has quietly mixed them together behind your back.
Checking the root package is one thing, but tracing every loaded submodule takes the investigation to another level. Knowing where your code comes from matters just as much as knowing what it does!
Yeah ... i was surprised as well , love these experiments, always show new insights about what can go wrong :D ... and helps me to enrich / improve my skills and plugin
Haha 😂 The “onboarding funnel designed to turn script kiddies into systems architects without their prior consent” is SO accurate!
You start with a tiny script, and you're making architectural decisions by the end of the week. And mutable default arguments deserve their own horror story. The first time you encounter that bug, you really start questioning everything you thought you knew about Python 😂
The 'except Exception: pass' section needs a sequel where the script prints 'Done!' after quietly skipping every file. That's the moment the absence of a traceback becomes much scarier than the traceback itself. For a batch script, I'd rather see '0 processed, 12 failed' than a cheerful success message with nothing behind it. Your five-minute automation has now acquired an exit code policy, which feels like the next stage of turning it into a tool.
Interesting, because it really looks like Javascript issues 😄
The notebook crime scene deserves its own sequel: “Restart and Run All” as the final boss. A notebook that only works in the order 7, 14, 1, 39 has accidentally invented a puzzle game.