Názory k článku Nejdůležitější novinka v Pythonu 3.10: strukturální pattern matching

Preco kompilovat python 3.10 na fedore, ked ho ma v repozitari dost dlhu dobu? Aktualna verzia 3.10.6, testovane teraz na fedore 36...

Na Fedoře 36 to nutné není, já jsem jen ten překlad na Fedoře _testoval_ (víc mě zajímal ten Mint, protože tady provozujeme starší verze Mintu) pro lidi, co to třeba ve svých LTS distribucích nenajdou a ještě si vzpomínají, že na Linuxu byl "standardem" trojpříkaz configure+make+make install :-).

Njn... mozno by to potom este chcelo python -m test

btw, nie je od veci na jednorazovu kompilaciu pouzit kontainer, clovek potom nemusi tolko cistit system a je to mozne kompilovat proti kazdej distribucii pre ktoru existuje image...

To je pravda, hodí se vždycky. Díky moc za doplnění.

Ja bych rad doplnil jeste druhou moznost, ktera mi pri caste praci s Pythonem prijde mozna malinko lepsi. Clovek alespon nemusi pracovat s celou dalsi technologii (kontejnery) jen proto, aby si pustil python. A totiz `pyenv`. Potom pro test noveho pythonu (urcite i na starem mintu) `pyenv install 3.10.6` a je hotovo.

Pripadne venv... aby ale pozadovana verzia bola pristupna cez venv, tak musi byt nainstalovana na systeme.

Ake i tak je to offtopic, my sme pisali o kompilacii interpretru.

Ten poslední příklad z Coconutu asi nejde převést do Pythonu že:

def say_hello2(s):
    case s:
        match "My name is " + name + ".":
            return "Hi " + name

Přitom by to mohlo být hodně praktické, asi lepší, než to chytat regexpy...

Zrovna takové zachytávání Python v současnosti neumí. Ale možná v budoucnu to umět bude, zrovna v Coconutu se možná inspirovali (tedy až na prohození slov, to je asi mix s Rustem :-)

https://peps.python.org/pep-0622/#custom-matching-protocol

v pythonu se uvazovalo o uzivatelsky definovatelnem chovani metodou __match__, ale nakonec to zamitli. Pokud by to v budoucnu pridali,bylo by mozne implementovat napriklad

case RegexMatchingGroup(r'My name is (name) .', name):

Jako popravdě mám z toho smíšený pocit. Na jednu stranu je fajne, jak se Python vyvíjí a nepřešlapuje na místě. Na stranu druhou už to není ten snadný jazyk, jak býval někdy okolo Pythonu 2.x nebo i 1.6 (a teď se podržte - viděl jsem tuto verzi používat!). S novými konstrukcemi, možností zápisu datových typů, teď ještě novými operátory (Walrus operátor asi začátečníky dost zmate) a tak...

Vidím to podobně, Python jde cestou C++, "feature creep as a feature". Věta There should be one – and preferably only one – obvious way to do it už dávno neplatí.

30. 8. 2022, 10:07 editováno autorem komentáře

Nedá mi to, musím parafrázovat:

There should be one – and preferably only one – obvious way to do it != now you have Python 2 and Python 3, almost incompatible ways to do it

Žádný Python 2 ale už de iure neexistuje. Pokud někdo něco programuje v Pythonu 2 (pevně doufám, že tedy používá 2.7, kde ta kompatibilita přece jenom je co největší), dobře mu tak.

Pohybuji se na rozhraní dvou světů - "velké" IT, tedy firmy, které mají velké IT oddělení a mohly si dovolit migraci už dávno (a někdy to dost bolelo). A potom malé firmy, co mají nějaké aplikace kdysi udělané v Pythonu 2 (různé reporty atd.) a tam prostě nejsou peníze a hlavně vůle s tím něco dělat - jen vždycky někdo něco do skriptu přidá, ale migraci na Python 3 si nelajzne. Takže tam se udržují prastaré Pythony 2.

jo no, ale de iure neni de facto :-). Nektery projekty tedy prechazi pomalu, treba takova Callibra

Z jaký python je v gimpu, inkscape nebo open office?

Podle ne se jen ten jediny (doporuceny) zpusob casem meni.

Walrus operator v mnoha situacich nahradi while True idiom. Pattern matching nahradi retez ifu nebo tu prisernost se slovnikem lambda funkci.

Myslíš něco podobného? Někdy se to hodilo :D ... Takovej chudej swich

def update(self, action: Action) -> 'Machine':
      """
      Update the machine state.
      """
      state = {
          (State.CLOSED, Action.OPEN): State.OPENED,
          (State.OPENED, Action.CLOSE): State.CLOSED,
          ...
      }[(self.state, action)]
      ...

31. 8. 2022, 16:16 editováno autorem komentáře

Neco takoveho, hodnoty toho slovniku mohou byt funkce

Pamatuju si, že zrovna := mi v začátcích (před více než 20 lety) při přechodu na Python chyběl. Je pravda, že za ty roky jsem si už zvykl.

30. 8. 2022, 10:17 editováno autorem komentáře

Ale to prechazels odjinud. Takovy zacatecnik asi muze byt zmateny. ale popravde nevim, protoze tady se decka (15 a 17 let) sice uci Python, ale nekde na urovni puvodniho Pythonu 1 :-) - tedy zadne list comprehensions, pochopitelne vubec nic s typovou anotaci, zadne f-stringy, bodudik do nich ani necpou OOP

Já teda znám jen 2 a 3, ale nevšiml jsem si, že by bylo nějak hodně velkých změn. Většina je syntaktický cukr, možnost napsat to jednodušeji, ale že by nebyla možnost napsat to původním způsobem. Walrus, patterny, f stringy, generátory... nic z toho čék nemusí používat.

Pokud "čék" funguje v totální izolaci, tak samozřejmě. V realitě ale potřebuje číst cizí kód a pracovat s knihovnami, a tak logicky musí chápat a používat všechny změny, které adoptuje komunita.

Osobně mi přijde, že nejproblematičtější oblastí je formátování řetězců - teď máme (pokud mi něco neuniká) 4! způsoby jak formátovat řetězec standardními prostředky Pythonu:

1. Klasický C přístup s %
2. Rust-like formátování s .format()
3. f-string
4. Template strings

To je docela přehnané, podobně zbytečná mi přijde i dualita používání jednoduchých a dvojitých uvozovek.

Walrus operator má v zásadě hlavní hodnotu v list comprehensions a generator expressions. Používat se ale nemusí, jak píšeš.

Format a fstring ma stejnou syntax a je to doporuceny zpusob pokud nemate specificky pozadavek.

C-style se hodi pokud prechazite mezi C a pythonem.

1. a 4. už jsem dlouho nikde neviděl. Zase je super, že lidi z různých jazyků si mohou vybrat co se jim líbí. Za mě jsou f-stringy super Pythonu velmi pomohli. Co bych za to dal kdyby tohle bylo v Java.

Python má vyše 30 rokov. Je pochopiteľné, že sa autori rozhodli pridať nejaké nové prvky z iných jazykov. Ja to kvitujem. Trebárs ten fstring je jedným z najlepších a najprehľadnejších riešení aké poznám. Tie ostatné sú historickým reliktom; programátori nie sú nutení poznať/používať všetky spôsoby. V C# je to podobne; tam je tých vylepšení na mraky.

Nik nedokáže navrhnúť jazyk hneď perfektne na prvý krát.

Klasický zastaralý C přístup s % doporučuju nepoužívat. F-stringy jsou super na krátké formátované řetězce. Na delší řetězce nebo řetězce, které obsahují hromadu výpočtů, používám pro lepší čitelnost metodu format(). Template strings jsem dosud neznal. Zdá se, že mají úzce zaměřené použití.

