I still see the same bug pop up in code reviews: a teammate calls a method like it’s a function, or passes a function where a bound method is required, and the error message looks deceptively small. That confusion isn’t about syntax—it’s about identity. In Python, a function is a standalone unit of behavior. A method is behavior attached to a specific object or class, and that attachment changes how calls work, how parameters are bound, and how you reason about state. When you’re building real systems—web APIs, data pipelines, internal tooling—you need a mental model that lets you predict what the runtime will do before you run it.

Here’s the promise: by the end, you’ll be able to look at any callable in Python and tell whether it’s a function or method, how it receives its first argument, how to move code between the two safely, and when to prefer one or the other. I’ll also show the real errors I see most often and the fixes I recommend, with runnable examples and a few modern 2026 patterns so you can apply this in production code right away.

The Mental Model I Use: Objects Carry Their Methods

I keep it simple when I explain this to new engineers: a function is just a tool on a workbench, while a method is a tool already bolted to a specific machine. You can pick up a function and use it anywhere, as long as you hand it the inputs it needs. A method already knows which machine it belongs to and gets handed that machine automatically when you call it.

That “automatic handoff” is the core difference. When you do:

report = Report()
report.render()

Python is really doing something closer to:

Report.render(report)

The method is attached to the instance, and the instance becomes the first argument. That first argument is conventionally named self. You can name it anything, but you shouldn’t. The behavior is the same whether you see it or not.

A function, on the other hand, doesn’t have that automatic attachment. You pass every argument explicitly:

def render_report(report):
return report.render_body()
render_report(report)

The difference sounds small, but it shapes your architecture. If behavior depends on instance state, a method is almost always the clearest choice. If behavior is stateless or should be shared across many types, a function keeps the dependency explicit. You’ll see that pattern over and over: methods for “acting as the object,” functions for “acting on the object.”

What Really Happens When You Call a Method

The first time I understood methods, it wasn’t from an OOP lecture. It was from inspecting a method object in the REPL. Try this and you’ll see what I mean:

class Ledger:
def add_entry(self, amount, note):
self.balance += amount
self.notes.append(note)
def init(self):
self.balance = 0
self.notes = []
ledger = Ledger()
print(ledger.add_entry)

You’ll see something like <bound method Ledger.add_entry of <main.Ledger object at 0x...>>. The phrase “bound method” matters. It means the function object has been wrapped with the instance so Python can pass self for you.

If you access the method on the class instead of the instance, you get a plain function:

print(Ledger.add_entry)

Now it’s not bound to anything. You must pass an instance manually:

Ledger.add_entry(ledger, 100, "Refund")

This behavior is implemented through Python’s descriptor protocol. Under the hood, functions defined in a class implement get. When you access them on an instance, get returns a bound method. When you access them on the class, it returns the raw function. You don’t need to implement descriptors yourself to benefit from this, but understanding this mechanism helps you reason about tricky situations, like assigning functions to instances or sharing methods between classes.

You’ll also run into two special method flavors:

1) @classmethod — Python binds the class itself as the first argument (cls). This is a method, but it’s attached to the class rather than the instance.

2) @staticmethod — Python does not bind anything automatically. It behaves like a function placed inside a class namespace.

Here’s a compact example showing all three behaviors in one place:

class CacheKey:
namespace = "orders"
def init(self, order_id: int):
self.orderid = orderid
def as_str(self) -> str:
# instance method: self is bound
return f"{self.namespace}:{self.order_id}"
@classmethod
def from_str(cls, raw: str) -> "CacheKey":
# class method: cls is bound
, orderid = raw.split(":")
return cls(int(order_id))
@staticmethod
def validate(raw: str) -> bool:
# static method: nothing is bound
return ":" in raw and raw.count(":") == 1

When you decide between these, I recommend a simple rule: if the behavior needs instance state, keep it as an instance method; if it needs class-level configuration, use a class method; if it needs neither, prefer a module-level function unless you’re grouping for discoverability.

Functions Are Explicit: That’s Their Superpower

Functions are the simplest callable building block in Python. Because they are independent, their inputs are always explicit, and that makes them easy to test, mock, and move across modules. In my codebases, functions are where I park logic that doesn’t care about object identity.

Consider a batch data-cleaning step:

from datetime import datetime
ISO_FORMAT = "%Y-%m-%dT%H:%M:%SZ"
def parse_timestamp(value: str) -> datetime:
# Fast, explicit, and easy to test
return datetime.strptime(value, ISO_FORMAT)
def normalize_email(value: str) -> str:
# Only data in, data out
return value.strip().lower()

You can pass these around as parameters without worrying about binding:

def apply_transform(values, transform):
return [transform(v) for v in values]
emails = ["  [email protected] ", "[email protected]"]
print(applytransform(emails, normalizeemail))

That pattern is one reason functions pair well with functional-style tools like map, list comprehensions, and concurrency libraries. If a function needs state, you can either pass it explicitly or build a closure:

from decimal import Decimal
def maketaxcalculator(rate: Decimal):
def add_tax(amount: Decimal) -> Decimal:
return amount * (Decimal("1.0") + rate)
return add_tax
addvat = maketax_calculator(Decimal("0.20"))
print(add_vat(Decimal("100.00")))  # 120.00

The closure is still a function. It just carries captured state from its creation context. That’s not the same as a method: the binding is created once at function creation time, not at call time on an object.

This distinction pays off in modern Python tooling. Static analyzers like Pyright or mypy often give sharper feedback with pure functions because the dependency chain is explicit. Formatters and linters such as Ruff tend to flag unbound method mistakes quickly, but it’s still on you to choose the right structure so the code reads cleanly. I prefer functions whenever I can keep behavior stateless and predictable.

Choosing Between Methods and Functions in Real Projects

Here’s the decision tree I actually use when I’m designing APIs or refactoring large modules:

1) Does the behavior need to read or write instance state? If yes, method.

2) Does the behavior belong to a class-level factory or configuration? If yes, class method.

3) Is it purely about inputs and outputs? If yes, function.

4) Do you want to group related helpers without leaking state? Often function in a module.

In practice, the trade-offs are more nuanced, so I like a compact comparison that reflects modern Python style. Here’s a clear split I’ve found helpful with teams:

Classic OOP style

Modern pragmatic style

—

—

Most logic inside classes as methods

Logic that needs state stays as methods; everything else is module-level functions

Use @staticmethod for helpers

Prefer module-level functions for helpers; use @staticmethod only for strict grouping

Larger classes with many helper methods

Smaller classes with fewer methods and more shared functionsIf you are building frameworks or SDKs, I often recommend a method-heavy surface for user ergonomics, but a function-heavy internal design for testing. That keeps the public API clean while your internal code stays easy to reason about.

For example, in a web service you might expose a class-based handler:

class InvoiceService:
def init(self, store, notifier):
self.store = store
self.notifier = notifier
def issue(self, invoice_data):
invoice = buildinvoice(invoicedata)
self.store.save(invoice)
self.notifier.send_invoice(invoice)
return invoice

Notice how build_invoice is a function, not a method. It doesn’t need self, so it stays outside. This separation lets me unit test invoice building without setting up a service instance.

Common Mistakes I See and How I Fix Them

I’ve seen the same errors hundreds of times, and the fixes are always the same. Here are the ones that cost the most time in code reviews:

1) Forgetting self in a method definition

class User:
def full_name(first, last):  # wrong: missing self
return f"{first} {last}"

This breaks when called as user.full_name() because Python still passes the instance. Fix it by adding self and adjusting the call:

class User:
def full_name(self):
return f"{self.first} {self.last}"

2) Calling a method like a function

user = User()
fullname = User.fullname()  # wrong: missing instance

Correct call:

fullname = user.fullname()

3) Defining helper functions inside a class when they don’t need state

That adds noise to the class API and encourages misuse. If a helper doesn’t touch self or cls, move it out. It becomes easier to test and easier to reuse.

4) Using @staticmethod as a default

I only use @staticmethod when I want the function to live in the class namespace for documentation or organizational reasons. If you use it everywhere, the class becomes a dumping ground. Prefer a module-level function instead.

5) Treating functions as methods by passing the wrong callable

This comes up in callbacks:

class Clock:
def tick(self):
print("tick")
clock = Clock()
Wrong: passing the unbound function
schedule_task(Clock.tick)

Unless schedule_task expects to pass the instance itself, you should pass the bound method:

schedule_task(clock.tick)

When I see this, I usually recommend adjusting the callback signature so it’s obvious whether it wants a function or a bound method.

Real-World Scenarios and Edge Cases

To make this concrete, here are a few situations where the method vs function choice changes your design in subtle ways.

Scenario 1: CLI utilities

CLI tools are often function-heavy because the behavior is largely stateless. I usually keep argument parsing in one module and business logic as functions so they are easy to test. If a CLI has long-lived state like a cache client, that’s where a class and methods become useful.

Scenario 2: Data pipelines

In a pipeline, I prefer functions for transformations. They compose cleanly and support parallel map/reduce workflows. But if a step depends on a model artifact, a database handle, or a large in-memory index, I wrap that in a class so the state is loaded once and methods can reuse it.

Scenario 3: Web handlers

Frameworks often encourage class-based handlers for routing or dependency injection. Even then, I keep I/O boundaries inside methods and push pure transformations into functions. This makes it easy to unit test without hitting a network or database.

Scenario 4: Plug‑in systems

If you’re loading user-defined code, a function is the safest surface. Your plug‑in API can accept a function signature and call it explicitly. Methods introduce state and implicit binding, which can be harder to sandbox or serialize.

Scenario 5: Serialization and pickling

Functions at module scope are easy to pickle. Bound methods are not, unless the instance is picklable. If you plan to pass work across processes, functions often behave better. This matters in multiprocessing or distributed task queues.

These scenarios show a pattern: methods shine when you need persistent state or a rich object model. Functions shine when you need portability and explicit inputs.

Performance Notes Without Hand‑Waving

Performance is not usually the deciding factor, but it does show up in hot paths. Method calls do a bit more work because Python has to bind self and resolve the attribute on the instance. Function calls skip that binding step. In real applications the difference is small, and I only care when the call happens millions of times per second.

Here’s a practical way I frame it for teams: a single method call might cost a few extra microseconds compared to a local function call, and over many calls that can add up to a typical range of 10–15ms in tight loops. That’s not a reason to replace all methods with functions, but it is a reason to keep hot inner loops simple. If you have a compute-heavy loop, I recommend either caching the bound method locally or using a pure function.

Example pattern that keeps things quick without compromising readability:

class Counter:
def init(self):
self.total = 0
def add(self, value: int):
self.total += value
counter = Counter()
add = counter.add  # local reference to the bound method
for value in range(1000000):
add(value)

This is a small detail, but in real-time systems it matters. I use this kind of micro-optimization sparingly and only after profiling. In 2026, I still trust cProfile and py-spy first, and I reach for JIT options like PyPy or native extensions only when the data backs it up.

A Clean, Complete Example That Shows the Difference

Here’s a runnable example that demonstrates how methods and functions behave differently, including @classmethod and @staticmethod:

from datetime import datetime
def format_currency(amount: float) -> str:
# A pure function: explicit input, explicit output
return f"${amount:,.2f}"
class Invoice:
tax_rate = 0.08
def init(self, customer: str, subtotal: float):
self.customer = customer
self.subtotal = subtotal
self.created_at = datetime.utcnow()
def total(self) -> float:
# Instance method: uses instance state
return self.subtotal * (1 + self.tax_rate)
def summary(self) -> str:
# Instance method calls a function
amount = format_currency(self.total())
return f"{self.customer} owes {amount}"
@classmethod
def withdefaulttax(cls, customer: str, subtotal: float) -> "Invoice":
# Class method: alternative constructor
return cls(customer, subtotal)
@staticmethod
def validate_subtotal(value: float) -> bool:
# Static method: utility inside class namespace
return value >= 0
invoice = Invoice.withdefaulttax("Acme", 120.0)
print(invoice.summary())
print(Invoice.validate_subtotal(50.0))

This example showcases three call styles:

• invoice.total() is an instance method; self is bound to invoice.
• Invoice.withdefaulttax(...) is a class method; cls is bound to Invoice.
• Invoice.validate_subtotal(...) is a static method; nothing is bound automatically.

How to Tell What You’re Looking At in Real Code

When you’re reading a large codebase, you don’t always know whether a callable is a function or a method until you see it in action. Here’s how I quickly classify them:

• Look at the definition: Is it nested inside a class? If yes, it’s a method (even if it’s @staticmethod).
• Check the first parameter: self or cls is a method clue. But remember that static methods won’t have them.
• Inspect the object: In the REPL, obj.attr that prints as is a method. The class attribute Class.attr will show a function (or a descriptor wrapper).
• Trace how it’s called: obj.method() is clearly a method call. function(obj) is clearly a function call. The confusion happens with callbacks, so I always check what is being passed.

In a production debugger, I often use callable, inspect.ismethod, and inspect.isfunction to make this explicit:

import inspect
print(inspect.isfunction(Invoice.total))   # True
print(inspect.ismethod(invoice.total))     # True

This is the kind of check that saves time when you’re wiring callbacks, async tasks, or plugin hooks.

Edge Cases That Surprise Even Experienced Engineers

The method/function distinction gets weird in edge cases. These are the ones I keep in my head because they are the biggest sources of confusion:

1) Assigning a function to an instance

If you assign a function to an instance attribute directly, Python does not turn it into a bound method. Binding only happens at attribute access on the class.

def greet(self):
return f"hello from {self.name}"
class User:
def init(self, name):
self.name = name
u = User("Mia")
u.greet = greet
This will fail, because greet is not bound
u.greet()  # TypeError
You must pass the instance explicitly
print(u.greet(u))

If you really want to attach a function as a bound method dynamically, you can use types.MethodType:

import types
u.greet = types.MethodType(greet, u)
print(u.greet())

2) Methods on dataclasses and attrs

Dataclasses and attrs classes are still classes. Methods work the same. The confusion comes when you auto-generate methods like init, repr, and eq. Those are still methods, and they still bind self.

3) Properties aren’t methods, but they behave like attribute access

Properties look like attributes, but they are methods under the hood. This can blur the mental model:

class Temperature:
def init(self, c):
self._c = c
@property
def f(self):
return (self._c * 9 / 5) + 32
print(Temperature(25).f)  # looks like attribute access

Even though it reads like a field, the property executes a function each time you access it. If the computation is expensive, the “feels like a field” illusion can hide performance issues.

4) Descriptors beyond functions

Anything implementing get can behave like a method. This is how staticmethod, classmethod, and property work. If you understand that, you can reason about custom descriptors too. It’s also why some frameworks can do “magic binding” for you—they hook into this same protocol.

5) Method resolution order and monkey patching

If you monkey-patch a class method at runtime (common in tests), the binding still occurs because it’s a function on the class. But if you patch the instance, no binding happens. This is a sharp edge when mocking. I always prefer patching at the class level unless I have a specific reason not to.

Practical Refactoring: Moving Code Between a Function and a Method

Refactors are where this difference really matters. Here’s a safe step-by-step approach I use when moving logic from a function into a method (or back out):

Refactor a function into a method

Start with a function:

def calculate_discount(customer, subtotal):
if customer.is_vip:
return subtotal * 0.9
return subtotal

Move it into a class only if it genuinely uses instance state:

class Checkout:
def init(self, customer):
self.customer = customer
def calculate_discount(self, subtotal):
if self.customer.is_vip:
return subtotal * 0.9
return subtotal

Then update the call sites:

checkout = Checkout(customer)
subtotal = checkout.calculate_discount(subtotal)

Refactor a method into a function

Start with the method:

class Checkout:
def calculate_discount(self, subtotal):
if self.customer.is_vip:
return subtotal * 0.9
return subtotal

Pull it out and make dependencies explicit:

def calculate_discount(customer, subtotal):
if customer.is_vip:
return subtotal * 0.9
return subtotal

Then update call sites:

subtotal = calculate_discount(customer, subtotal)

The key is to verify that you didn’t break implicit dependencies. If a method touches self in multiple places, you must add those inputs to the function signature or keep it as a method.

Methods in Inheritance and Mixins: Power and Danger

Methods really shine in inheritance, but that’s also where confusion spikes.

Overriding a method

If you override a method in a subclass, self is still the subclass instance.

class BaseFormatter:
def format(self, value):
return str(value)
class MoneyFormatter(BaseFormatter):
def format(self, value):
return f"${value:,.2f}"

Calling format on a MoneyFormatter instance uses the overridden method. This is why methods are the right place for polymorphic behavior.

Mixins and cooperative multiple inheritance

Mixins are class-only helpers that expect to be combined with other classes. They assume the method binding will work in the final class. In this world, methods are not just behavior—they are extension points. Functions don’t give you that.

If you use mixins, follow a strict naming and calling convention (super()), and keep the mixin methods small. Otherwise you’ll create hard-to-debug surprises.

Async and Await: Methods vs Functions in 2026 Code

Modern Python code is async-heavy. The method/function distinction stays, but async adds a few patterns worth highlighting.

Async functions are still functions

An async function is a function that returns a coroutine when called. It can be a function or a method, depending on where it lives.

async def fetchuser(userid):
...
class UserStore:
async def fetchuser(self, userid):
...

The binding rules are identical. The only difference is that you must await the call:

user = await store.fetch_user(123)

Passing async methods as callbacks

This is a frequent source of bugs. If a scheduler expects a function returning a coroutine, you can pass the bound async method.

schedulejob(store.fetchuser)  # ok if scheduler calls it with user_id

If you pass the unbound method, the scheduler must inject the instance. Most don’t. So the safe default remains: pass the bound method (store.fetchuser), not the unbound (UserStore.fetchuser).

Testing Strategy: Functions vs Methods

This is where functions shine.

Functions are easy to unit test

A pure function doesn’t need fixtures, mocks, or setup. You pass inputs, assert outputs. That’s it.

def testnormalizeemail():
assert normalize_email(" [email protected] ") == "[email protected]"

Methods often require test setup

You need to create instances and sometimes dependencies:

def testinvoicetotal():
invoice = Invoice("Acme", 100.0)
assert invoice.total() == 108.0

This is still easy, but for complex methods the setup cost grows quickly. That’s why I keep as much logic as possible in functions or small helper methods.

Mocking and patching

When you patch a function, you patch the module-level symbol. When you patch a method, you patch the class attribute. That distinction matters in tests:

• Patch module.function for functions.
• Patch Class.method for methods.

If you patch the instance method (instance.method) you may bypass binding in surprising ways.

Practical Decision Table: When to Use What

Here’s my personal cheat sheet. It’s not “academic,” it’s what I’ve found keeps teams moving fast without confusion:

Need

Prefer

Why —

—

— Uses instance state

Instance method

self binding keeps it natural Uses class config

Class method

cls binding supports polymorphism Stateless transform

Function

Explicit inputs, easy tests Grouping only

Function or @staticmethod

Grouping is a stylistic choice Performance critical loop

Function or cached bound method

Fewer lookups Plugin API

Function

Simpler surface and serialization Async callback

Bound method or function

Avoid unbound method mistakes

A Deeper, Real-World Example (Service + Functions)

Here’s a full, practical example that mixes methods and functions in a way I’d ship in production. It also shows where problems appear when you pick the wrong one.

from dataclasses import dataclass
from datetime import datetime
def format_currency(amount: float) -> str:
return f"${amount:,.2f}"
def calculate_tax(subtotal: float, rate: float) -> float:
return subtotal * rate
def buildlineitems(raw_items):
# Pure transformation from input payload to model
return [{"sku": i["sku"], "qty": int(i["qty"]), "price": float(i["price"])} for i in raw_items]
@dataclass
class InvoiceRecord:
customer: str
subtotal: float
tax: float
total: float
created_at: datetime
class InvoiceService:
def init(self, store, tax_rate: float):
self.store = store
self.taxrate = taxrate
def issue(self, payload):
items = buildlineitems(payload["items"])
subtotal = sum(i["qty"] * i["price"] for i in items)
tax = calculatetax(subtotal, self.taxrate)
total = subtotal + tax
record = InvoiceRecord(
customer=payload["customer"],
subtotal=subtotal,
tax=tax,
total=total,
created_at=datetime.utcnow(),
)
self.store.save(record)
return record
def render_summary(self, record: InvoiceRecord) -> str:
return (
f"Customer: {record.customer}\n"
f"Subtotal: {format_currency(record.subtotal)}\n"
f"Tax: {format_currency(record.tax)}\n"
f"Total: {format_currency(record.total)}"
)

Why this split works:

• buildlineitems, calculatetax, and formatcurrency are pure functions: easy to test and reuse.
• InvoiceService.issue is a method because it depends on instance state (store, tax_rate).
• The model (InvoiceRecord) is a dataclass, which doesn’t need method-heavy behavior.

If you tried to make calculate_tax a method, you’d either have to pass self (and then ignore it) or fake state. That’s usually a code smell.

“Method or Function?” in API Design

When you design a public API—especially for libraries—the choice changes how users think. Here’s the lens I use:

• Functions are direct and explicit. They feel lightweight and easy to integrate.
• Methods feel more fluent and object-oriented. They’re discoverable in IDEs and encourage stateful usage.

If your API expects long-lived state (connections, caches, configuration), methods are a natural fit. If your API is a set of utilities, functions keep things clean.

I often design in layers: a function-heavy core, wrapped by a method-heavy facade. That gives users the ergonomic API while giving me a testable foundation.

Common Pitfall Patterns and How to Avoid Them

Pitfall: instance method used as a callback without binding

class Handler:
def process(self, event):
print(event)
register_callback(Handler.process)  # wrong

Fix:

handler = Handler()
register_callback(handler.process)

Pitfall: helper method that never uses self

class Parser:
def normalize(self, text):
return text.strip().lower()

Fix: move it to a function so the dependency is explicit.

Pitfall: staticmethod used for design-by-habit

class Parser:
@staticmethod
def normalize(text):
return text.strip().lower()

If you only need grouping, that can be fine. But I still prefer a module-level function unless the class namespace is part of the public API.

Pitfall: method names that hide required state

Methods that depend on an instance but don’t obviously advertise it can be misleading. If you see a method that fetches network data or reads disk, consider naming it to reflect side effects (for example, load..., fetch...). That’s not about methods vs functions directly, but it reduces confusion about what gets bound and when.

Alternative Approaches: Multiple Ways to Solve the Same Problem

Sometimes you really can pick either. Here are alternative designs for the same behavior:

Option A: Pure functions

def send_invoice(store, notifier, payload):
invoice = build_invoice(payload)
store.save(invoice)
notifier.send_invoice(invoice)
return invoice

Option B: Class with methods

class InvoiceService:
def init(self, store, notifier):
self.store = store
self.notifier = notifier
def send(self, payload):
invoice = build_invoice(payload)
self.store.save(invoice)
self.notifier.send_invoice(invoice)
return invoice

Both are valid. I pick based on lifespan of dependencies and readability. If I’m passing the same store and notifier around repeatedly, a class cleans up call sites. If I need a simple one-off action, a function is clearer.

Modern Tooling and AI‑Assisted Workflows (2026 Lens)

In 2026, a lot of teams rely on static analysis, codegen, and AI-assisted refactoring. The method/function split influences these tools more than you might expect.

• Type checkers: Functions are straightforward and stable. Methods can hide dependencies behind self, which means your typing discipline matters more.
• Auto‑refactors: Tools can safely move and rename functions with fewer ripple effects than methods, because method names often form a class API.
• AI code assistants: They tend to generate class-heavy code by default. I often nudge them toward a function-first internal structure and then wrap methods around the core if needed.

A practical tip: if you’re using code generation or automated refactors, keep core logic as functions so the tools have a smaller surface area to reason about.

A Quick Checklist I Use Before Shipping

Before I ship a module, I run through a quick checklist:

• Does any method not use self? If yes, move it out or make it a @staticmethod only if grouping matters.
• Does any function secretly depend on external state? If yes, make that dependency explicit or move to a class.
• Are any callbacks passing unbound methods? If yes, fix them to pass bound methods.
• Are there methods that should be @classmethod for alternative constructors? If yes, add them.
• Are methods small and focused, or do they read like a “script”? If the latter, extract functions.

This takes five minutes, and it has saved me hours of debugging.

Final Takeaways: Your Mental Model in One Screen

• A function is standalone. Inputs are explicit. It’s portable and easy to test.
• A method is attached to an object or class. Its first argument is implicitly bound.
• Instance methods act on instance state; class methods act on class state; static methods are just functions in a class namespace.
• If you’re unsure, start with a function. Promote to a method only when state or polymorphism demands it.
• Most bugs come from passing the wrong callable or forgetting that Python binds self automatically.

If you keep these rules in your head, the errors I see most often in code reviews basically disappear. The best part is that your code will read more clearly to everyone else on your team, too.

Bonus: A Compact Debugging Exercise

When you’re not sure what a callable is, try this:

import inspect
print(inspect.isfunction(obj))
print(inspect.ismethod(obj))
print(getattr(obj, "self", None))

If self is set, you’re looking at a bound method. If it’s None, it’s probably a function or an unbound method. It’s a tiny exercise, but it builds the instinct you need to avoid mistakes in real projects.

If you want, I can also add a short FAQ section or a hands‑on mini‑quiz for readers who want to test themselves.