Poslední beta Pythonu 3.15 je venku, výchozím kódováním bude UTF-8

Release manager Hugo van Kemenade vydal 18. července čtvrtou betu Pythonu 3.15. Je poslední plánovaná: nové funkce do jazyka nesměly přibývat už od 7. května, kdy vyšla beta první, a od téhle chvíle se nemá měnit ani binární rozhraní, na které se váží knihovny psané v jazyce C. První kandidát na vydání má vyjít 4. srpna, druhý 1. září a ostrá verze 1. října 2026.

Podle plánu vydání dostane 3.15 opravné aktualizace zhruba jednou za dva měsíce po dobu dvou let, bezpečnostní pak až do roku 2031. Novinek je uvnitř dlouhý seznam, tři z nich ale stojí za pozornost, i když s Pythonem jen občas něco spustíte.

Výchozí kódování určuje Python, ne systém

Dosud platilo, že když program otevře soubor bez uvedení kódování, použije se to, které hlásí systém. Na Linuxu z toho vycházelo UTF-8 skoro vždycky, na Windows se řídilo národním nastavením, a tentýž skript tak na dvou počítačích četl tentýž soubor jinak. Od 3.15 to neplatí: dokumentace uvádí, že Python nově používá UTF-8 jako výchozí kódování nezávisle na prostředí systému, takže volání open('flying-circus.txt') bez dalšího údaje čte v UTF-8. Týká se to i standardního vstupu a výstupu a rour mezi programy.

Změnu popisuje PEP 686 od Inady Naokiho, který je od 3.15 ve stavu Final. Jeho argument je prostý: UTF-8 se stalo faktickým standardem u formátů jako JSON, TOML nebo YAML i u editorů a webů, a rozdílné chování Pythonu na různých systémech je zdrojem chyb, které ostatní jazyky neřeší.

Nepříjemná část je v oddílu o zpětné kompatibilitě téhož dokumentu. Program, který se na dosavadní výchozí kódování spoléhal, může podle PEPu skončit chybou UnicodeError, vypsat zpřeházené znaky, nebo si dat tiše poškodit (v originále „silent data corruption“). Nejvíc to dopadá na Windows, kde bylo výchozí kódování dosud odvozené od nastavení systému. Staré chování se vrací proměnnou prostředí PYTHONUTF8=0 nebo přepínačem -X utf8=0; režim UTF-8 se tedy dá i nadále vypnout, jen se nově nemusí zapínat. Dokumentace k tomu dodává, že nejlepší je kódování u každého otevření souboru napsat výslovně.

Líný import existuje, ale musí se vyžádat

Druhá viditelná novinka je klíčové slovo lazy. Zápisem lazy import json nebo lazy from pathlib import Path se modul nenačte hned, ale až ve chvíli, kdy program se jménem poprvé opravdu pracuje. Import tak může zůstat nahoře v souboru, kam patří, aniž by se za něj platilo při každém spuštění.

lazy import json
lazy from pathlib import Path

print("Starting up...")  # json ani pathlib zatím načtené nejsou

data = json.loads('{"key": "value"}')  # tady se načte json
p = Path(".")                          # a tady pathlib

PEP 810 zdůrazňuje, že jde o volbu, ne o změnu chování: existující programy běží dál stejně, dokud si o líné načítání někdo neřekne. Kdo ho chce zapnout plošně bez zásahu do kódu, má na to přepínač -X lazy_imports a proměnnou PYTHON_LAZY_IMPORTS. Omezení jsou tvrdá – lazy smí stát jen na úrovni modulu, uvnitř funkce, těla třídy nebo bloku try skončí chybou syntaxe, a stejně dopadne hvězdičkový import i import z __future__.

S čísly je to horší. PEP mluví o zkrácení startu o 50 až 70 procent u nástrojů příkazové řádky a o úspoře paměti 30 až 40 procent „v reálném provozu“, u žádného z nich ale neuvádí, odkud se vzalo. Jediný údaj s doloženým zdrojem je zrychlení startu o 10 až 20 procent u aplikací postavených na PySide, kde PEP odkazuje na konkrétní hlášení v systému chyb Qt. Doložená je i jiná věc: v samotné standardní knihovně je už dnes zhruba 17 procent importů mimo testy schovaných uvnitř funkcí, tedy skoro 3 500 importů v 730 souborech. Líné načítání si tedy vývojáři dělali ručně dávno, jen kvůli tomu musel import z hlavičky souboru zmizet dovnitř funkce.

Rychlost nástrojů je téma i v jiných jazycích. TypeScript kvůli ní přepsal celý překladač do Go a sestavení tím zkrátil na osminu až dvanáctinu.

Rozšíření pro běh bez globálního zámku mají vlastní stabilní ABI

Třetí změna je pod povrchem a týká se knihoven psaných v C. Python má v běžném sestavení globální zámek interpretu, který pouští ke kódu v jednu chvíli jen jedno vlákno. Od verze 3.13 vedle něj existuje sestavení bez tohoto zámku a od 3.14 se nepovažuje za pokus, jenže rozšíření se pro něj musela stavět zvlášť pro každou verzi Pythonu.

PEP 803 od Petra Viktorina a Nathana Goldbauma zavádí variantu stabilního rozhraní abi3t, ve které jde rozšíření přeložit jednou a používat i na sestaveních bez zámku. Cena za to není malá. Struktura PyObject se stává neprůhlednou, takže se do ní nesmí sahat přímo ani ji vkládat do vlastních struktur; knihovna musí přejít na rozhraní zavedené v PEP 697 a místo dosavadní vstupní funkce PyInit_ použít nový vývozní bod PyModExport_ z PEP 793. Dokumentace navíc upozorňuje, že stabilní rozhraní nenabízí všechno, co CPython umí – kdo se do něj nevejde, staví dál zvlášť pro klasické stabilní ABI a zvlášť pro verzi bez zámku.

Drobnost pro uživatele Maců: oficiální instalátory pro macOS nově instalují podporu běhu bez globálního zámku ve výchozím stavu.

Co se ještě do 3.15 vešlo

Vedle toho přibývá neměnný slovník frozendict, vestavěný typ sentinel pro zástupné hodnoty, rozbalování v seznamových a podobných zkrácených zápisech, samostatný balíček na profilování s novým vzorkovacím profilerem Tachyon a ukazatele na rámce zapnuté ve výchozím stavu, což usnadňuje sledování běžícího programu nástroji operačního systému. Překladač JIT se podle poznámek k vydání výrazně změnil; konkrétní naměřené zrychlení v nich ale není, a čísla, která kolují po přetiscích, se nedají doložit z původního zdroje.

Do ostré verze zbývají dva kandidáti na vydání a dva měsíce. Kdo spravuje kód, který otevírá soubory bez uvedeného kódování, má právě teď nejlepší příležitost zjistit, kolik takových míst v něm vlastně je.

Zdroje: oznámení Python 3.15.0b4 na blogu vývojářů, poznámky k vydání 3.15, návrhy PEP 686, PEP 810 a PEP 803, plán vydání PEP 790 a text Tima Andersona na The Register.