DEV Community: Anton Shcherbatov

Why Does `+=` Sometimes Create a New Object and Sometimes Not?

Anton Shcherbatov — Mon, 20 Jul 2026 18:41:04 +0000

This article assumes you're already comfortable writing simple Python programs and know the basics (if, for, functions, and lists). Here we're not learning how to use Python - we're learning why it behaves the way it does.

Try to guess what this code prints.

x = 10

print(id(x))

x += 5

print(id(x))

Many people expect += to simply change the value of the variable.

But if you look at the result of id(), you'll find that it's now a different object.

It seems as though += created a brand-new object.

Now consider a very similar example.

numbers = [1, 2]

print(id(numbers))

numbers += [3]

print(id(numbers))

This time, id() stays exactly the same.

Now the behavior is the complete opposite.

In one case, a new object appears.

In the other, the existing object is reused.

Why?

If you've followed the previous articles, the answer is already within reach.

We know two important things:

a name doesn't store an object - it simply refers to one;
Python has both mutable and immutable objects.

The second point turns out to be the key.

Let's start with a number.

x = 10

The name x refers to the object 10.

x ───► 10

Now we execute:

x += 5

At first glance, it looks like the number itself has changed.

But numbers are immutable objects.

We've already learned that immutable objects cannot be modified.

So Python does something else instead.

First, it computes:

10 + 5

Then it creates a new object whose value is 15.

Finally, the name x is rebound to that object.

Conceptually, the process looks like this:

x ───► 10

↓

create object 15

↓

x ───► 15

The original object is never modified.

That's why id() changes.

Now let's look at a list.

numbers = [1, 2]

Then we execute:

numbers += [3]

Many people expect this to behave just like the previous example.

But lists are mutable objects.

That means Python can modify the existing object instead of creating a new one.

Conceptually, it's very similar to writing:

numbers.append(3)

Or, when multiple elements are involved:

numbers.extend([3])

The list itself remains the same object.

Only its contents change.

That's why id() stays the same.

Let's compare the two cases side by side.

With numbers:

x = 10

before = id(x)

x += 5

after = id(x)

before and after will be different.

With lists:

numbers = [1, 2]

before = id(numbers)

numbers += [3]

after = id(numbers)

This time, before and after are identical.

This reveals an important principle.

The += operator doesn't, by itself, determine whether a new object will be created.

Instead, it asks the object to perform an in-place addition if possible.

What happens next depends entirely on the object itself.

If the object can be modified, Python modifies it.

If it can't, Python creates a new object instead.

That's why the exact same operator behaves differently in different situations.

There's one more interesting example.

Consider this code:

numbers = [1, 2]
other = numbers

numbers += [3]

print(other)

What do you think it prints?

If you've been following the previous articles, you already know the answer:

[1, 2, 3]

Why?

Because += modified the existing list.

Both names continued to refer to the same object.

Now compare that with numbers:

x = 10
y = x

x += 5

print(y)

The result is:

This time, a new object was created.

The name x now refers to the new object, while y continues referring to the original one.

We can now summarize the rule.

The += operator does not guarantee that an existing object will be modified.

Nor does it guarantee that a new object will be created.

It simply invokes the behavior defined by the object itself.

For mutable objects, that usually means modifying the object in place.

For immutable objects, it means creating a new object instead.

If this still feels a little magical, don't worry.

There's no magic involved.

Every Python object defines how it responds to different operations.

That's why the very same operator can produce completely different behavior depending on the object it's working with.

This naturally leads to another interesting question.

We already know that objects can be copied.

But what does a "copy" actually mean?

If you copy a list, are nested lists copied too?

And why does modifying a copy sometimes seem to change the original?

That's exactly what we'll explore in the next article.

Why You Shouldn't Use `def func(items=[])`

Anton Shcherbatov — Sun, 19 Jul 2026 09:31:29 +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.

Try to guess what this code prints:

def add(item, items=[]):
    items.append(item)
    return items

print(add(1))
print(add(2))
print(add(3))

If you've never encountered this behavior before, you might expect something like:

[1]
[2]
[3]

Each function call looks independent from the previous one.

However, Python produces a very different result:

[1]
[1, 2]
[1, 2, 3]

It looks as if the list somehow "remembers" previous function calls.

But why does this happen?

If you look at this example in isolation, it might seem like Python functions have some kind of hidden memory.

In reality, there is nothing magical going on.

To understand this behavior, we only need to recall two ideas from previous articles:

variables don't store objects, they refer to them;
lists are mutable objects.

Together, these two facts fully explain what's happening.

When Python encounters a function definition:

def add(item, items=[]):
    ...

the default list is created exactly once.

Not on every function call.

Not each time add() is executed.

But at the moment the function is defined.

We can think of it like this:

add
 │
 └────► items ───► []

The function parameter items is bound to a single list object.

Now the first call happens:

add(1)

Since no second argument is provided, Python uses the existing default list.

After append(), it looks like this:

items ───► [1]

The function finishes execution.

But the list does not disappear.

It continues to exist.

Now the second call happens:

add(2)

One might expect Python to create a new empty list.

But it doesn't.

The same object is reused.

Now the list becomes:

items ───► [1, 2]

The third call behaves the same way.

The same list keeps being modified:

items ───► [1, 2, 3]

This is why each call appears to "remember" previous results.

It's important to notice that the issue is not with functions themselves.

If we write the same logic without a function, nothing surprising happens:

items = []

items.append(1)
items.append(2)
items.append(3)

print(items)

The result is:

[1, 2, 3]

We already know why this happens.

A list is a mutable object.

Each append() modifies the same object instead of creating a new one.

The function behaves exactly the same way.

The only difference is that the list was created earlier than many people expect.

So how do we write this correctly?

Python has a widely accepted pattern for this case.

Instead of using a mutable default value, we use None:

def add(item, items=None):
    if items is None:
        items = []

    items.append(item)
    return items

Now each call without an explicit list creates a new one.

The behavior becomes predictable:

print(add(1))
print(add(2))
print(add(3))

[1]
[2]
[3]

You might wonder why Python behaves this way at all.

Why not create a new list automatically for each function call?

The reason is simple: default argument values are objects like everything else in Python.

They are created once at function definition time and then reused.

This makes the behavior consistent and efficient.

For immutable objects like numbers or strings, this behavior is usually invisible.

But once a mutable object like a list, dictionary, or set is used as a default value, the effect becomes observable.

From everything we've learned so far, nothing new is actually happening here.

There is an object.

There is a reference to that object.

The object is mutable.

So every function call modifies the same shared list.

This is why experienced Python developers almost never use mutable objects as default argument values.

At this point, we know enough to move one step further.

We've repeatedly said that lists can be modified in place.

But is that always true?

For example, what happens here?

numbers = [1, 2]

numbers += [3]

Is the existing list modified, or is a new list created?

And what if we replace the list with a number?

On the surface, the operation looks the same - but the behavior can be very different.

That's exactly what we'll explore in the next article.

Identity and Equality in Python

Anton Shcherbatov — Fri, 17 Jul 2026 10:06:33 +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 the difference is between is and ==, you'll often hear something like this:

"== compares values, while is compares references."

It's a common explanation.

And while it points in the right direction, it isn't quite accurate.

Let's see what's really happening.

We'll start with a simple example:

a = [1, 2, 3]
b = [1, 2, 3]

print(a == b)
print(a is b)

The output is:

True
False

At first glance, that seems odd.

If the lists are identical, why does one comparison return True while the other returns False?

To answer that, let's recall what we've learned in the previous articles.

In Python, variables don't contain objects.

Names refer to objects.

When we execute:

a = [1, 2, 3]

Python creates a list object.

Then we execute:

b = [1, 2, 3]

This creates another list object.

Even though both lists contain exactly the same values, they are two distinct objects.

Visually:

a ───► [1, 2, 3]

b ───► [1, 2, 3]

Now the behavior of the two operators becomes much easier to understand.

The == operator asks:

Do these objects have the same value?

In this case, they do.

So:

a == b

returns:

True

The is operator asks a completely different question:

Are these the very same object?

This time, the answer is no.

So:

a is b

returns:

False

In other words:

== compares an object's value
is compares an object's identity

Now consider a different example:

a = [1, 2, 3]
b = a

print(a == b)
print(a is b)

This time, both comparisons return:

True
True

Why?

Because no second list was ever created.

The assignment:

b = a

simply gives the existing object another name.

Now the picture looks like this:

a ─┐
   ├──► [1, 2, 3]
b ─┘

Since both names refer to the same object:

the values are equal
and the identity is the same

That's why both operators return True.

At this point, you might wonder:

If is only checks whether two names refer to the same object, why do we need it at all?

Why not always use ==?

Most of the time, == is exactly what you want.

Use it whenever you're comparing values - for example, numbers, strings, or lists.

But sometimes the identity of an object matters more than its value.

The best-known example is None.

You've probably seen code like this:

if value is None:
    ...

Notice that it uses is, not ==. Why?

Because there's only one None object in a Python program.

We're not asking whether another object happens to behave like None.

We're asking whether this is the None object.

That's why the Python community recommends writing:

if value is None:

instead of:

if value == None:

It clearly communicates your intent and is considered the idiomatic way to write the comparison.

You may occasionally run into something even more surprising:

a = 10
b = 10

print(a is b)

On many Python implementations, this prints:

True

But based on everything we've discussed so far, you might have expected False.

Don't worry - this doesn't mean numbers behave differently.

Python sometimes reuses certain small immutable objects as an internal optimization.

Small integers are one example.

The important thing is that your code should never rely on this behavior.

If you're comparing values, use ==.

If you're checking whether two names refer to the same object, use is.

We can now summarize the difference with one simple rule.

If you're asking:

"Do these objects have the same value?"

use ==.

If you're asking:

"Are these the same object?"

use is.

That's exactly why the previous articles in this series were so important.

Without understanding objects and names, the difference between is and == feels like an arbitrary rule you have to memorize.

Once you understand Python's object model, though, the distinction becomes completely natural.

Mutable and Immutable Objects in Python

Anton Shcherbatov — Tue, 14 Jul 2026 13:01:10 +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.

In the previous article, we discovered something interesting.

Lists can be modified:

numbers = [1, 2]

numbers.append(3)

print(numbers)

The output is:

[1, 2, 3]

Numbers, however, behave differently.

When we write:

x = 10
x = 20

the object 10 doesn't somehow become 20. Instead, the name x simply becomes bound to a different object.

At first glance, these seem like two completely different behaviors.

In reality, they come from one of Python's most fundamental ideas.

Python divides its objects into two broad categories:

mutable objects
immutable objects

Let's start with mutable objects.

A mutable object is one whose internal state can be changed after it's created.

Lists are the classic example.

Suppose we create a list:

numbers = [1, 2]

We can then add elements:

numbers.append(3)

remove them:

numbers.remove(2)

or replace existing values:

numbers[0] = 100

In every case, Python is working with the same object.

The object isn't replaced or recreated.

Only its contents change.

That's why multiple names referring to the same list all observe the same changes.

Now let's look at immutable objects.

Once an immutable object has been created, its state can never change.

Take a number:

x = 10

Now assign a different value:

x = 20

It may look as though the object changed.

But that's not what happened.

The object 10 remains exactly as it was.

The name x simply stops referring to it and becomes bound to another object instead.

The same idea applies to strings.

Suppose we write:

name = "Python"

Now we "add" some text:

name = name + " 3"

It looks like the string has been modified.

In reality, Python creates an entirely new string:

"Python 3"

and rebinds the name name to it.

The original string "Python" never changes.

At this point, it's worth emphasizing one important idea.

When we describe an object as mutable or immutable, we're talking about the object itself.

Not the variable.

Not the name.

Not the assignment statement.

The property belongs to the object that exists in memory.

This distinction may seem subtle now, but it'll help us avoid many common mistakes later on.

So which built-in objects are immutable?

Some of the most common examples are:

10
3.14
True
"hello"
(1, 2, 3)

These include:

integers;
floating-point numbers;
booleans;
strings;
tuples.

Once created, none of these objects can be modified.

Common mutable objects include:

[1, 2, 3]
{"name": "Anton"}
{"python", "java"}

These are:

lists;
dictionaries;
sets.

Their contents can be changed after they're created.

At this point, you might be wondering:

If mutable objects are so flexible, why isn't everything mutable?

The answer is that immutable objects offer several important advantages.

Since they can never change, Python can safely share and reuse them in many situations, compare them efficiently, and make certain internal optimizations.

They're also easier to reason about.

If an object is immutable, you never have to worry that some other part of your program has modified it behind your back.

That's why Python includes both mutable and immutable objects.

Each serves a different purpose.

We can now summarize Python's object model a little more precisely.

When you write:

x = something

Python doesn't store a value inside a variable.

It binds a name to an object.

What happens next depends on the object itself.

If the object is mutable, its state can be modified in place.

If it's immutable, any apparent "change" results in a different object, with the name simply being rebound to it.

Now we're finally ready for another interesting question.

Suppose we have two lists containing exactly the same values:

a = [1, 2, 3]
b = [1, 2, 3]

Are they actually the same object?

Or are they merely equal?

And why does Python sometimes use ==, while other times is is the right choice?

That's exactly what we'll explore in the next article. 🚀

Why Numbers Behave Differently from Lists

Anton Shcherbatov — Sun, 12 Jul 2026 19:49:18 +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.

The previous article, we saw something that can seem quite surprising at first:

a = [1, 2]
b = a

a.append(3)

print(b)  # [1, 2, 3]

It almost looks as if Python somehow "links" variables together.

But that's not what's happening.

The variables aren't connected to each other - they simply refer to the same object.

That naturally leads to another question.

If a list can be modified in place, why don't numbers behave the same way?

Consider this example:

x = 10
y = x

x = 20

print(y)

This time, the output is:

y still refers to 10, even though we reassigned x.

