Краткий ответ

Ключ окажется в конце порядка вставки, даже если до удаления находился в середине словаря. Повторная вставка создаёт для него новую позицию.

Исторический контекст

В современных версиях Python порядок элементов обычного словаря является гарантированной частью языка начиная с Python 3.7. В CPython это поведение стало фактически наблюдаемым раньше, но до Python 3.7 на него нельзя было переносимо полагаться во всех реализациях.

Гарантия порядка решала практическую проблему предсказуемого обхода словарей: сериализация, формирование отчётов и сопоставление данных перестали зависеть от случайного внутреннего размещения ключей.

Постановка проблемы

Если программа использует словарь как упорядоченную последовательность, удаление и повторное добавление ключа меняет его позицию. Неверное ожидание, что ключ «вернётся на прежнее место», может изменить порядок JSON-полей, шагов обработки или отображения данных.

Важно отличать изменение значения от удаления ключа. Присваивание нового значения существующему ключу сохраняет его исходную позицию, тогда как удаление с последующей вставкой перемещает ключ в конец.

Подробное решение

Словарь сохраняет порядок успешных вставок ключей. При удалении связь ключа с его текущей позицией устраняется; последующее добавление рассматривается как новая вставка.

items = {"a": 1, "b": 2, "c": 3}
del items["b"]
items["b"] = 20
print(list(items))

Результат — ['a', 'c', 'b']. Если вместо удаления выполнить items["b"] = 20, порядок останется ['a', 'b', 'c'].

Это правило относится к обычному dict и его обходу, включая keys(), values(), items() и преобразование в список. Оно не означает сортировку по ключам: порядок определяется историей вставок, а не значениями или алфавитом.

Удаление и повторная вставка имеют практическую цену: меняется порядок, а операции модификации словаря могут нарушать активный итератор или сделать его дальнейший обход непредсказуемым с точки зрения прикладной логики. Если нужен независимый явно управляемый порядок, его следует формировать отдельно, например сортировкой ключей или использованием списка ключей.

Ситуация из практики

Сервис формирует поля ответа из словаря настроек. Разработчик обновляет параметр через удаление старого ключа с последующей вставкой нового значения и замечает, что параметр переместился в конец ответа.

Вариант с удалением и вставкой прост, но меняет порядок и может вызвать лишние побочные эффекты при обходе. Вариант с обычным присваиванием сохраняет позицию и подходит, если требуется только изменить значение. Явная сортировка даёт стабильный бизнес-порядок, но требует дополнительного сравнения ключей и не всегда отражает порядок, заданный пользователем.

Оптимальное решение — использовать обычное присваивание для обновления существующего параметра, а сортировку применять только при наличии отдельного требования к порядку. В результате порядок ответа остаётся стабильным, а код точнее выражает намерение.

Что кандидаты часто упускают

Дополнительный вопрос: Что произойдёт с позицией ключа при изменении только его значения?

Ответ: Позиция не изменится. Присваивание существующему ключу обновляет значение, но не считается новой вставкой. Это позволяет обновлять данные без перестановки полей при обходе или сериализации.
Дополнительный вопрос: Можно ли считать порядок словаря сортировкой ключей?

Ответ: Нет. Словарь сохраняет порядок вставки, поэтому ключи могут идти в произвольном относительно сортировки порядке. Для алфавитного или числового порядка нужен отдельный вызов сортировки, который создаёт соответствующую последовательность обхода.
Дополнительный вопрос: Гарантирует ли порядок словаря, что безопасно изменять его набор ключей во время обхода?

Ответ: Нет. Сохранение порядка не отменяет ограничений на структурную модификацию во время итерации. Добавление или удаление ключей может привести к RuntimeError; безопасный подход — сначала собрать нужные ключи в отдельный список, затем изменить словарь после завершения обхода.