V 99 % času používám jednoduché uvozovky. Jen výjimečně použiju dvojité právě v f-stringu: f'Mlíko stojí {mliko["cena"]} Kč'

Za mě mezi 2 a 3 přibyl zápas s „tohle je string a tohle jsou bytes“, bez možnosti říct něco jako „teď budu používat pouze ascii (nebo utf8) tak si to násilím zkonvertuj když potřebuješ“.

30. 8. 2022, 11:43 editováno autorem komentáře

String ve trojce je u-string z dvojky. Defaultne jsou vstupy dekodovany utf8.

30. 8. 2022, 11:51 editováno autorem komentáře

Zde bych spíš viděl chybu implementace, kterou přinášel starý Python. Řetězec je řetězec a bajty jsou bajty. Doba, kdy se kódovaly texty 8 bity na znak, je už několik desítek let za námi.

Jo no, jen par novejsich jazyku to ma spravne. A to nemluvim o databazich, kde "char" znamena kdovico - nekdy bajt, nekdy znak :)

Souhlas, ale nutno uznat, nějaké globální "chci stringy utf-8 všude" by se asi hodilo.

Skor ten zapas skoncil...

'abcd' - default utf8, stale je mozne zvolit v akom kodovani je zdrojovy text
b'abcd' - 8 bit na znak

a pre konverziu su uplne nanasilne metody encode() a decode()

Možná nejsem hoden programování v Pythonu (přitom se to dřív prezentovalo jako jazyk pro lamy :), ale furt se mi občas podaří že mi program crashne na to, že strkám jedno do druhého, i když by vůbec nemusel, protože pracuju s věcmi co by šly bez problému přetypovat automaticky.

Nedávno som sa hlbšie venoval práve pattern match syntaxe. Podľa mňa nejde len o nejaký vylepšený switch/case, ale o fundamentálne hlbší spôsob analýzy dát.

Práve v poslednej dobe sa pattern match pridal do viacerých jazykov: PHP, Python, Groovy (switch expression), Java či C#. Hodnotenie: Java (bieda), Python, PHP (slabé), Kotlin, C#, Rust, Scala (OK), Groovy, F# (excelentné).

Raku je pravdepodobne tiež veľmi dobré; Clojure tuším zo svojej podstaty pattern match nepotrebuje.

Ináč jednotlivým voľbám sa hovorí arms ako protikladu branches pri klasickom switch/case.

Tie excelentné jazyky majú guards, ranges, a množstvo spôsobov ako rozpitvať dátové štruktúry. Pattern match je výraz, ktorý vracia hodnotu. Podporujú priamy regex match.

def rnd = new Random()
def ri = rnd.nextInt(-5, 5)

def res = switch (ri) {
    case { ri < 0 } -> "${ri}: negative value"
    case { ri == 0 } -> "${ri}: zero"
    case { ri > 0 } -> "${ri}: positive value"

}

println res

Tento Groovy príklad ukazuje priradenie voľby do premennej a guards.

def rnd = new Random()
def ri = rnd.nextInt(0, 120)

switch (ri) {

    case 1..30 -> println('value is in the range from 1 to 30')
    case 31..60 -> println('value is in the range from 31 to 60')
    case 61..90 -> println('value is in the range from 61 to 90')
    case 91..120 -> println('value is in the range from 91 to 120')
}

Groovy a ranges.

def words = ['week', 'bitcoin', 'cloud', 'copper', 'raw', 'war',
    'cup', 'water']

def selected = []

for (word in words) {

    def res = switch (word) {

        case ~/^w.*/ -> word
        case ~/^c.*/ -> word
        default -> 'skip'
    }

    if (res != 'skip') {
        selected.add(res)
    }
}

println selected

Groovy a regex výrazy.

open System

printf "Enter a number: "

let value = Console.ReadLine()

