Omarchy (Wikipedie) je linuxová distribuce s dlaždicovým správcem oken Hyprland. Založena je na Arch Linuxu. Vydána byla v nové verzi 4.5.0. Nově také pro Apple Silicon, konkrétně pro M1/M2/M3/Neo MacBooky.
Byla vydána nová stabilní verze 8.3 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 156 s bezpečnostními opravami z Chromia 157. Přehled novinek i s náhledy v příspěvku na blogu.
Multimediální přehrávač mpv byl vydán ve verzi 0.42.0. Jde o větší balík změn po bezmála roce. Mimo jiné se lépe integruje s Waylandem nebo rozšiřuje podporu DVD/Blu-ray, např. umožňuje přehrávat rovnou obrazy médií (soubory iso).
Desktopové prostředí LXQt (Lightweight Qt Desktop Environment, Wikipedie) vzniklé sloučením projektů Razor-qt a LXDE bylo vydáno ve verzi 2.5.0. Přehled novinek v poznámkách k vydání.
Byla vydána (𝕏) nová verze 8.0 LTS open source monitorovacího systému Zabbix (Wikipedie). Přehled novinek v oznámení na webu, v poznámkách k vydání a v aktualizované dokumentaci.
Byla vydána verze R14.1.7 desktopového prostředí Trinity Desktop Environment (TDE, fork KDE 3.5, Wikipedie). Přehled novinek v poznámkách k vydání, podrobnosti v seznamu změn.
Bazzite (Wikipedie), tj. linuxová distribuce vycházející z Fedora Linuxu a optimalizována pro hraní počítačových her, byla vydána ve verzi 45. S Open Gaming Collective (OGC) jádrem a novým Easy Anti-Cheatem pro Linux (EAC Linux v2).
MikroTik zveřejnil vlastní bezpečnostní upozornění potvrzující, že zranitelnost linuxového jádra postihuje také RouterOS 7. Jde o use-after-free při zpracování IPv4 TCP spojení s IP options. Zranitelnost se týká provozu směřujícího na TCP službu samotného routeru, nikoli paketů, které router pouze přeposílá. Opraveno v long-term od 7.24.6, v stable od 7.25.1 a devel od 7.26beta5.
Ve správci balíčků APT, používaném v Debianu a odvozených distribucích, byla nalezena a opravena kritická zranitelnost CVE-2026-109518. Vzdálený útočník může obejít ověření stažených balíčků pomocí přesměrování a dočasných chyb HTTP serveru.
Ř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: