Microsoft představil Azure Linux 4.0 a Azure Container Linux. Na konferenci Open Source Summit North America 2026 organizované konsorciem Linux Foundation a sponzorované také Microsoftem. Azure Linux 4.0 vychází z Fedora Linuxu. Azure Container Linux je založen na projektu Flatcar. Azure Linux (GitHub, Wikipedie) byl původně znám jako CBL-Mariner.
Nové číslo časopisu Raspberry Pi zdarma ke čtení: Raspberry Pi Official Magazine 165 (pdf).
Byla vydána verze 9.2 open source virtualizační platformy Proxmox VE (Proxmox Virtual Environment, Wikipedie) založené na Debianu. Přehled novinek v poznámkách k vydání a informačním videu.
Firefox 151 podporuje Web Serial API. Pro komunikaci s různými mikrokontroléry připojenými přes USB nebo sériové porty už není nutné spouštět Chrome nebo na Chromiu postavené webové prohlížeče.
Byla vydána nová stabilní verze 8.0 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 148. Přehled novinek i s náhledy v příspěvku na blogu.
Ve FreeBSD byla nalezena a opravena zranitelnost FatGid aneb CVE-2026-45250. Jedná se o lokální eskalaci práv. Neprivilegovaný uživatel se může stát rootem.
Společnost Flipper Devices oznámila Flipper One. Zcela nový Flipper postavený od nuly. Jedná se o open-source linuxovou platformu založenou na čipu Rockchip RK3576. Hledají se dobrovolníci pro pomoc s dokončením vývoje (ovladače, testování, tvorba modulů).
Vývojáři Wine oznámili vydání verze 2.0 knihovny vkd3d pro překlad volání Direct3D na Vulkan. Přehled novinek na GitLabu.
Společnost Red Hat oznámila vydání Red Hat Enterprise Linuxu (RHEL) 10.2 a 9.8. Vedle nových vlastností a oprav chyb přináší také aktualizaci ovladačů a předběžné ukázky budoucích technologií. Vypíchnout lze CLI AI asistenta goose. Podrobnosti v poznámkách k vydání (10.2 a 9.8).
Organizace Apache Software Foundation (ASF) vydala verzi 30 integrovaného vývojového prostředí a vývojové platformy napsané v Javě NetBeans (Wikipedie). Přehled novinek na GitHubu. Instalovat lze také ze Snapcraftu a Flathubu.
Řešení dotazu:
Ahoj. Začínám tvořit v Pajtnu celkem složitý projekt a uvízl jsem na importu. Pokud budu importovat třeba class s názvem Foo() a tato třída bude umístěna v /a/b/c/d/__init__.py…Kdyz uz tak v
a/b/c bude d.py a v nem tridy. __init__.py na tyhle veci nezneuzivej.
…tak ji sourcnu from a.b.c.d import Foo a zavolám a.b.c.d.Foo(). Potud vše OK…Ne, to neni ok.
from…import ti udela referenci na Foo ale ne a.b.c.d takze jestli ti to nevybouchne tak mas nekde schovanej import a.b.c.d. Pak ti ale nic nezaruci ze Foo je reference na stejny objekt jako a.b.c.d.Foo, coz je chyba ktera se ti muze pekelne nevyplatit. Cely je to ukazkovy priklad proc je radno se from…import vyhybat.
…ale když potřebuji z class Foo() volat další class Bar(), sourcnu from a.b.c.d import Bar a zavolám Bar(). Jenže potřebuji zachovat strukturu, čili bych chtěl i z class Foo() volat a.b.c.d.Bar() namísto jen Bar()…Kdyz bude
a (tedy ten prvni modul z a.b.c.d) nekde v PYTHONPATH tak to bude fungovat. Ale cely je to nesmysl – kdyz nechces aby se moduly chovaly jako moduly, tak je proste nepouzivej. Ty tecky nejsou jen syntakticky cukr ktery kompiler dereferencuje a zapomene jako treba v jave. Jednoduse receno, kazda tecka je nejaky jmenny prostor (modulu, objektu nebo instance). A pokud je budes vyrabet zbytecne jen proto ze to dobre vypada ve zdrojaku, tak strukturu nezachovavas ale naopak rozbijis.
…či self.Bar(). Poradí někdo?Tezko rict kdyz nenapises o co se snazis. Pokud opravdu potrebujes takhle strukturovat jmenne prostory tak bych misto ohybani modulu spis udelal proxy objekty ktere to zaridi v __getattr__(). Ale vzhledem k tomu ze viditelne netusis jak funguji jmenne prostory bych spis rekl ze se snazis realizovat nejaky zlozvyk z jineho jazyka ktery v pythonu nedava smysl.
potřebuji zachovat strukturu, čili bych chtěl i z class Foo() volat a.b.c.d.Bar() namísto jen Bar() či self.Bar()Docela by mě zajímalo proč.
Tiskni
Sdílej: