Má Python budoucnost?

[Ivan Nový]

Tak todle moc čitelné není a je to v haskellu (přebráno z GitHubu):

onCreate :: JNIEnv -> JObject -> JObject -> IO ()
onCreate env activity _bundle = runJNISafe () env $ do
  msg <- liftIO $ do
    getNumProcessors >>= setNumCapabilities
    caps <- getNumCapabilities
    return $ "Hello World!\nRunning on " `append` pack (show caps) `append` " CPUs!"

Programovaci jazyk nema nutne byt citelny pro ty, kteri jej neznaji (a uz vubec ne, pokud neznaji ani dane paradigma). Nedokazu pousoudit, zda je to nejhezci mozny zapis v Haskellu, ale citelne a krasne me to prijde (no, mozna az na ten append).

Zkuste si v cistem Pythonu hezky funkcionalne retezit par transformaci (napr. nekolik map, filter a pouzijte v nich inline funkce) a pak srovnejte se Scalou nebo Haskellem. To teprv uvidite tu krasu .

Řetězení transformací je chytlavý nešvar FP, nedá se to dobře testovat. A v konečném důsledku je to podobné, jako když funkce má 12 parametrů.
Python je navržen schválně tak, aby nic nešlo lehce řetězit.

[Reklama]

[noef]

Řetězení transformací je chytlavý nešvar FP, nedá se to dobře testovat.

To pouze odpovida nekolika prikazum za sebou. Nebo bezne snad testujete jen polovinu metody objektu, napr. jen prvni tri prikazy, ikdyz jich metoda obsahuje 20? Treba v Jave to asi mozne je, ale nevim proc to delat.

A v konečném důsledku je to podobné, jako když funkce má 12 parametrů.

Ne, neni. Stejne jako mit 12 prikazu v metode neznamena, ze je to stejne jako mit 12 parametru.

Python je navržen schválně tak, aby nic nešlo lehce řetězit.

S tim souhlasim, je zamerne navrzen tak, aby v nem neslo elegentne provozovat FP. Ostatne myslim, ze i samotny tvurce se k tomu tak vyjadril, ze FP je pro neho na druhe koleji. Cely Python je zamerne navrzen tak, aby byl ukecany, coz nemam rad - jazyk je hezky pro novacky, jakmile ale po chvili povysi na znale, tak najednou vidi vsude tu ukecanost pro zacatecniky, ktera pokrocilym uz ale nic neprinasi. Nevzniklo ostatne proto Ruby?

[Ondrej]

Z mého pohledu to jsou zvěrstva, které v běžné aplikaci nemají co pohledávat. Když někdo použije takový hnus, tak se nemůže divit, že se to chová podivně. Podivně se v PHP chová například typ boolean. Už léta ho nepoužívám, protože mi připadá v dnešní době zbytečný. Kdo ho používá, tak se občas diví.

OMG, co je teda spravny typ pro bool hodnotu? Integer nula/nenula?


A z jineho soudku:
http://stackoverflow.com/questions/70528/why-are-pythons-private-methods-not-actually-private

Je tam genialni implementace privatni metody pres inspect outer caller:

Kód: [Vybrat]

import re
import inspect

class MyClass :

    def __init__(self) :
        pass

    def private_function ( self ) :
        try :
            function_call = inspect.stack()[1][4][0].strip()

            # See if the function_call has "self." in the begining
            matched = re.match( '^self\.', function_call )
            if not matched :
                print 'This is Private Function, Go Away'
                return
        except :
            print 'This is Private Function, Go Away'
            return

        # This is the real Function, only accessible inside class #
        print 'Hey, Welcome in to function'

    def public_function ( self ) :
        # i can call private function from inside the class
        self.private_function()

Celkem 180 upvotes a tisice dekovnych dopisu.
Tomuhle se uz neda ani smat, to je jedno velke WTF.

Nic jako privátní meto v Pythonu není.
K _ prostě přistupovat můžeš, ale pak se nediv...

Nicméně to že někdo takhle privátní metodu zprasí a spousta lidí mu ještě děkuje je nepochopitelné, prostě WTF...

S tim souhlasim, je zamerne navrzen tak, aby v nem neslo elegentne provozovat FP. Ostatne myslim, ze i samotny tvurce se k tomu tak vyjadril, ze FP je pro neho na druhe koleji. Cely Python je zamerne navrzen tak, aby byl ukecany, coz nemam rad - jazyk je hezky pro novacky, jakmile ale po chvili povysi na znale, tak najednou vidi vsude tu ukecanost pro zacatecniky, ktera pokrocilym uz ale nic neprinasi. Nevzniklo ostatne proto Ruby?

Si asi jeden z mála lidí co považuje Python za ukecanej jazyk.

[ROFL]

proměnné typu boolean nepoužívám. Bez náhrady. Těm aplikacím to prostě nechybí.

Nechodím sem často, ale skoro vždycky tady prezentujete nějaký neotřelý koncept, o kterém by mě nenapadlo ani uvažovat. Jste génius. Sepište knihu o programování. Okamžitě si jí koupím a otevřu jí vždycky, když budu mít špatnou náladu, zaručeně pobaví.

[Ivan Nový]

Řetězení transformací je chytlavý nešvar FP, nedá se to dobře testovat.

To pouze odpovida nekolika prikazum za sebou. Nebo bezne snad testujete jen polovinu metody objektu, napr. jen prvni tri prikazy, ikdyz jich metoda obsahuje 20? Treba v Jave to asi mozne je, ale nevim proc to delat.

A v konečném důsledku je to podobné, jako když funkce má 12 parametrů.

Ne, neni. Stejne jako mit 12 prikazu v metode neznamena, ze je to stejne jako mit 12 parametru.

Python je navržen schválně tak, aby nic nešlo lehce řetězit.

S tim souhlasim, je zamerne navrzen tak, aby v nem neslo elegentne provozovat FP. Ostatne myslim, ze i samotny tvurce se k tomu tak vyjadril, ze FP je pro neho na druhe koleji. Cely Python je zamerne navrzen tak, aby byl ukecany, coz nemam rad - jazyk je hezky pro novacky, jakmile ale po chvili povysi na znale, tak najednou vidi vsude tu ukecanost pro zacatecniky, ktera pokrocilym uz ale nic neprinasi. Nevzniklo ostatne proto Ruby?

Dobře, když máte výraz x = a(b(c(d(e(f(g)))))), tak jak otestujete, která funkce je špatně bez přepisování kódu. Jak se dozvíte, co je výsledkem c na reálných datech?

[Reklama]

[Citrisin]

Nic jako privátní meto v Pythonu není.
K _ prostě přistupovat můžeš, ale pak se nediv...

Nicméně to že někdo takhle privátní metodu zprasí a spousta lidí mu ještě děkuje je nepochopitelné, prostě WTF...

Přesně tak, WTF. Rád bych poznamenal, Python není Java a neměla by se z něho Java dělat. To že Python nemá nic jako privátní typ se mě osobně náhodou velice líbí. Ale pokud byste v Pythonu skutečně něco programovali tak existují standardy na kterých se jednotlivý vývojáři domluvili a metody formátu __*__ jsou považovány za privátní a nikdo je z vnějšku nevolá. Pokud je zavoláte tak se nic nestane, ale vývojář je může odstranit či změnit a váš kód může bez ohlášení přestat fungovat.

To co já považuju na Pythonu za velice dobrého je, že nutí všechny vývojáře psát stejně strukturovaný kód (pravda kopírování kódu je pak občas peklo) a dále že přímo integruje dokumentaci. Součástí definice jazyka je prostě i způsob jak dokumentovat a nástoje (žlutou vlnovkou) opozorňují že dokumentace chybí. Příjde mi prostě, že python jako takový vynucuje slušné programátorské zvyklosti, to je celé. Že je ukecaný, to místy trochu je, ale alespoň není kryptický.

K tomu, co tu párkrát okrajově zaznělo, že Python díky tomu, že se nekompiluje neprovádí žádnou kontrolu (typovou či jakoukoli jinou), ano neprovádí, je to převážně skriptovací jazyk. Ale s nástroji pylint a pep8 se většina chyb objeví již v editoru.

Finálem k diskuzi o IDE. Rád bych poznamenal, že refaktroring je možné udělat i mimo IDE, stejně tak našeptávání a sémantické prohledávání a to možná ještě efektivnějí než v případě IDE, které mají mnohdy na velkých projektech problémy. V tomto případě hovořím především o C/C++, pro Javu bych s IDE neváhal. Jinak k výběru IDE, mnohdy nemáte na výběr už jen kvůli tomu co se na projektu používalo dodneška. Pro některé existuje svět i mimo web a PC a v tomto světě většinou skončíte na IDE které má podporu právě pro vaši platformu a změna je prakticky nemožná. Z tohoto pohledu mi přijdou takové dohady zbytečné a programátor prostě musí dělat v tom v čem musí a zrovna podpora více IDE není většinou to co se ve vývoji chce podporovat, protože to není to co zákazník uvidí, práce na více platformách má už větší smysl.

[eee]

Kdyby byl Python nepouzitelny jazyk, jak tvrdis, tak ho nikdo nebude pouzivat, ale on je naopak siroce pouzivany.

Staci se podivat na PHP. Jazyk, ktery mel byt utracen davno (hrozna "specifikace", jazyk i interpret), je to jako splacane od zacinajiciho studentika VS, presto tu dal uspesne preziva. Kvalita nema bohuzel s popularitou nic spolecneho.

Rec je o pouzitelnosti, nikoliv kvalite a popularite. Je dobre rozlisovat mezi akademickou kvalitou a praktickou pouzitelnosti a zamyslet se, proc se tem akademickym jazykum v praxi tolik nedari. Velmi pravdepodobne v posouzeni kvality jazyka bude kazdy zduraznovat jine vlastnosti, rozhodne bych to neredukoval jen na cistotu syntaxe.

Ja ho naopak preferuji a uprednostnuji kde muzu a nemusim naopak Javu, ktera me osobne prijde celkove tezkopadna a neohrabana.

Python me prijde stejne neohrabany jako Java. Moc to nesleduju, ale Java 8 myslim prinasela dost FP veci, coz vede k mnohem jednodussimu kodu. Osobne me prijde Scala jako dobry kompromis mezi uplatnitelnosti (JVM) a "krasou" jazyka (velmi jednoduse zapsane slozite veci, podpora DSL, FP atd).

Neumim si predstavit, ze bych neco jako scala pouzival prakticky, tj. ze bych mel odvahu to nasadit u zakaznika v rozsahu desitek tisic radkukodu a udrzoval/rozvijel to 15+ let. Pro me je to neduveryhodny a proto _prakticky_ nepouzitelny jazyk.

V Pythonu me vadi velke mnozstvi boilerplatu (napr. @property, @staticmethod, lambda, nenasel jsem zpusob, jak lehce retezit volani funkci, takze pokusy o FP styl pusobi hrozne) a kod celkove pusobi roztahane.

Samozrejme na Haskell, co se tyce "krasy" a strucnosti, as nic moc nema*. A to jsem v nem "noob", pamatuji si ho pouze ze skoly. Ale uz i jen ty zaklady byly nezapomenutelne (pro ostatni studenty spise v tom spatnem slova smyslu ).
*: Resp. nic lepsiho jsem jeste nevidel. Pokud neco znate, tak sem s tim.

Dekoratory nejsou boilerplate, to je naopak reseni eliminujici boilerplate, ktere vede k prehlednosti a strucnosti, nejsou povinne a jsou velmi flexibilni, muzes si je prizpusobit svym potrebam. Na haskellu mi nic krasneho neprijde, ale nema smysl porovnavat funkcionalni jazyk s imperativnim a tomu druhemu vycitat opacny stav. Argument, ze pokusy programovat v haskellu imperativne vypada hrozne, bych osobne povazoval za fail :-).

A naopak, moznost program casto a co nejdriv spoustet je jedna z vyhod interpretovanych jazyku.

Vzhledem k tomu, ze existuji inkrementalni prekladace (tusim ze jej ma Java i Scala a urcite mnoho dalsich), tak tohle je standard, ne vyhoda. Stejne tak i kompilovana Scala ma REPL, take to neni vyhrada Pythonu nebo interpretovanych jazyku.

Neni to standard a naopak, ze se o to snazi i kompilovane jazyky jen dokazuje, ze to ma smysl a je to vyhodou pro kazdy jazyk, ktery to umi.

[Kit]

Nic jako privátní meto v Pythonu není.
K _ prostě přistupovat můžeš, ale pak se nediv...

Nicméně to že někdo takhle privátní metodu zprasí a spousta lidí mu ještě děkuje je nepochopitelné, prostě WTF...

V Javě se to stejně obchází přes gettery a settery, takže to vyjde nastejno. V C# na to dokonce vymysleli syntaktický cukr. Python si na privátní atributy prostě nehraje, takže ty gettery ani settery nepotřebuje.

[Citrisin]

Nic jako privátní meto v Pythonu není.
K _ prostě přistupovat můžeš, ale pak se nediv...

Nicméně to že někdo takhle privátní metodu zprasí a spousta lidí mu ještě děkuje je nepochopitelné, prostě WTF...

V Javě se to stejně obchází přes gettery a settery, takže to vyjde nastejno. V C# na to dokonce vymysleli syntaktický cukr. Python si na privátní atributy prostě nehraje, takže ty gettery ani settery nepotřebuje.

No ne že by je nepotřeboval, jako na zpracování dat před uložením se hodí (například pro kontrolu). Jinak by python nepodporoval magickou metodu __setattr__. Ale obecně si myslím, že python se svou volnější představou o OOP je na tom líp než taková Java nebo C++. Ale to je jen můj názor.

[Youda]

Nic jako privátní meto v Pythonu není.
K _ prostě přistupovat můžeš, ale pak se nediv...

Nicméně to že někdo takhle privátní metodu zprasí a spousta lidí mu ještě děkuje je nepochopitelné, prostě WTF...

V Javě se to stejně obchází přes gettery a settery, takže to vyjde nastejno. V C# na to dokonce vymysleli syntaktický cukr. Python si na privátní atributy prostě nehraje, takže ty gettery ani settery nepotřebuje.

No a kdyz v Jave _NECHCI_, aby mi nekdo hrabal do privatniho atributu, no tak zkratka pro nej getter/setter nevygeneruju.
Gettery a settery jsou v Jave nepovinne, pouzivaji se hlavne proto, ze je pak mozno na akci cteni/zapisu atributu nahookovat nejakou akci, treba debuglog.

Pokud v Jave budu treba potrebovat pri setovani atributu provest sideefect akci (napr. odeslat SNMP trap), puvodni tridu si zdedim, prepisu setter kde krome volani super() este poslu ten SNMP trap.
A protoze classes IoC injektuju Springem, injektnu zkratka moji zdedenou tridu, interface se nezmenil a okolni svet nemusi delat nic.

Pokud budes po pythonovsku setovat atribut naprimo, ceka te pri mnou popisovane uprave preveliky oser a to i pro svet okolo.

Nehlede na to, ze bez opravdu privatnich atributu a metod nejde bezpecne udelat prakticky zadny coding pattern, ani primitivni singleton ne.
Kazy jouda pouzivajici tvuj objekt ti jej muze rozbit. U toho singletonu zvlaste, kde kazdy automaticky zavola konstruktor, namisto ClassName.getInstance()

[Kit]

Nic jako privátní meto v Pythonu není.
K _ prostě přistupovat můžeš, ale pak se nediv...

Nicméně to že někdo takhle privátní metodu zprasí a spousta lidí mu ještě děkuje je nepochopitelné, prostě WTF...

V Javě se to stejně obchází přes gettery a settery, takže to vyjde nastejno. V C# na to dokonce vymysleli syntaktický cukr. Python si na privátní atributy prostě nehraje, takže ty gettery ani settery nepotřebuje.

No ne že by je nepotřeboval, jako na zpracování dat před uložením se hodí (například pro kontrolu). Jinak by python nepodporoval magickou metodu __setattr__. Ale obecně si myslím, že python se svou volnější představou o OOP je na tom líp než taková Java nebo C++. Ale to je jen můj názor.

V Pythonu se __setattr__ používá spíš k přetěžování operátoru přiřazení. Tedy nikoli k omezení, ale k rozšíření funkcionality objektu.

[ROFL]

V Javě se to stejně obchází přes gettery a settery, takže to vyjde nastejno.

Tady nejde o nějaké obcházení. Díky getterům a setterům má právě programátor věci plně pod kontrolou. Jde o úmyslné poskytnutí částečného a kontrolovaného(to je celkem důležité slovo) přístupu k určitým datům. Smyslem zapouzdření není neměnitelný objekt, do kterého se akorát všechno na začátku nasype konstruktorem. Osobně s volností Pythonu problém nemám, ale argument, že "to vyjde nastejno", je zase mimo.

