Asociace repair.org udělila anticeny těm nejhorším produktům představeným na veletrhu CES 2026. Oceněnými jsou například šmírující kamery Amazon Ring AI, chytrý běžecký pás od společnosti Merach, která otevřeně přiznává, že nedokáže zabezpečit osobní data uživatelů, případně jednorázové lízátko, které rozvibrovává čelisti uživatele a tak přehrává hudbu. Absolutním vítězem je lednička od Samsungu, která zobrazuje reklamy a kterou lze otevřít pouze hlasovým příkazem přes cloudovou službu.
Íránští protirežimní aktivisté si všímají 30% až 80% ztráty packetů při komunikaci se satelity služby Starlink. Mohlo by se jednat o vedlejší důsledek rušení GPS, kterou pozemní přijímače Starlinku používají k výpočtu polohy satelitů a kterou se režim rovněž snaží blokovat, podle bezpečnostního experta a iranisty Amira Rashidiho je ale pravděpodobnější příčinou terestrické rušení přímo satelitní komunikace Starlinku podobnou
… více »Evropská komise (EK) zvažuje, že zařadí komunikační službu WhatsApp americké společnosti Meta mezi velké internetové platformy, které podléhají přísnější regulaci podle unijního nařízení o digitálních službách (DSA). Firmy s více než 45 miliony uživatelů jsou podle DSA považovány za velmi velké on-line platformy (Very Large Online Platforms; VLOP) a podléhají přísnějším pravidlům EU pro internetový obsah. Pravidla po
… více »Tržní hodnota technologické společnosti Alphabet poprvé v historii přesáhla čtyři biliony dolarů (83 bilionů Kč). Stalo se tak poté, co Apple oznámil, že bude na poli umělé inteligence (AI) spolupracovat s dceřinou firmou Alphabetu, společností Google.
Nové číslo časopisu Raspberry Pi zdarma ke čtení: Raspberry Pi Official Magazine 161 (pdf).
Po delší době vývoje vyšla nativní linuxová verze virtuálního bubeníka MT-PowerDrumKit 2 ve formátu VST3. Mezi testovanými hosty jsou Reaper, Ardour, Bitwig a Carla.
Desktopové prostředí Budgie bylo vydáno ve verzi 10.10. Dokončena byla migrace z X11 na Wayland. Budgie 10 vstupuje do režimu údržby. Vývoj se přesouvá k Budgie 11. Dlouho se řešilo, v čem bude nové Budgie napsáno. Budgie 10 je postaveno nad GTK 3. Přemýšlelo se také nad přepsáním z GTK do EFL. Budgie 11 bude nakonec postaveno nad Qt 6.
OpenChaos.dev je 'samovolně se vyvíjející open source projekt' s nedefinovaným cílem. Každý týden mohou lidé hlasovat o návrzích (pull requestech), přičemž vítězný návrh se integruje do kódu projektu (repozitář na GitHubu). Hlasováním je možné změnit téměř vše, včetně tohoto pravidla. Hlasování končí vždy v neděli v 9:00 UTC.
Byl vydán Debian 13.3, tj. třetí opravná verze Debianu 13 s kódovým názvem Trixie a Debian 12.13, tj. třináctá opravná verze Debianu 12 s kódovým názvem Bookworm. Řešeny jsou především bezpečnostní problémy, ale také několik vážných chyb. Instalační média Debianu 13 a Debianu 12 lze samozřejmě nadále k instalaci používat. Po instalaci stačí systém aktualizovat.
Na stránkách Evropské komise, na portálu Podělte se o svůj názor, se lze do 3. února podělit o názor k iniciativě Evropské otevřené digitální ekosystémy řešící přístup EU k otevřenému softwaru.
Mám funkci v Pythonu:
def get_template(template_file):
"""Get a file containing a template. Return its content as a string."""
try:
return open(template_file, 'r').read()
except IOError:
print "Error: Cannot read the file containing the template."
Na webu Pythonu se ale (v HOWTO Idioms and Anti-Idioms in Python) uvádí jako ne zcela správný příklad:
def get_status(file):
try:
return open(file).readline()
except (IOError, OSError):
print "file not found"
sys.exit(1)
Mimochodem, proč je tam OSError?
U příkladu níže se píše, že ideální a že výjimka se má řešit v místě volání (což nechci).
def get_status(file):
fp = open(file)
try:
return fp.readline()
finally:
fp.close()
Jak je to v mém kódu s uzavíráním souboru? Nemám do svého try bloku vnořit ještě jeden s větví finally?
Řešení dotazu:
Nikdo neodpovídá, tak to zkusím. Ale moc nevím, v čem je jádro pudla, tak to nějak vágně okomentuju:
Jestliže chci přečíst soubor, tak chci buď jeho obsah nebo vyhozenou výjimku. Ten první příklad se mi proto moc nelíbí, protože když něco selže, tak jen vypíše nějaký řetězec na obrazovku, ale vrátí None. Navíc, nevypíšou se podrobnosti o chybě. Zavírat soubor nemusíš.
Ve druhém (a třetím) příkladě se přepisuje klíčové slovo „file“, což není dobrý nápad. Naopak, je spíš zvykem používat file místo open (jsou to synonyma).
Druhý příklad: Kdy se v tomto případě může vyskytnout OSError, to nevím. Dám se podat.
Třetí příklad považuju za zrádný. Někdy vrátí None, někdy vyhodí výjimku,
No prostě, já bych to psal takhle
def readfile(fn):
return file(fn).read()
A na to bych vlastně ani nepsal funkci. Ale to je do značné míry otázka vkusu a taky toho, jak moc si chceš všechno ošetřit sám.
Imho ten první příklad je spíš špatně proto, že ověřuje existenci souboru pomocí vyjímky.To by se spíš mělo řešit např pomocí os.path ...
os.path mi nevyřeší případ, když během čtení něco ten soubor smaže. Takže tam mám dát obojí?
Je to tak jak řikáš - os.path spoustu věcí nevyřeší. Jako špatný příklad je to podle mě uvedeno právě z toho důvodu, že se tím ověřuje existence souboru, na což jsou ale jinačí nástroje. Pro jiné případy může být samořejmě použití vyjímek adekvátní.
No a? Pokud je ten soubor pro funkčnost nutný, pak je výjimka na místě. Pokud má aplikace počítat s tím, že soubor tam být nemusí, pak bylo by lepší použít os.path.isfile().
Pokud je soubor nutný, tak bych vyhodil svojí vyjímku:
if not os.path.exists("soubor"):
raise NejakaMojeVyjimka(.......)
To je jedna třída a několik řádků kódu navíc. Záleží na rozsahu a komplexnosti projektu, jestli je nutné mít pro všechno vlastní výjimky.
Stejně tak pak musíš ošetřit i výjimku z open()/file(), protože ten soubor mohl v čase mezi exists() a open() někdo smazat 
Záleží na rozsahu a komplexnosti projektu...
Několik set řádků, možná to poslouží jako backend pro GUI nebo jednoduchou webovou aplikaci.
Jestliže chci přečíst soubor, tak chci buď jeho obsah nebo vyhozenou výjimku. Ten první příklad se mi proto moc nelíbí, protože když něco selže, tak jen vypíše nějaký řetězec na obrazovku, ale vrátí None. Navíc, nevypíšou se podrobnosti o chybě.
OK, co s tím? sys.exit? Ale to je nevhodné při použití jako knihovny ve frameworku...
Zavírat soubor nemusíš.
Díky.
Ve druhém (a třetím) příkladě se přepisuje klíčové slovo „file“, což není dobrý nápad. Naopak, je spíš zvykem používat file místo open (jsou to synonyma).
Ten kód je z webu Pythonu...
Třetí příklad považuju za zrádný. Někdy vrátí None, někdy vyhodí výjimku,...
Taky si myslím, ale autor toho HOWTO píše, že to má být ošetřeno v místě volání funkce.
OK, co s tím?
sys.exit? Ale to je nevhodné při použití jako knihovny ve frameworku..
Tak mohlo by to třeba vyhazovat výjimku, že
Nebo vracet None. Ale výjimka bude lepší, především může nést informaci o chybě; to tam pak ani žádné try-except nemusíš dávat. Knihovna by asi také neměla sama od sebe něco vypisovat na jakýkoliv standardní výstup, stejně jako by neměla exitovat (pokud to ovšem nemá být smysl knihovny).
Soubor se ti uzavře sám, jakmile se garbage collector bude chtít zbavit instance file. To může být kdykoliv a může to případně i vypisovat nějaké warningy nebo tak něco, což by mohlo být dost nečekané a matoucí, takže občas se soubory uzavírají v bloku finally.
Mimochodem, pokud řešíš takové detaily už u obyčejného čtení souboru, co teprve děláš při rozhodování o celkovém designu aplikace? 
Tak mohlo by to třeba vyhazovat výjimku, že
Bingo!
Mimochodem, pokud řešíš takové detaily už u obyčejného čtení souboru, co teprve děláš při rozhodování o celkovém designu aplikace?
Ladím si styl. ^_^
Jestliže ty výjimky odchytávat nepotřebuješ, tak to nedělej. Mnohem lépe se to pak ladí, protože backtrace ukáže spoustu důležitých informací. Nejhorší je, když někdo odchytne vyjimku a dá tam print "ERROR" a ukončí program.
None.
Informace, kde přesně je chyba, by ale měla být součástí té výjimky, ne? Obecně platí, že by měla být přísně dodržena pravidla ošetřování chyb - buď VŠECHNO ve frameworku pouští/vyhazuje výjimku, nebo všechno vrací/nastavuje nějaký předdefinovaný chybový stav (None, -1, ...). V tomhle případě zřejmě metoda předpokládá, že template existuje a jeho neexistence je tedy vyjímečným stavem (odtud výjimka
).
Já bych definoval vlastní výjimku (obecnou TemplateError, případně z ní ještě odvozenou TemplateReadfileError) obsahující příslušné informace a do ní vložil původní výjimku - nikdy nevím, kdy framework použiju nebo jak moc se rozroste.
Když už jsme u toho, místo metody get_template bych udělal třídu Template buď obsahující metodu něco jako Load, nebo načítající template v konstruktoru - pro jistotu, nikdy nevím, co všechno budu chtít s templatem ještě dělat, aspoň by to bylo všechno v kupě. 
Navíc možná by bylo dobré neotvírat přímo soubory z disku, ale vytvořit si třídu, která bude zajišťovat načítání dat podle nějakého identifikátoru (v tomhle nejjednodušším případě podle jména souboru), nikdy nevím, kdy budu chtít templaty třeba načítat z databáze... Záleží na tom, jak moc si představuješ, že se ten framework může rozrůst a na co všechno bys ho mohl chtít použít.
Tiskni
Sdílej: