Komentáře k článku

Python profesionálně: úvod

Python logo

Programovací jazyk Python přispívá k rychlému vývoji. Dovolí nám nesoustředit se na technické detaily a nechává nám více prostoru na skutečné řešení problému. Python se sice snaží být intuitivní, ale obsahuje věci, které nejsou všední, a příliš se o nich neví. Tímto dnes začínajícím seriálem vám chci Python více přiblížit a odkrýt vám jeho krásu.

Zpět na článek

85 komentářů k článku Python profesionálně: úvod:

  1. Jirka Vejražka

    Hezke, ale PEP8?

    Diky, clanek je opravdu zajimavy a tesim se na pokracovani. Mel bych ale prosbu – bylo by ve „vyukovych“ clancich mozne alespon priblizne dodrzovat zavedene standardy a konvence pro jmena funkci a promennych? V pythonu ze jmen typu „isCarWhichILo­okingFor“ nebo „listOfCars“ docela boli oci, tohle neni JavaScript ;-)

    Diky!

    1. Solitary

      Re: Hezke, ale PEP8?

      Nejsem Pythonista, proto se ptam… jake konvence jsou tedy ty spravne v Pythonu? Trosku mi prijde, ze spravna konvence je takova, ktera je pochopitelna na prvni pohled… ne takova, jakou diktuje jazyk. A tyhle Java(scriptove) nazvy jsou mnohdy dost vystizne.

        1. Jirka V.

          Re: Hezke, ale PEP8?

          Jak jsem to odeslal tak mě ještě napadlo… Ono to může vypadat jako zbytečná rýpačka = nemá co by zkritizoval tak se vozí po konvencích. Jenže Python je na konvencích postavený. Lecjaká důležitá konstrukce jako self u objektů, nebo _protected __private jsou taky jen konvence.

          Python nikoho nenutí je dodržet, akorát o pak po vás nikdo nepřečte, a proto je v zájmu programátora samotného se jich držet. Konec konců samotný článek tím začíná, i v Pythonu se dá kód pěkně zprasit, stejně tak si ale můžete koupit novou LED telku a hodit jí z Nuseláku. Je to vaše volba.

            1. Jirka V.

              Re: Hezke, ale PEP8?

              Ja myslím, že to konvence v jistém smyslu slova přece jen je. Rozhodně ta proměnná či metoda není private ve smyslu jak to má Java.

              I k metodě označné jako __private se dá celkem snadno dostat. Takže je to opět jen konvence, kterou ale respektuje i samotný interpret Pythonu a zabrání zavolání té metody přímo (AttributeError).

              Jenže stačí to volání jen lehce upravit a…

              Class Pokus(object):
                 def __init__(self):
                      self.__foo = 'neco desne duleziteho'
              
              test = Pokus()
              
              print test.__foo # vyhodi AttributeError, ale
              print test._Pokus__foo # vypise 'neco desne duleziteho'
              1. Inkvizitor

                Re: Hezke, ale PEP8?

                Od té doby, co v Javě zavedli Reflection, už to s tou ochranou také není, co to bývalo. Jinak bych řekl, že ta ochrana je v OOP obecně zamýšlena spíš jako konvence.

            2. PMD

              Re: Hezke, ale PEP8?

              No, v pravém smyslu konvence to není, ale k přístupu k __private přes _MyClass__private vám stejně nic nebrání:)

        2. ByCzech

          Re: Hezke, ale PEP8?

          Pylint má pro mě příliš false-positives keců, takže bych se jím do latě moc stavět nenechal…

            1. ByCzech

              Re: Hezke, ale PEP8?

              To že mu zakážu upozorňovat na chyby, když je to jeho primární funkce, jen proto, že upozorňuje na chybu, tam kde chyba prokazatelně není, neříkám umravnění, ale vypnutí primární funkce. Řešení je chybu v takovém detekčním softu opravit a ne detekce vypnout, jinak ho nemá moc cenu používat.

              1. Jirka Vejražka

                Re: Hezke, ale PEP8?

                Kdyz se mi z nejakeho duvodu nelibi jedno z 30 typu varovani, muzu ho „utlumit“. To jeste neznamena, ze dalsich 29 typu varovani je zbytecnych…

    2. petr

      Re: Hezke, ale PEP8?

      V Pythonu píšu několik let skoro na plný úvazek. Myslím že PEP8 je naprosto zbytečná hovadina, která se snaží jako součást komunity vynutit něco, co je individuální. Zrovna mě PEP8 vůbec nesedí (skoro v ničem: píšu tab místo mezer (zobrazený na 3 místa), zásadně nezačínám řádku, pokud nenásleduje odsazený blok, používám camelCase na proměnné místo _, které jsou delší, atd) a nevím, jak to souvisí s programováním. Přijde mi to, jako byste chtěl, abych při psaní měl na hlavě kulicha nebo něco podobného.

        1. nakrev

          Re: Hezke, ale PEP8?

          Ja treba nemam problem se ctenim kodu ciziho cloveka. Staci mi, aby nepsal jako prase. Nemusi dodrzovat zadnou konvenci. Je mi jedno jestli pise camelCase, nebo podtrzitka, jestli dela mezery mezi }{()= , Jestli odsazuje 2,4,8 mezer. Dulezity pro me je, aby se toho stylu drzel a „nepreskakoval“.

          Pokud na projektu dela vic lidi, tak bude urcite potreba dohodnout nejaky code style. Jestli to ale bude PEP8 nebo #endif to uz je na rozhodnuti/dohode.

          V opacnem pripade pouziju vlastni hlavu. Pokud bude neco v ni, lide okolo budou stastni a usmevavi i bez PEPy.

          To je muj nazor na tento obraz.

          (Autor preferuje camelCase metody u pythonu a je mu jedno, ze z toho nekdo jinej jde do vrtule.)

      1. Jiří Vraný

        Re: Hezke, ale PEP8?

        To je celkem legitimní názor. Pokud píše člověk pro sebe, klidně si to může psát v palindromickém haiku v mandarýnském dialektu.

        Nicméně, pokud to má číst někdo další, nebo co víc, se podle toho učit programovat v daném jazyce, tak je lepší držet se konvencí platných pro daný jazyk. A že je má Python jiné než Java? To má i spoustu dalších věci…

        1. ByCzech

          Re: Hezke, ale PEP8?

          To přirovnání k haiku v mandarýnském dialektu dost pokulhává, protože pro koho je nečitelná proměnná „TotoJeVystup­ZmehoObjektu“ místo „toto_je_vystup_z_me­ho_objektu“ nemá vůbec na to číst a pochopit algoritmy a další věci v takovém zdrojáku.

          Ale to je jen můj subjektivní názor, protože číst takové základní věci mi nedělá potíž v žádném jazyce, se kterým jsem se setkal…

          1. Jirka Vraný

            Re: Hezke, ale PEP8?

            Haiku nesmíte brát tak doslova. To byl pokus o vtip :) Celkem vzato si nemyslím, že je potřeba dělat z toho téma roku. Najdou se i velké Python projekty, které camelCase používají, například PySide (PyQT). Má to tam svůj důvod – aby API bylo stejné jako v C++. Nicméně si stojím za tím, že výukové články o Pythonu by PEP8 ctít měli a jsem rád, že to autor článku tady v komentářích sám uznává.

    3. Kenny

      Re: Hezke, ale PEP8?

      Díky pěkný článek!

      CamelCase je hodně používané a rozhodně ne nepřehledné ;) S javascriptem jako takovým už nemá vůbec nic společného. Je to asi spíš o tom na co je člověk zvyklí nebo o tom jakou máš nastavenou štábní kulturu v teamu.

      Když se podíváš na dokumentaci pythonu ( http://docs.python.org/tutorial/classes.html#a-word-about-names-and-objects ) tak uvidíš že borci taky používají CamelCase ( class MyClass ).

      Takže jestli tě z toho bolí oči tak jenom proto že jsi zvyklí na_něco_jiného_;)

      1. Jirka Vejražka

        Re: Hezke, ale PEP8?

        Ono to mozna bude tim, ze pro class je CamelCase doporuceno, zatimco pro funkce a promenne ne :)

  2. Piitak

    Chybka

    Predpokladam, ze v nasledujicim prikladu doslo k prohozeni radku:

    obj = None
    for item in listOfCars:
        if item.isCarWhichILookingFor():
            obj.unlockTrunk()
            obj = item
            break
  3. had

    python verze

    Myslím, že by nebylo na škodu, kdyby čtenář věděl o verzi Pythonu, pro kterou jsou příklady napsány.

    1. Michal HořejšekAutor příspěvku

      Re: python verze

      Všechny ukázky plně fungují pro Python druhé řady. Úpravy pro Python 3 jsou minimální, takže se o nich ani nezmiňuji. Pokud však existuje v Pythonu 3 něco navíc nebo tam je nějaká změna, tak se o tom zmíním, viz dnešní ukázka one, two, three, *fourfivesix = range(1, 7).

    2. daks

      Re: python verze

      Taky se přimlouvám, já chápu článek jako popis toho, co je v Pythonu novýho od verze 3. Ono to z článku v podstatě vyplyne, ale hodilo by se to napsat někde v úvodu.

  4. Lada

    Pěkné čtení

    Děkuji za zajímavé a poutavé informace. Člověk se učí pořád. Díky a těším se na pokračování.

  5. emko

    +1 ...

    Díky za zajímavý článek. Sice jsem primárně (= v práci) .Neťák, ale i tak se hodí. Těším se na pokračování.

  6. zeitung

    f*ck

    prestal jsem cist po hlasce „V dnešní době však není podstatné mít efektivitu neustále na paměti.“

    1. Lada

      Re: f*ck

      Ano, v jazyku C nebo assembleru máte vše v rukách, včetně režie paměti. Ale třeba vypsat výskyt všech slov ze souboru není tak jednoduché jako použit např. kód:

      import re
      m = re.compile('(w+)')
      slova = set()
      for radek in open('soubor'):
        slova.update(m.findall(radek))
      print slova
      
  7. Ales Zoulek

    prosim, ucte (se) python s pep8!

    Opravdu bych byl rad, kdyby autor v prikladech kodu dodrzoval pep8 a tedy psal jmena metod a funkci podtrzitkovou­_notaci. Zvlast pokud ma ambici ukazovat, jak v Pythonu psat *profesionalne*.

    Nejde o zadne bezucelne rypani. Naopak, Python si zaklada na dodrzovani urcitych konvenci a nedodrzovani spravneho pojmenovavani je minimalne stejne nevhodne jako psani dlouhych necitelnych onelineru, ktere autor sam (opravnene) kritizuje.

    A koneckoncu osvojeni pep8 je schopnost, ktera se v profesionalnim python vyvoji hodi mnohem casteji jak znalost else bloku ve while cyklu.

    1. ornyx

      Re: prosim, ucte (se) python s pep8!

      Konvence jsou prima vec, ale ja napriklad pri psani veci v Pythonu pouzivam zasadne javovskou (a vsude jinde pouzivanou) camel case konvenci (tohleJeJmeno­Funkce, JmenoTridy), protoze Python neni muj jediny nastroj (js, as3 a dalsi) a me treba podrzitkova konvence pride priserna, ale k cecku (ze ktereho asi pochazi) jsem pricichl jen letmo…

      1. Neseznamak

        Re: prosim, ucte (se) python s pep8!

        Ano, ani Python neni muj jediny nastroj, ale respektuji konvence jazyka/prostredi, ve kterem delam.

        Opacny pristup znemena, ze jsem tam vetrelcem.

        Mimochodem, javovskou (***a vsude jinde pouzivanou***) svedci pouze o tom, jaka je vase definice slova vsude.

      2. https://profiles.google.com/118074983456106867579

        Re: prosim, ucte (se) python s pep8!

        Klidne pouzivejte zasadne Javovskou konvenci vsude. Problem je v okamziku, kdyz bude clanek „Java profesionalne“ pouzivat coding style ala Cecko, Perl, nebo cokoliv co jde proti tomu, co se v Jave povazuje za spravne…

      3. Rax

        Re: prosim, ucte (se) python s pep8!

        Za camel case normálně sekám ruce, tedy není pravda že je to všude jinde používané :-) To proto, že rozlišovat identifikátory pouze na základě velikosti písmen je zaručená cesta do záhuby a zdroj zcela zbytečných chyb.

        1. emko

          Re: prosim, ucte (se) python s pep8!

          Vyjma Clojure (tam-se-identifikátory-píší-s-pomlčkami) jsem se snad nikde nesetkal s tím, že by se camelCase nepropagovala. Asi to záleží na tom, v jakých oblastech se člověk pohybuje ;-)

        2. Riff

          Re: prosim, ucte (se) python s pep8!

          Díky za osvícení. Doteď jsem napsal kilometry kódu s camel-case konvencí a až díky vám jsem si uvědomil, že se v těch kódech vlastně nevyznám a všichni kdo je upravují taky ne. Ještě jednou moc díky, jdu to všechno zrefaktorovat.

        3. Inkvizitor

          Re: prosim, ucte (se) python s pep8!

          V projektech, které jsem v Pythonu (v týmu) páchal, jsou stovky tisíc řádků a NIKDY tam nebyl problém ve špatné velikosti písmen. Camel case je naprosto rovnocenné podtržítkové notaci ve všech směrech.

  8. MilanK

    Jak zjednodušit tento cyklus

    Občas se mi stane, že dospěju k následující konstrukci:

    d = nacti_polozku()
    while polozka_je_platna(d):
        zpracuj_polozku(d)
        d = nacti_polozku()

    v C jde zkombinovat ten test platnosti a nacteni do jednoho:

    while ((d = nactipolozku())
        zpracuj_polozku(d);

    Nejde to zapsat v Pythonu take nejak jednodusseji, aby se to cteni nemuselo zapisovat dvakrat? (V uvedenem prikladu mam na to funkci nacti_polozku, ale obcas je to treba jen slozitejsi vyraz, kvuli kteremu nenadefinuji dalsi funkci, ale proste ho tam dvakrat opisu). Napada mne jedine nasledujici, ale to je neprehledne:

    while True:
        d = nacti_polozku()
        if not polozka_je_platna(d): break
        zpracuj_polozku()
      1. Havri

        Re: Jak zjednodušit tento cyklus

        Myslím to takto:

        for d in iter(nacti_polozku, None):
            zpracuj(d)

        Jediným předpokladem je, že funkce nacti_polozku musí, pokud už dojde „na konec”, vrátit None (nebo jinou zvolenou hodnotu).

    1. Neseznamak

      Re: Jak zjednodušit tento cyklus

      Jedniduchost a citelnost, zalezi co si clovek vybere ,)

      Nevim co presne znamena polozka_je_platna, protoze v tom Ccku tak nejak neni. Jestli to jenom znamena ze uz se nevratilo nic, tak staci

      map(zpracuj_polozku, iter(nacti_polozku))

      Pro hodne funkci to pujde i bez toho iter.

      1. Havri

        Re: Jak zjednodušit tento cyklus

        Jen bacha na to, že v Pythonu 3 vrací map iterátor, takže kód se neprovede okamžitě. Pokud to dále nezpracuji, nic se vlastně neprovede.

        1. MilanK

          Re: Jak zjednodušit tento cyklus

          Děkuju za návrhy, například o druhé formě iter() se dvěma argumenty jsem vůbec nevěděl. Obecně je asi řešením mého dotazu nějaká forma iterátoru, ať už přes iter() nebo podpora iter protokolu v používaném objektu. Vlastně to popisují na tom http://docs.python.org/faq/design.html#why-can-t-i-use-an-assignment-in-an-expression.

          A to, že map() vyrábí konečně iterátor (nesouvisí vůbec s mým dotazem), mě snad přiměje začít používat Python 3 :-)

  9. ByCzech

    Ternární operátor

    Já jako ternární operátor používám (a nejen já) obvykle konstrukci:

    (výraz1, výraz2)[podmínka]

    Trik v článku je pro mě novinka…

    1. Havri

      Re: Ternární operátor

      V článku zmíněné konstrukce (přes andy a ory a if else) běžně vídám, ale tohle vidím fakt poprvé. Připomíná mi to konstrukci

      cena = '100'
      mena = 'Kc'
      ukazMenu = True
      
      cena += mena * ukazMenu

      Ve smyslu

      if ukazMenu:
          cena += mena
    2. Michal HořejšekAutor příspěvku

      Re: Ternární operátor

      I tento trik znám a v práci ho stále na několika místech máme. Do článku jsem ho nezahrnul, protože bych se mu raději (kvůli čitelnosti) vyhýbal. Ale nezapomněl jsem na něj a alespoň odkázal v závěru článku.

      1. ByCzech

        Re: Ternární operátor

        Mi to nečitelné nepřijde, asi je to subjektivní záležitost a zvyk. V céčku je to:
        Podmínka ? VýrazKdyžPravda : VýrazKdyžNepravda
        V Pythonu je to přesně pozpátku v tomto triku, to je jediná věc, kterou jsem si musel zapamatovat.
        Víc lidí, víc chutí…
        Každopádně díky za článek.

    3. Raskal

      Re: Ternární operátor

      Pozor na specificka chovani vyhodnoceni ternarniho operatovu v kontrukci and-or:

      In [719]: def a(x):
      …..: print x
      …..: return x
      …..:

      In [720]: (a(1), a(2))[1>2]
      1
      2
      Out[720]: 1

      In [721]: 1>2 and a(1) or a(2)
      2
      Out[721]: 2

      Osobne pouzivam tvary (<podm> and <then> or <else>) resp. (not <podm> and <else> or <then>) v pripade, kdy bool(<else>) == False a zaroven bool(<then>) == True. Dalsim duvodem je zbytecna konstrukce pametove struktury tuple.

      Nejlepsi je nasledujici zpusob (ostatni jsou zrejme hacky; ja osobne velmi preferuji podminku na zacatku vyrazu a ne nekde uprostred):

      In [722]: a(1) if 1>2 else a(2)
      2
      Out[722]: 2

      In [723]: a(1) if 1<2 else a(2)
      1
      Out[723]: 1

    4. blizz

      Re: Ternární operátor

      to vpodstate ani neni trik, if then else je proste normálny výraz, preto v nom ternarny operator nema zmysel… neviem ako v pythone ale vo funkcionálnych jazykoch je vsetko výraz.

  10. zzzzzzzzz

    Nemuzu si pomoct...

    …python a profesional v jedne vete mi prijde usmevne :-D
    Python na rychle prototypovani, rychlou vypomoc s jednorazovym problemem nebo podobne – Ano
    Python na aplikace ktere budou cteny vic lidmi vic nez jednou, a ktere nejsou trivialni rozhodne NE

    Denne vidim problemy zpusobene chybami ktere se projevi az pri behu, ruzne formatovani ruznych lidi atd… peklo.

    Na druhou stranu, je dobre ze lidi se uci dalsi jazyk, takze v serialu jen dal…

    1. Neseznamak

      Re: Nemuzu si pomoct...

      „ruzne formatovani ruznych lidi“

      Tyjo, tak zrovna z jazyku co znam mi tohle prislo v Pythonu jako nejmensi problem, at uz to porovnam prakticky s cimkoli co me napada.

      Ktere jazyky to maji vyresene lip?

    2. Raskal

      Re: Nemuzu si pomoct...

      S kazdym „parametrem“ jazyka se musis nejak vyrovnat. Ani silne typovany jazyk se vsema moznyma kontrolama pri prekladu te pred runtime chybou nezachrani. Python poskytuje daleko mensi pocet radku kodu o stejne funkcnosti a maximalni svobodu manipulace s prostredim. Kdyz vis jak ho pouzivat a nezastavas dosavadni nazor, tak na tom muzes vydelat. Tim nerikam nic o nazorech zakaznika. Python neni pro kazdeho a nekdo ma ve svem kodu rad 50% vaty jednovyrazovych metod urcenych k uspokojeni kompilatoru napriklad ruznymi fasadami pro preskladani parametru a jejich default hodnot. Ja ne a tak rad pouzivam Python.

      1. Radek Miček

        Re: Nemuzu si pomoct...

        Ani silne typovany jazyk se vsema moznyma kontrolama pri prekladu te pred runtime chybou nezachrani.

        Některé jazyky ano.

        Python poskytuje daleko mensi pocet radku kodu o stejne funkcnosti

        Myslím, že program v Haskellu může být kratší než program v Pythonu,
        a to při zachování funkčnosti.

        1. Raskal

          Re: Nemuzu si pomoct...

          [Některé jazyky ano.]

          Zadne. (Neobskurdni standardne pouzivane programovaci jazyky.)

          [Myslím, že program v Haskellu může být kratší než program v Pythonu,
          a to při zachování funkčnosti.]

          Neni treba chodit az k Haskelu. Perl to zvlada taky napriklad diky automatickemu vytvareni datovych struktur. Plati se za to zase treba prehlednosti a srozumitelnosti kodu. Nerikam, ze je na tom Python s delku kodu nejlepe, neni. Zato je to skriptovaci jazyk s vykonnosti blizici se napriklad kompilovane Jave (pypy – JIT, RPython a moznost kompilace, …) a pritom neni v kodu potreba definovat v podstate nic, co definovat nechci.

          1. Radek Miček

            Re: Nemuzu si pomoct...

            Perl to zvlada taky napriklad diky automatickemu vytvareni datovych struktur.

            Jenže tyto tzv. dynamicky typované jazyky mají velmi slabý typový systém, který vám s korektností programu nijak nepomůže. Haskell jsem uvedl právě kvůli jeho silnému typovému systému.

            1. Raskal

              Re: Nemuzu si pomoct...

              […s korektností programu nijak nepomůže…]

              Je otazka, zda s tim ma a muze pomoci (duck typing). Nutnost svazovani trid pres interface jen proto, abych s nimi mohl dale pracovat na abstraktnejsi urovni, to mi prijde dost draha vlastnost predevsim v ranne fazi vyvoje. Pokud tyto dodatecne informace nemusim (mohu, ale nemusim) specifikovat, mohu se vice zamerit na vlastni reseny problem. Dalsi upresnovani informaci v kodu znamena dodatecnou davku informaci, kterou je nutne dale udrzovat s hlavnimi zmenami. Tuto praci za mne muze udelat stroj.

              […jsem uvedl právě kvůli jeho silnému typovému systému.]

              Rozumim.

  11. Honza Kral

    Python profesionalne

    Uz ponekolikate prosim autora pod jeho clankem aby respektoval jazyk ve kterem
    pise. Drive jsme se jeste mohli hadat zda to je dulezite kdyz clanek mel udajne
    byt o hezkem kodu obecne a Python byl jen pro ilustraci; to uz ale tentokrat
    jasne neplati.

    Kod v clanku opet obsahuje zakladni chyby proti stylu (pep-8) a bezpecnosti
    (osetrovani chyb) ktere rozhodne nejsou nad ramec tech par radku ktere se nam
    snazi autor ukazat.

    Zacatecnikum by mozna mohlo vice pomoct informace o tom jake ma Python datove
    struktury, jak pracuje s promennymi, jaky je rozdil mezi == a is nebo proc je
    dulezite vedet jaka datova struktura je immutable. Vedet ze cyklus v pythonu
    muze mit blok else je sice cool, ale v realnem svete profesionalniho
    programovani to zas tak relevantni neni a uz vubec ne neco co by patrilo do
    oblasti znalosti kterou musi kazdy programator znat.

    Abych jen nekritizoval tak rad nabidnu sve sluzby pokud bude autor chtit
    zkonzultovat kod ci clanek jeste pred vydanim. Myslim si ze Python je skvely
    jazyk ktery se hodne rozmaha a ktery ma siroke uplatneni od drobneho
    skriptovani, pres webove aplikace az po implementaci rozsahlych systemu, byla
    by skoda kdyby si nekdo delal obrazek o Pythonu a programovanim v nem na
    zaklade clanku ktere neodpovidaji realite.

    1. Martin Hassman

      Re: Python profesionalne

      Honzo, pokud bude Michal souhlasit, klidně ti další díly pošlu předem k nahlédnutí.

    2. emko

      Re: Python profesionalne

      Hm, ono tento článek asi není pro začátečníky.

      Upřímně, já osobně python používám minimálně, převážně na jednorázové věci (= napsat a zahodit; tedy přesně pro ten případ, kdy „command line Jedi“ použije gerp, awk a sed) a jen tam, kde je nainstalovaný (jinak mám smůlu a musím použít Brainfu… pardon, Perl). Myslím, že takových jako já, je mezi uživateli Pythonu hodně. A předpokládám, že i mezi čtenáři tohoto článku.

      Je mi celkem jedno, jestli autor dodržuje best practices nebo ne. To patří do produkčního kódu, ale bylo by celkem zbytečné u pár ukázkových řádků. Podle vyznění je článek zaměřen na pokročilejší uživatele, kteří chtějí na první pohled vidět, co chtěl autor říci. Ne na začátečníky, kterým je potřeba vštěpovat základní pravidla.

    3. Michal HořejšekAutor příspěvku

      Re: Python profesionalne

      Díky za komentář. S PEP8 souhlasím, resp. v článku jsem měl na něj brát ohled, aby si to někdo neosvojil a neříkal tomu Python konvence. V pokračování už bude kód vyhovovat PEP8.

      Jinak seriál není zaměřen na datové struktury, rozdíl mezi == a is atd., jak uvádíš (můžeme si tykat?). Takovéhle věci si může každý přečíst v různých příručkách, kterých je dostatek. Já jsem se zaměřil na to, o čem se málo ví, protože to v jiných jazycích není zvykem. O tom, co je zajímavé a zlepšuje vývoj.

      Pokud jsem špatně zvolil úvod a očekával jsi něco jiného, tak se opravdu omlouvám. Každopádně tohle byl takový jednoduchý úvod a každý další díl se posune o stupínek dál.

      1. Honza Kral

        Re: Python profesionalne

        Ahoj, tykat si urcite muzem ;)

        v tom pripade se tesim na dalsi dily. Moje nabidka stale trva, ja bych rad videl neco na tema implementace zakladnich datovych struktur, dekoratoru, deskriptoru a metaclass. V techto tematech panuje spousta mytu a dogmat ktere neodpovidaji realite a pritom se jedna prave o nekolik malo mist jejichz pochopeni otevre cloveku uplne cely Python a nic ho v tom jazyce uz dal neprekvapi.

        Pokud by se melo jednat o prakticke rady ktere clovek muze pouzit a mene o teoreticke znalosti, rozhodne bych doporucil pruchod knihovnami itertools a collections kde jsou perly ktere uz jsem mnohokrat videl naimplementovane v kodu zcela zbytecne prave proto ze si lidi nejsou vedomi toho ze tuto praci za ne jiz odvedl nekdo mnohem chytrejsi :)

        1. Michal HořejšekAutor příspěvku

          Re: Python profesionalne

          S Martinem jsem se dohodl, že Ti na ukázku pošle další díl a můžeš k tomu případně něco říct. Pokud zatím neposlal, určitě pošle.

          Například dekorátory a metatřídy se v seriálu objeví. Nevěděl jsem, na koho se hlavně zaměřit, takže jsem to napsal delší a pro všechny, aby si každý z toho něco odnesl. Začátek je proto takový, jaký vidíš, a postupně budou témata složitější.

  12. Amatér

    Zbytočná kópia

    Toto je hodne, hmm, blbý spôsob:


    for item in listOfCars[::-1]:
    # Do something...

    Tento kód najprv zbytočne celý zoznam otočí do dočasnej kópie, ktorú po skončení cyklu zahodí.

  13. BS-Harou

    PEP-8

    A já jako javascriptař jsem třeba rád, že článek dodržuje JS konvence místo nějakýho pep8 :) Pro mě osobně je to tak daleko čitelnější….

    1. PMD

      Re: PEP-8

      A vlastně taky dodržuje Java konvence, takže dotneťák by měl být po právu dotčen, že to nejde číst, protože metody nemají první písmeno velký:)

  14. hejhula

    "Profesionálně"? Nesouhlasím.

    Posledních 7 let se živím výhradně programováním SW v pythonu (s vyjímkou pár desítek kilobajtů .sh a .sql) a článek je podle mne špatný, nebo alespoň špatně pojmenovaný.
    Měl by se jmenovat spíše tipy a triky v pythonu a mělo by být dodané varování, ať se jim v profesionální praxi vyhýbáte!

    Protože poté, co s vaším nepřehledným kódem zacvičí vaši kolegové, kteří ho budou chtít v časovém stresu změnit, se vzteky po*erete.

    Pro týmovou práci v byznysu, kde nevíte, jakého matláka vám manažer přiřadí jako kolegu na projekt, JE KLÍČOVÉ PSÁT STUPIDNĚ JEDNODUCHÝ KÓD, je-li to vůbec možné.

    Třeba ternární operátory jsou na hraně a často nestojí za ušetřené 2-3 řádky. A vůbec snad všechny triky, jak výraz zkomplikovat na méně řádků, jsou ŠPATNĚ. Váš nečitelný kód nebude upravován, ale bude v určitých situacích „oběhnut ifem“ nebo reimplementován, s příslušnými dopady na rychlost a spravovatelnost programu.

    Prasit tak, jak to bylo ukázané v článku, můžete i v byznysu. Ale neříkejte tomu profesionalita. Tak si můžete dovolit psát nedůležité části prototypu.

    1. Raskal

      Re: "Profesionálně"? Nesouhlasím.

      Ctivost a srozumitelnost produktu je prvni v rade. Z tohoto duvodu je potreba, aby samotny kod mel sam o sobe optimalni vypovidajici hodnotu (samodokumentujici nazvy promennych, funkci a trid, proste vseho krome klicovych slov, kde si sam volim nazev) o tom, jak byla jeho funkce zamyslena. Zbytek je treba davat do dokumentacnich retezcu a do jednoradkovych komentaru tam, kde se provadi jakasi celistva operace (mentalne celistva).

      Shodou okolnosti me Python take zivi cca 7 let a dodrzovani techto konvenci mi uz mnohokrat pomohlo od opakovani vlastnich chyb. Dokonce si v kodu nechavam zakomentovana zaludna zdanlive spravna reseni situace, abych vedel, ze jsem tuto chybu jiz jednou udelal, doplatil na to a neopakoval se. Pokud bude program takto dobre napsan, muzete si v nem dovolit i pokrocile vyjadrovani.

      Ternarni vyraz je nebo bude krome poskytnute moznosti vyjadreni take vniman JITem jako moznost k optimalizaci.

      Kolega znaly analyzy problemu, ktery neni schopen pojmout v souladu s analyzou projektu dobre napsany a komentovany kod, je pro mne bud liny ho pri cteni vnimat nebo je jednoduse neschopny a oboji znamena, ze neodvadi kvalitni praci. Problem nastava tam, kde nema kod dostecne vypovidajici schopnost na sebe prozradit co ma ktera pasaz delat. Takoveho kodu je dnes vetsina a pri stresujicich situacich je pak mene narocne jej obejit nez resit rebusy na ktere neni prave ted cas.

      Python, ackoliv smeruje k jednoduchosti, poskytuje velmi pokrocile moznosti programovani. Pokrocilym programovanim nemyslim programovani jen pro zapis (cili „fuj, tohle se fakt neda cist“). Myslim tim napriklad pouziti metatrid, generatoru a uzaveru, kde si kolega neznaly ternarniho operatoru zrejme neskrtne. Pouzivat se maji tam, kde je to vhodne pouzit, tedy vetsinou na core casti a stale pamatovat na to, ze vhodne neznamena vzdy nutne. Zaroven maji mit tyto core casti jasne hranice a byt male, aby se pripadne nedodelky a nejasnosti nesirily dal pres lidi v tymu a jejich odpovednosti.

      1. Klerik

        Re: "Profesionálně"? Nesouhlasím.

        dobrý den, můžete mi napsat na mail klerik_na_klerik.cz ? Mel bych par dotazu ohledne profi pyhonu, diky.

    2. Klerik

      Re: "Profesionálně"? Nesouhlasím.

      Dobrý den hejhulo :), mohl byste mi napsat na mail klerik_na_klerik.cz … mel bych par dotazu ohledně profi pythonu. Díky.

Napsat komentář

Přihlásit se

Tato diskuse je již příliš stará, pravděpodobně již vám nikdo neodpoví. Pokud se chcete na něco zeptat, použijte diskusní server Devel.cz

Zdroj: http://www.zdrojak.cz/?p=3622