[Kit]

Nic jako privátní meto v Pythonu není.
K _ prostě přistupovat můžeš, ale pak se nediv...

Nicméně to že někdo takhle privátní metodu zprasí a spousta lidí mu ještě děkuje je nepochopitelné, prostě WTF...

V Javě se to stejně obchází přes gettery a settery, takže to vyjde nastejno. V C# na to dokonce vymysleli syntaktický cukr. Python si na privátní atributy prostě nehraje, takže ty gettery ani settery nepotřebuje.

No a kdyz v Jave _NECHCI_, aby mi nekdo hrabal do privatniho atributu, no tak zkratka pro nej getter/setter nevygeneruju.
Gettery a settery jsou v Jave nepovinne, pouzivaji se hlavne proto, ze je pak mozno na akci cteni/zapisu atributu nahookovat nejakou akci, treba debuglog.

Pokud v Jave budu treba potrebovat pri setovani atributu provest sideefect akci (napr. odeslat SNMP trap), puvodni tridu si zdedim, prepisu setter kde krome volani super() este poslu ten SNMP trap.
A protoze classes IoC injektuju Springem, injektnu zkratka moji zdedenou tridu, interface se nezmenil a okolni svet nemusi delat nic.

Pokud budes po pythonovsku setovat atribut naprimo, ceka te pri mnou popisovane uprave preveliky oser a to i pro svet okolo.

Nehlede na to, ze bez opravdu privatnich atributu a metod nejde bezpecne udelat prakticky zadny coding pattern, ani primitivni singleton ne.
Kazy jouda pouzivajici tvuj objekt ti jej muze rozbit. U toho singletonu zvlaste, kde kazdy automaticky zavola konstruktor, namisto ClassName.getInstance()

V Javě tyhlety gettery ani settery nepoužívám, protože je k ničemu nepotřebuji. Na privátní atributy objektu mi tak nikdo hrabat nebude. Případný debuglog injektuji do konstruktoru.

Singleton je antipatternem, který má své účelné použití například u vzoru NullObject. Jinak je vcelku bezvýznamný.

[Citrisin]

V Pythonu se __setattr__ používá spíš k přetěžování operátoru přiřazení. Tedy nikoli k omezení, ale k rozšíření funkcionality objektu.

Ano to je pravda, viz. Django. Špatně jsem se vyjádřil.

Kazy jouda pouzivajici tvuj objekt ti jej muze rozbit. U toho singletonu zvlaste, kde kazdy automaticky zavola konstruktor, namisto ClassName.getInstance()

Upřímně, můj názor je že chránit se takto před něčím, co kdyby je, zbytečné. Každý programátor by měl psát dokumentaci a každý programátor by ji měl číst. Nedej bože by měl dodržova i standard daného jazyka. Kdo to nedělá tak není programátor a sebelepší programovací jazyk ho nezachrání. Když ho rozbije je to jeho chyba, jemu ten program nebude fungovat. A upřímě není zase až tak těžké pochopit, že to co se jmenuje __*__ na to se z vnějšku nesaha. Pak není těžké vytvořit ani Java-like getry a setry., nikdo ti v tom nebrání. Nevim na co, ale tady je ukázka.

Kód: [Vybrat]

class foo:
  def __init__(self):
    self.__fo__ = true
  def set_fo(self, val):
    self.__fo__ = val
  def get_fo(self,val):
    return self.__fo__Myslím že volnost je ta hlavní vlastnost, nikdo tě nenutí dodržovat OOP přesně do puntíku. Naproti tomu v Java nutí programátora do OOP a programátoři to pak prostě různě obcházejí. Python tě to prostě nechá udělat. V Pythonu můžeš napsat kód který nemá jedinou classu a bude fungovat, tady to máš Javo.

[Kit]

Myslím že volnost je ta hlavní vlastnost, nikdo tě nenutí dodržovat OOP přesně do puntíku. Naproti tomu v Java nutí programátora do OOP a programátoři to pak prostě různě obcházejí.

Java na jedné straně nutí do OOP, na druhé straně to programátoři obchází přes gettery a settery. A ještě se tím chlubí.