DEV Community: Anton Shcherbatov

What Really Happens When You Write x = 10

Anton Shcherbatov — Tue, 30 Jun 2026 19:20:16 +0000

We assume you already know how to write simple Python programs and understand basic syntax (if, for, functions, lists). Here, we're not discussing how to use the language, but why it works the way it does.

If you ask a beginner what this line of code does:

x = 10

the answer is usually something like:

"The number 10 is stored in the variable x."

At first glance, that sounds perfectly reasonable. We're used to thinking of a variable as a box or a memory cell that can hold a value. First the box is empty, then we put a number, a string, or a list into it.

The problem is that Python doesn't actually work that way.

To understand many of Python's behaviors, it's helpful to stop thinking of variables as containers for data. Instead, think of a variable as a name that refers to an object.

When Python executes:

x = 10

it doesn't start with the variable - it starts with the object 10.

The number 10 is an object. Once that object exists, the name x is bound to it.

Visually, you can think of it like this:

x ───► 10

The arrow indicates that the name x refers to the object whose value is 10.

At first, this distinction may seem unimportant. What difference does it make whether the number is stored inside the variable or the variable simply points to it?

As it turns out, the difference is enormous, and it explains many of Python's most important behaviors.

Now suppose we add another line:

y = x

Many people expect Python to create a second copy of the number and store it in another variable.

That's not what happens.

Instead, the name y is simply bound to the very same object that x already refers to.

Now the picture looks like this:

x ─┐
   ├──► 10
y ─┘

There's still only one object, but now there are two names that refer to it.

That's why Python makes a clear distinction between objects and names.

Objects hold data.

Names allow you to access those objects.

Things become even more interesting when a variable appears to "change."

Consider this code:

x = 10
x = 20

If you think of variables as boxes, it's natural to imagine that the number 10 inside the box has somehow been replaced with 20.

But that's not what Python does.

Initially, the name x refers to the object 10:

x ───► 10

After the second assignment, the name refers to a different object:

x ───► 20

The object 10 hasn't changed, disappeared, or turned into 20.

The name x has simply been rebound to another object.

This may seem like a subtle detail, but it's one of the fundamental ideas behind Python's execution model.

Later, we'll see that it explains many things that often confuse beginners:

why modifying a list can unexpectedly affect another variable;
why is and == are not the same;
why strings behave differently from lists;
and how Python passes arguments to functions.

For now, remember just one idea.

When you write:

x = 10

Python doesn't put the number into a variable.

It binds the name x to the object 10.

That's why experienced Python developers usually don't say that a variable stores a value. Instead, they say that a name refers to an object.

It may sound a little less intuitive at first, but it's much closer to how Python actually works.

More abbreviations to the abbreviation's God

Anton Shcherbatov — Sun, 11 Jun 2023 19:54:17 +0000

At the work I meet a lot of different abbreviations. Some of them are insignificant, some of them are pretty useful, but most of them you're already know. Nevertheless, they describe the developing process in a way it should be and can help to build a real robust applications. There is a list of the most common of them. Which ones would you like to add?

SOLID Principles

S (Single Responsibility) Every class is responsible for the on operation only.
O (Open Closed) The classes have to be open for extending and closed for modification
L (Liskov substitution) It should be possible to use a child class (type) instead of a parent without negative consequences
I (Interface Segregation) You shouldn't force a class to implement an interface, which doesn't relate to the class
D (Dependency Inversion) Abstractions don't depend on the details, but details do depend on the abstractions

YAGNI (You're not gonna need it) If you're writing the code, ensure you're gonna use it. Don't add the code if you think it'll be useful later
DRY (Don't repeat yourself) Pretty obvious. Don't hurry to write the code - look around. Likely, someone already wrote it. This is why I love pull requests for - somebody can remember that your functional already exists and we don't actually need. Seriously?! Where have you been during the sprint planning?!
KISS (Keep it simple, stupid) Well, just be simpler. The simpler code, the better it works. If a task doesn't require over-complicated solution, just use the solution. It supposes that you have multiple solution of the task. Haha :\
BDUF (Big design up front) This is what I'm lack in. No time to think, just write the ~~f..~~ code. It's incorrect. Before starting coding, ensure that everything is well thought out
APO (Avoid Premature Optimization) Don't force the code optimization until it's really necessary.

There are much more abbreviations in a programming world. Which one is your favourite? My favourite is LGTM in the comments of pull requests!

Bottle+Sqlite

Anton Shcherbatov — Thu, 01 Jun 2023 19:10:50 +0000

A few more words about Bottle. After enabling a sqlite extension, you can easily include a specified keyword as a view argument. Like:

app = bottle.Bottle()
db_plugin = bottle_sqlite.Plugin(dbfile='./test.db', keyword="db")
app.install(db_plugin)

@app.route("/")
def main(db):
    ....

It works perfect... Until you decide to show the view for authorized users only. And this

@bottle.auth_basic()
def save_post(db):
    ...

will cause

TypeError("main() missing 1 required positional argument: 'db'")

This is a known issue, which still wasn't solved on the plugin level. So, again workarounds

The only change here is:

params = inspect.signature(_callback).parameters
if keyword not in params:
    return callback

instead of

argspec = inspect.getargspec(_callback)

Bottle

Anton Shcherbatov — Tue, 30 May 2023 09:02:48 +0000

Bottle is a really small python-based framework. The whole its code takes 1 file with ~4000 rows. Meanwhile, Bottle is pretty self-sufficient - it supports:

wsgi-server
routing
authorization
plugins
own templates language
a lot of extensions (mostly one-paged too)
custom error pages
and much more!

I was excited trying to write my blog using Bottle. The first issue I faced - you can login, but you can't logout :D

Bottle supports basic auth mechanism, so you can do something like:

def auth_callback(user, password):
    return user == password  # or any check you want

@bottle.auth_basic(auth_callback)
def edit_post(db, post_id):
    ....

But there is no way to logout. The only workaround I found is to return 401 status as a response. It allows to force logout the user. It's not quite correct, because user doesn't expect to get 401Error on logout, but this is why it's called workaround.

To make the solution to look more pretty I also customized 401 Error page, by adding an html-template with link to login.

def logout():
    return bottle.abort(401)

@app.error(401)
def error_401(error):
    return bottle.template("errors/401")

app.route("/logout/", ["GET"], logout)

As alternative, there is an extension for bottle, called bottle-login, which has been archived few years ago.

klen / bottle-login

Implement users' sessions in Bottle framework

Bottle Login

Bottle Login -- Implement users' sessions in Bottle web framework.

Contents

Requirements

python >= 2.6

Installation

Bottle Login should be installed using pip:

pip install bottle-login

Usage

from bottle import Bottle, request, redirect
from bottle_login import LoginPlugin

app = Bottle()
app.config['SECRET_KEY'] = 'secret'

login = app.install(LoginPlugin())

@login.load_user
def load_user_by_id(user_id):
    # Load user by id here


# Some application views

@app.route('/')
def index():
    current_user = login.get_user()
    return current_user.name

@app.route('/signout')
def signout():
    # Implement logout
    login.logout_user()
    return redirect('/')

@app.route('/signin')
def signin():
    # Implement login (you can check passwords here or etc)
    user_id = int(request.GET.get('user_id'))
    login.login_user(user_id)
    return redirect('/')

Bug tracker

If you have any suggestions, bug reports or annoyances please report them to the issue tracker at https://github.com/klen/bottle-login/issues

Contributing

Development of Bottle Login happens at: https://github.com/klen/bottle-login

Contributors

klen (Kirill Klenov)

License

Licensed under a BSD license.

View on GitHub

First post

Anton Shcherbatov — Mon, 29 May 2023 21:01:16 +0000

Well, this is probably the first time when I use this title not for testing purposes. Although, this is still gonna be a part of experiment, where I'm trying different kind of frameworks, technologies, skills and share all the useful (for me) and interesting (again, for me) information.