let n =
    match Int32.TryParse value with
    | true, num -> num
    | _ -> failwithf "'%s' is not an integer" value


let f = function
    | value when value > 0 -> printfn "positive value"
    | value when value = 0 -> printfn "zero"
    | value when value < 0 -> printfn "negative value"

f (int value)
f n

F# a spracovanie chýb.

let grades = ["A"; "B"; "C"; "D"; "E"; "F"; "FX"]

for grade in grades do

    match grade with
    | "A" | "B" | "C" | "D" | "E" | "F" -> printfn "%s" "passed"
    | _ -> printfn "%s" "failed"

F# a viacnásobné voľby, ktoré výrazne skracujú zápis.

Nestyď se a klidně si ten článek před komentováním přečti.

Ja sa nehanbím, článok som prečítal. :)

Ten pattern matching na třídu bude občas docela peklo, protoze vubec nebere ohled na argumenty metody __init__, jak by se na prvni pohled zdalo.
Specifikace je tady: https://peps.python.org/pep-0634/#class-patterns

class Foo:
def __init__(self, x, y=0, z=0):
self.a = x
self.b = y
self.c = z

match subject:
case Foo() - matchuje pomoci isinstance(x, Foo)
case Foo(a=1, b=2) - navic testuje zda subject.a == 1 a subject.b==2
case Foo(1, a=1, b=2) - Nejprve se zase provede isinstance(x, Foo), pak se pomoci subject.__mat­ch_args__ se zjisti jmeno atriburtu pro prvni argument a pak se zkontrolujou hodnoty atributu stejne jako v prechozim pripade. Pro built-in typy (viz vycet v dokumentaci) se to samozrejme chova jinak.

To ale znamena, ze vyraz Foo(x, y=z) uvnitr 'case' znamena (semanticky) neco uplne jineho, nez ve zbytku kodu. Nejsem si jisty, jestli se mi to libi.

Obecne pri programovani neni dobre se ridit dojmy. __init__ se nevola. Matchuji se atributy.

31. 8. 2022, 13:11 editováno autorem komentáře

Jojo je to presne tak. Navic to neumi "vnorene" typy, tedy alespon jsem to z pohledu na gramatiku nedokazal vycist (ale tusim, ze to asi fakt zatim nepujde).

Vnorene typy funguji, pokud myslite tohle

class Point:
    def __init__(self, x, y):
        self.x = x
        self.y = y


class Line:
    def __init__(self, a, b):
        self.a = a
        self.b = b


l = Line(Point(0, 0), Point(1, 1))

match l:
    case Line(a=Point(x=0, y=0), b=Point(x=x, y=y)):
        print(x, y)
    case _:
        print('no match')

vypise 1, 1

aha super, toto jsem myslel, dík za doplnění.

Na to je jednoduché řešení; nepoužívat positional patterns vůbec. Já ve skutečnosti v Pythonu preferuju používat keyword argumenty v Pythonu; pak je rozumná jistota, že posílám hodnoty tam, kam potřebuju a žádná změna signatury funkce/metody to nerozbije. Explicitní je lepší než implicitní a tady na 100%.

On asi neni problem jen v signature, ten konstruktor muze argumenty ruzne transformovat.

> On asi neni problem jen v signature, ten konstruktor muze argumenty ruzne transformovat.

Nejen konstruktor, objekt v Pythonu je obecně mutable a s atributy se může stát kdykoli cokoli. Já jsem, co se týče signatury, ale měl na mysli normální volání funkcí, ne pattern matching.

31. 8. 2022, 19:24 editováno autorem komentáře

Jeste slavnejsi hlaska DOSu byla
"General failure reading disk C:"
nasledovala otazka
"Kdo je to general Failure a proc cte muj harddisk?"
:-)

Zaznělo to spoustu zajímavých programovacích jazyků...
Jenom mi v tom výčtu trochu chybí Erlang :-)

Taky chybí Agda :)