Mohanragul

Posted on May 5

I Thought I Knew Python. I Was Wrong — Here's What Relearning It Actually Felt Like

#python #beginners #learning #webdev

I opened IBM Course 4 — Python for Data Science, AI and Development — fully expecting to breeze through it.

I'd used Python before. In college. In personal projects. It was supposed to be the comfortable one.

Then **kwargs showed up.

A quick timeline

My previous post went up on May 2. After that, I finished IBM Course 3 on Prompt Engineering.

May 3 — started Course 4. Finished a major chunk of it the same day.

May 4 — wrapped it up.

Two days. But they didn't feel easy.

This one was different from the start

The earlier IBM courses — Intro to AI, Generative AI, Prompt Engineering — were concept-heavy. I could follow along, absorb ideas, take notes.

This one required me to actually do things.

You can't half-pay-attention your way through a coding module. The moment you try to rush it, you get stuck. And I got stuck more than I expected.

That gap — between passively understanding something and actively using it — is something nobody really warns you about. I felt it clearly here.

The moment it stopped feeling familiar

I was fine with *args. Used it before. Pass in multiple positional arguments, collect them as a tuple — fine.

Then **kwargs came up.

Collect keyword arguments as a dictionary. I'd never actually used this. I'd probably seen it in someone else's code and skimmed past it. The syntax looked familiar enough that my brain filed it under "things I know."

It was not.

def introduce(**kwargs):
    for key, value in kwargs.items():
        print(f"{key}: {value}")

introduce(name="Arun", role="Developer", learning="Python")
# name: Arun
# role: Developer
# learning: Python

Not a complicated concept. But I had to stop, reread it, try it, and actually think about when you'd want this over a regular dictionary parameter.

That pause told me something. There were gaps I hadn't accounted for.

What I actually relearned

Beyond **kwargs, the course pushed me back through things I thought I'd covered:

Variables, data types, control structures — the bones of Python
Functions, including documenting them with docstrings and how they connect to help() (genuinely didn't know this)

Parameter handling — *args for positional, **kwargs for keyword arguments as a dictionary

Exception handling — and this is where it got messy

The errors vs exceptions thing — I still haven't fully resolved this

I went in thinking I understood the difference. I came out less sure.
Technically, errors in Python — like SyntaxError — are things the interpreter catches before your code even runs. Exceptions — ValueError, TypeError, FileNotFoundError — happen at runtime while the code is executing.

But in practice? The line gets blurry. Developers use the terms interchangeably all the time.

And it's not a beginner problem. Research on mobile app development found that around 80% of exception bugs cause serious issues like crashes or unstable behavior. A separate study analyzing 16 open-source Java and C# projects found exception handling anti-patterns in every single one of them.

One of the most common mistakes — especially for newer developers — is using exceptions as regular control flow, when they're meant to signal genuinely abnormal conditions. The bare exceptblock in Python is a classic version of this — catching everything indiscriminately and silently hiding bugs in the process.

I got confused during the course. I still am, a little. Leaving it here honestly rather than pretending I have a clean answer — I think that's more useful.

Day 2 — finishing the course

The second day covered:

Working with files and different file formats
pandasand NumPy— first real structured exposure to these
Basics of web scraping
Working with APIs in Python

These felt like what the whole course was building toward. The day-one fundamentals started making sense in context.

The actual realization

There's a difference between familiarity and understanding.

I was familiar with Python. Familiar enough to feel comfortable. But familiarity isn't the same as knowing why something works, or when to use one approach over another, or what happens when you get it wrong.

Relearning made that distinction very clear.

Going back to something you already "know" and finding gaps is uncomfortable. It's also — once you get past the initial deflation — one of the more useful things you can do.

What I'm walking away with

Familiarity is not fluency. Assuming you know something is a good way to stop learning it.
**kwargs is small. The lesson behind it is not.
Exception handling needs more time. I'll come back to it.

Next up: projects. That's the only way any of this becomes real. I'll share it when I do.

Have you ever gone back to something you thought you knew and found gaps you didn't expect? Did you push through or start over?

Drop it in the comments — genuinely curious. 👇

DEV Community