Why?

The answer lies in one subtle but fundamental idea.

Not all Python objects behave the same way when you try to "change" them.

Let's start with numbers.

When we write:

x = 10

Python creates the object 10, and the name x becomes bound to it:

x ───► 10

Now we execute:

x = 20

This is where it's important to separate rebinding a name from modifying an object.

The object 10 does not turn into 20.

In fact, the object 10 doesn't change at all.

Instead, Python creates (or reuses) the object 20, and the name x is simply rebound to it.

Now the picture looks like this:

x ───► 20

y ───► 10

The object 10 still exists because y continues to refer to it.

Now let's compare that to a list.

a = [1, 2]

This creates a single list object:

a ───► [1, 2]

Now comes the important part:

a.append(3)

Unlike assignment, append() does not create a new list.

Instead, it modifies the existing object in place.

After the call, we have:

a ───► [1, 2, 3]

If we originally had two names:

a = [1, 2]
b = a

the picture looked like this:

a ─┐
   ├──► [1, 2]
b ─┘

Calling:

a.append(3)

doesn't change the names.

It changes the object itself.

As a result, both names still refer to the same list-but that list now has different contents:

a ─┐
   ├──► [1, 2, 3]
b ─┘

This brings us to the key difference.

The number 10 cannot be modified.

A list can.

This isn't a special rule for numbers or lists, and it isn't a quirk of Python's syntax.

It's a fundamental property of Python objects.

Some objects can never change after they're created.

Whenever they appear to "change," Python actually creates a different object and rebinds the name.

Other objects allow their internal state to be modified without creating a new object.

That's why:

numbers behave as unchangeable objects;
lists behave as changeable objects.

Here's a useful way to think about it.

An unchangeable object is frozen once it's created.

If you need a different value, you need a different object.

A changeable object, on the other hand, remains the same object even though its contents can change.

Now the difference between numbers and lists becomes much easier to understand.

With numbers, changing the value always means referring to a different object.

With lists, you're usually modifying the existing object instead.

This leads to an important principle that we'll keep coming back to throughout this series:

In Python, a program's behavior is determined not by what's "stored in a variable," but by whether you're modifying an object or simply rebinding a name.

Now we can finally introduce the official terminology.

The kinds of objects we've been talking about are called:

mutable objects
immutable objects

By now, though, these shouldn't feel like abstract definitions.

They're simply names for the behaviors we've already observed.

In the next article, we'll take a closer look at mutable and immutable objects, see which built-in types belong to each category, and understand why this distinction is so fundamental to Python itself.

Why Does a List Change in Two Variables?

Anton Shcherbatov — Fri, 03 Jul 2026 12:45:05 +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.

In the previous article, we learned that variables in Python don't store data themselves. Instead, a name simply refers to an object.

With numbers, this feels quite intuitive:

x = 10
y = x

Both names refer to the same object whose value is 10.

So far, everything seems straightforward.

But as soon as we start working with lists, Python's behavior often surprises people.

Consider this example:

a = [1, 2]
b = a

a.append(3)

print(b)

Many beginners expect the output to be:

[1, 2]

After all, we modified a, not b.

Instead, Python prints:

[1, 2, 3]

It looks as if changing one variable somehow changed the other.

At first glance, it may seem like Python is keeping the two variables synchronized behind the scenes.

In reality, the explanation is much simpler.

Let's go back to the idea from the previous article.

When we write:

a = [1, 2]

Python creates a list object, and the name a becomes bound to it.

Visually:

a ───► [1, 2]

Next comes this line:

b = a

This is the crucial part.

Python does not create a second list.

No copy is made.

Instead, the name b is bound to exactly the same object.

Now the picture looks like this:

a ─┐
   ├──► [1, 2]
b ─┘

Notice that there's still only one list.

The only thing that changed is that there are now two names referring to it.

That's why the next line:

a.append(3)

doesn't create a new list.

It modifies the existing object.

After the call to append(), the picture becomes:

a ─┐
   ├──► [1, 2, 3]
b ─┘

Since both names refer to the same object, the change is visible through both of them.

In other words, Python didn't modify two different lists.

It modified one list that simply has two names.

This behavior is one of the most common sources of confusion for beginners.

For example, you might write a function that modifies a list passed as an argument, only to discover later that the original list outside the function has changed as well.

From Python's point of view, though, there's nothing mysterious happening.

If multiple names refer to the same object, they all see the object's current state.

At this point, you may be wondering something else.

If a list can be modified without creating a new object, why doesn't the same thing happen with numbers?

For example:

x = 10
y = x

x = 20

After this code runs, y still refers to 10.

Why can a list be modified in place, while a number cannot?

That's exactly the question we'll answer in the next article.

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.