Vývoj Pythonu bude přenesen na GitHub

Vývoj programovacího jazyka Python, přesněji řečeno jeho referenční platformy a nejrozšířenější implementace CPython, doteď probíhal na vlastních serverech s využitím SCM Mercurial. Na Nový rok bylo v diskusním listu core-workflow oznámeno, že vývoj Pythonu bude přenesen na GitHub. Více v PEP 0481.

4.1.2016 00:01 | Ladislav Hagara | Komunita

Komentáře

[AAnarchYsta]

Ten GitHub začína mať nejaký monopol... Je to zlé či dobré? :D

[gsnak]

Kedysi mal monopol sourceforge, teraz pridava do instalacnych suborov malware. Uvidime...

[mirec]

Zatiaľ dobré, kým to nezačne zneužívať. Na spoluprácu je to prakticky ideálna platforma a hlavne nie je to žiadne zaprdené SVN.

[Jendа]

No vzhledem k tomu, že mají v podmínkách, že se za ně budeš soudit v nějaké řiti na základě podivných zákonů jako SOPA, DMCA a praštěného patentového práva, tak špatné.

You shall defend GitHub against any claim, demand, suit or proceeding made or brought against GitHub by a third-party alleging that Your Content, or Your use of the Service in violation of this Agreement, infringes or misappropriates the intellectual property rights of a third-party or violates applicable law, and shall indemnify GitHub for any damages finally awarded against, and for reasonable attorney’s fees incurred by, GitHub in connection with any such claim, demand, suit or proceeding; provided, that GitHub (a) promptly gives You written notice of the claim, demand, suit or proceeding; (b) gives You sole control of the defense and settlement of the claim, demand, suit or proceeding (provided that You may not settle any claim, demand, suit or proceeding unless the settlement unconditionally releases GitHub of all liability); and (c) provides to You all reasonable assistance, at Your expense.

You agree that these Terms of Service and Your use of the Service are governed under California law.

[Tomas]

Coz ale neni nic proti nicemu. Pokud te pravnicine rozumim, tak se jedna o to, ze jen prebiras odpovednost za svuj kod a v pripade, ze nekdo uplatni nejaky ten patent proti tvemu kodu, ze spor si zaplatis ty.

[Jendа]

Znamená to, že budu muset řešit právní spor v zemi, jejíž právo je švihlé, neznám ho, v níž nemám kontakty na právníky, jejíž právníci jsou drazí a kam se nechci a nemůžu osobně dostavit. A když ho prohraju (opět na základě praštěného práva typu DMCA), tak budu platit za něco, co v mé zemi bylo zcela legální.

[Tomas]

a co ma byt? budes platit soudni spor v zemi, ve ktere te dotycny bude zalovat.

Co na tom neni pochopitelne? Pokud ve tvem repositari budes mit nejaky kod, ktery bude patentovany (a jsi tak "blby", ze to jeste vystavis na verejnem repositoari), a nekdo te bude zalovat... tak je

1) vcelku prirozene, ze soudit se bude s tebou, nikoli s githubem 2) soud probehne v zemi, ve ktere te dotycny "poskozeny" bude zalovat

Co je na tom nepochopitelneho?

[Jendа]

budes platit soudni spor v zemi, ve ktere te dotycny bude zalovat.

Ne, budu platit soudní spor v USA, kde bude dotyčný žalovat GitHub. Mě by dotyčný v USA žalovat nemohl, protože tam prostě nejsem.

Pokud ve tvem repositari budes mit nejaky kod, ktery bude patentovany (a jsi tak "blby", ze to jeste vystavis na verejnem repositoari)

a) Patentované je tam úplně všechno, ostatně hned vedle je zprávička, že je patentovaný scrollbar.

b) Je jedno, jestli je žaloba oprávněná, důležité je, že s tím budu mít pakárnu a investice, i když nakonec github vyhraje.

1) vcelku prirozene, ze soudit se bude s tebou, nikoli s githubem

Ty podmínky říkají něco jiného.

2) soud probehne v zemi, ve ktere te dotycny "poskozeny" bude zalovat

Jako že já zažaluju Pepu Vonáska z Horní Dolní v Guatemale a on s tím pak bude mít pakárnu v Guatemale? Ne.

[trekker.dk]

Mě by dotyčný v USA žalovat nemohl, protože tam prostě nejsem.

Na to se zeptej Kima Dotcoma, ten v USA taky nebyl, tak si ho nechají dovézt.

[Michal Kubeček]

ostatně hned vedle je zprávička, že je patentovaný scrollbar

A v diskusi je hned asi jako druhý nebo třetí příspěvek upozornění, že to je "trochu" jinak.

[trekker.dk]

Což ale nemění nic na tom, že v USA jsou registrované různé další stupidní patenty, které může kdejaký patentový troll zneužít.

[trekker.dk]

Je otázka, jestli takové ustanovení platí i mimo USA.

[dumblob]

Pro CR to neni otazka, protoze dle prava CR to v CR neplati.

[Jendа]

Hm, kde a v jakém zákoně?

[Tomas]

A ktere ceske pravo to neumiznuje? :)

[R]

Kazdy monopol je zly.

[Sid]

Vzdy ked citam ako dovod (odhliadnuc od inych rozumnych), ze to umozni lahko prispievat tak ma vzdy napadne, ze mozno by uz to chcelo konecne urobit nejaky prieskum ako sa zmena prejavi v mnozstve prace. Odmyslim si teraz trivialny commit typu preklep v nejakej message tak stale mi to pride, ze konfiguracia prostredia, testy, pochopenie kodu su nasobne zlozitejsie ako vytvorenie patchu. Hlavne to predpoklada motivaciu nieco urobit a vyriesit nieco co ma pali. Lebo povacsine co poznam vacsina programatorov si ponadava na nejaku chybu v ich toole ale malokto sa uz rozhodne to vobec reportovat a predstava, ze ked uvidi github tak hori tuzbou to fixovat sa mi zda pritiahnuta za vlasy. Ak pravda sa nevratim k bodu, ze ma velmi dobry dovod to robit. A v tom pripade asi obetuje tych 5 minut aby si pozrel ako urobit patch.

[washeck]

Poslední dobou pořád hledáme nové kolegy a odkaz na GitHub je už standardní způsob, jak kandidát může poslat referenci. Když vidím i triviální pull requesty do různých projektů, poznám, jaké nástroje dotyčný používá a že je schopný se zorientovat v cizím kódu a sepsat popis opravy tak, aby to ostatní pochopili.

Z tohoto pohledu je pro dotyčného lepší mít veškerou svojí open source aktivitu soustředěnou na GitHubu než rozptýlenou mezi samostatné VCS jednotlivých projektů.

[Sid]

asi ste nepochopil o com pisem. Nepisem o tom, ci github ano alebo nie ale o tom, ze by ma zaujimal realny prinos prechodu a nabor novych sil.

PS: nic v zlom ale pohlad na to ze by mal mat dotycny sustredenu aktivitu na githube a nie kde kade by ma celkom spolahlivo odradil od vasej firmy. Snad aby mal aj ten facebook kde pre zmenu zistite ci nie je asocial. No hlavne sa pri vyberovom procese moc neunavit, ze?

[washeck]

Vyčíslit reálný přínos by bylo zajímavé, ale v praxi asi těžko proveditelné. Osobně jsem si ověřil jen známou věc, že opensourcovat něco automaticky neznamená, že ostatní začnou přispívat. Chce to i dost marketingu, práce s komunitou, apod. Volba VCS je pak imho méně důležitá, ale zase GitHub je dnes standard, takže případná volba něčeho jiného by imho měl být dobře odůvodněná.

ad P.S.: Taky jsem neměl rád cloud a do teď mám blok dávat svá data mimo kontrolu, ale je dobré si přiznat, že je to silně menšinový přístup. Ve firmě jsem jediný bez FB, to samé mezi kamarády. A narážku na výběrový proces moc nechápu. Když vidím, že je někdo schopný najít a opravit např. chybu v nějaké knihovně získám mnohem lepší obrázek než ze CV, kde vidím jen název pozice a vůbec nevím, co ten člověk reálně dělal, jaký kód píše apod. V době před cloudem jsme to řešili nějakými testovacími úlohami, ale proč zatěžovat kandidáta i sebe něčím umělým, když na GitHubu bývá realný pracovní život.

[Bystroushaak]

PS: nic v zlom ale pohlad na to ze by mal mat dotycny sustredenu aktivitu na githube a nie kde kade by ma celkom spolahlivo odradil od vasej firmy.

No, ale to je tvoje chyba, ne přednost. Všichni zaměstnavatelé, kde jsem za poslední 4 roky řešil vstupní pohovor brali github jako velké plus a do velké míry mi to zajistilo pracovní místo, ale i zpříjemnilo pohovor, kde jsem se mohl věnovat konkrétnímu projektu, místo řešení nesmyslných úloh typu fizzbuzz. Pokud s tím máš problém, tak to není rebelie proti systému, ale znevýhodnění sama sebe na trhu práce.

Jinak tahle tvoje reakce mi připomíná K-R, prostě taková nechuť pro nechuť.

[Sid]

nie, narazal som na tuto vetu "Z tohoto pohledu je pro dotyčného lepší mít veškerou svojí open source aktivitu soustředěnou na GitHubu než rozptýlenou mezi samostatné VCS jednotlivých projektů.". github neni jedine miesto na svete kde je kod preboha, je tu apache napr. kde je toho kodu tiez dost. Nabuduce si snad budem klonovat cudzie projekty co su inde aby som ich mal na githube a ukazal tam nejake commity? Preto som narazal na to, ze pri pohlade na takto podany nazor by ma to odradilo od tejto firmy keby som niekoho takeho stretol. S tym, ze niekto chce referencie nemam najmensi problem.

[Bystroushaak]

Tak samozřejmě, že to není jediné místo na světě, kde lze hostovat kód. Je to ale momentálně asi nejznámější místo. I manažeři, kteří obecně nemají moc tušení o githubu vesměs vědí a orientují se v něm spíš, než na nějakém náhodném webu.

[washeck]

Ale samozřejmě. Pokud dotyčný napsal něco většího, třeba modul do Apache, pošle odkaz mimo GitHub. V praxi se ale spíš setkávám s tím, že člověk najde (a někdy opraví) menší chyby ve spoustě projektů. Jenže já třeba ve svém CV nemám odkaz x let starý bug report v OpenBSD, patche co jsem dělal do Webmina ani jiné drobnosti, protože každá zvlášť nedává smysl, ale dohromady tvoří celek.

[Boris Dušek]

Nechci to teď dohledávat, ale viděl jsem projekty, které zmiňovaly, že po přechodu na GitHub (s jeho Pull Requesty) se jim znatelně zvýšil počet příspěvků od externích přispěvatelů.

[kozzi]

No tak ja jsem presne ten typ cloveka co rad fixuje veci, ale delam to jen pokud se to da delat pres github, vyjmecene se mi che drbat s patchem a nejaktym mailing listem

[Sid]

No fajn. Takze zopar otazok ak mate chut odpovedat: 1) ako zlozite veci su fixy co robite? 2) fixujete veci ktore sa tykaju nejakeho problemu co vas pali? Alebo kludne aj vec co sa vas osobne netrapi? 3) ako zlozite su projekty ktore fixujete?

[kozzi]

1) to je velmi dynamicke od robnych preklepu, opravy dokumentace az po vetsi zasahy jao doimplementovani chybejici funkcionality, optimalizace ci vetsi a rozsahlejsi opravy.

2) Jak kdy, samozrejme pro me maji vetsi prioritu ty problemy co me trapi, ale casto opravuji i neco dle pozdavku jinych a veci ktere me osobne netrapi

3) To se tezko hodnoti ale casto i docela slozitejsi projekty napr standardni knihovna a kompilatory jazyka D, implementace JPA (batooJPA), HHVM, linux kernel (zde malo jelikoz se to nedela pres github)

[smazáno]

Tak ja mam treba zkusenosti takove, ze kdyz muj prispevek skonci pull requestem na GitHubu, tak uz to maintainer odklikne. Kdyz konci patchem v nejakem issue trackeru, tak se na to z vysoka ....opravdu to tak je. CPython je teda svetla vyjimka a nebyl problem se spravi uspesne komunikovat ani ted :).

[Bystroushaak]

Github je fajn právě proto, že všechny tyhle věci do velké míry automatizuje a usnadňuje. Třeba já jsem se poprvé zapojil do opensource projektů právě na něm a na projekty, které tam hostované nejsou ani neplýtvám časem (párkrát jsem to zkusil a byla to vesměs frustrující záležitost).

U projektů, které tam nejsou musím někde najít repozitář (to občas zahrnuje se registrovat na nějaké příšerné komunitní bugzilla stránky), pak se pokusit ho naklonovat (někdy nejsou přístupy a musím o ně žádat), nastudovat si spoustu blbostí ohledně přispívání, možná se prvně emailem zeptat, jestli o to fakt někdo stojí, pak provést změnu, zkusit testy, commitnout, pak přijít na to jak ten pull request vlastně poslat (někde normálně do repozitáře, jinde to chtěj třeba emailem), poslat pull request a doufat, že mě nějak trefí kladná/zamítavá odpověď emailem a nespadne do spamu.

Na githubu stačí kliknout na jedno tlačítko a velká část těchto starostí odpadá, vše je jednotné a jasně definované. Naklonuji, udělám změny, pošlu pull request, to vše rychle a přehledně.

[Sid]

ano to co ste popisal vyzera pekne (a tiez som to presne takto pouzil zoparkrat). Bavme sa ale o projektoch ktore nevyzadaju genialnu mysel aby clovek zistil kde co a ako poslat (tj nejake strasidelne wiki ktore niekto updatoval 3 roky dozadu) a kde to ako prispiet je popisane zrozumitelne, plus repository funguje v read-only mode a commitovat sa musi nepriamo. Stale mi pride (ale mozem sa mylit), ze ak sa nefixuje nejaka lahka vec lahko dohladatelna v kode tak celkove naklady na pochopenie projektu/kodu su nezrovnatelne inde ako cely proces s vygenerovavim fixu (ak je on zaujem samozrejme). Lebo pull request moze byt rovnako zamietnuty na githube.

[Bystroushaak]

Pull request sice na githubu zamítnout lze, nejde tím ale předejít forku, který vznikl už před tím. Ostatní z toho forku můžou vycházet (a často vycházejí), protože ho mají přehledně zobrazený. Kdyby se to stalo někde jinde, tak se o forku ani nedozví, natož aby k němu měli přístup a mohli ho dále modifikovat.

Zbytek argumentu asi úplně nechápu - náklady na pochopení projektu budou vždycky, ať už u githubu, nebo jinde, ne? Github prostě jen snižuje ten balast kolem, který musím udělat, abych mohl svůj kód nabídnout.

[Sid]

Ked si pozries ten zaciatok tak to neni github vs nie github co som pisal. To co pises plne uznavam. Ale ako moc github pritiahne novych ludi co maju zaroven technicke schopnosti (tj netrivialne fixy) a problem bol pre nich bol commit a veci okolo (JIRA,mailing list, atd). Lebo za seba sa priznam, ze vzdy ked som nieco takto opravoval tak to malo dovod v tom, ze som to pouzival a potreboval som odstranit nejaky bug alebo to rozsirit. Github je super na toto, lenze ked som potrebal to fixnut tak som jednoducho to urobil aj ked to bol svn alebo mercurial. Lebo som musel a mal motivaciu. A to mi slo, ze kde lezi ta hranica kde prevazi ohladom motivacie a lahkosti commitu. Mne pride,ze dlhodobo zrovna toto nikoho nepritiahne ale na druhu stranu vybrat si dva porovnatelne projekty (co je sice chimera ale dajme tomu) kde jeden je na githube a druhy na svn tak ani neni o com rozmyslat.

[Bystroushaak]

To je součástí toho, co jsem psal původně. Doslova byly projekty, kde jsem viděl homepage, zběžně jsem si prošel menu a pak se na ně vykašlal, protože mi bylo jasné, jak moc velký opruz by to celé bylo. Včetně například python knihoven, které jsem si lokálně na počítači opravil, ale prostě neměl sílu tu opravu předávat dál autorům, když k tomu mají takový prehistorický přístup. Samozřejmě, nejde o github, kdyby použili cokoliv jiného (gitlab třeba), než podivný hybrid bugzilly a wiki, tak bych se k tomu asi taky stavěl jinak. Ale takhle prostě moje nechuť potýkat se s jejich systémem byla větší, než chuť zpropagovat opravu chyby.

[washeck]

Ono taky nejde jen o opravy toho, co už používám, ale i fázi výběru. Třeba knihoven pro logování z Pythonu do Loggly je asi 8 a když vybírám, kterou použiju, podívám se na GitHub, jak který žije, kolik má forků a nemusím hledat, kde mají svn či mercurial, jestli je k tomu webové rozhraní, kde je issue tracker apod.

[Bystroushaak]

Jo, taky tak. Když si vybírám knihovny, tak je pro mě dost důležitá doba od posledního commitu.

[Bedňa]

To že je tam integrovaná bugzilla je super vec. Sám si do svojho projektu môžeš nahádzať problémy, alebo vylepšenia ktoré budeš riešiť.

GitHub a IRC považujem za najrýchlejšiu možnosť ako si dať v nejakom projekte opraviť bug.

Je to príjemné rozhranie nad projektom, jednoducho sa preklikávaš v histórií zmien, vidíš aktivitu, výborné vyhľadávanie v záplatách a kopec ďalších drobností, bez toho aby si musel študovať nejakú príručku.

[Bystroushaak]

Příjemné právě je, že to není bugzilla, ale issue tracker. Bugzilla má totálně nechutný fomulář pro ohlášení.

[Sid]

to hej, napr bugzilla netbeans je podla mna jeden pekny priklad, kde najst cosi konkretne v tej zaplave podpojektov je cista loteria a vyplnit bug je tiez zbytocne zlozite. Ale zase naopak reportovanie chyb z IDE prostredia do bugzilly je celkom fajn.

[Bedňa]

Ja všetky tieto projekty volám bugzilla, tak ako keď povieš oxeroxuj mi to.

[smazáno]

tak

[Bedňa]

Už to umí UNICODE?

[Bystroushaak]

A co bulánky?

[Bedňa]

Stačilo by Unicode.

[Bystroushaak]

Unicode tam samozřejmě je už asi 15 let. Co tam není je „Full grapheme based Unicode support“, viz nedávný thread v perl diskuzi.

[Bedňa]

Takže nemá.

[Bystroushaak]

Má dostatečně dobrou podporu unicode, aby se to dalo používat na každodenní bázi (=já to používám na každodenní bázi).

[Bedňa]

Ale jasne, len som čakal inú odpoveď aby som to mohol rozprúdiť ako v linkovanej diskusií, ty vôbec nepolupracuješ :)

[Tomas]

Kdyz chce clovek prudit, duvod se vzdy najde... A nejaka marginalni featura se pak vytahuje do aleluja... Ackoli dotycny vetsinou ani nevi, k cemu je.

[mirec]

Aby som bol presný chýba aj podpora kompozitných znakov napr.

In [1]: "noe\u0308l"
Out[1]: 'noël'

In [2]: "noe\u0308l"[::-1]
Out[2]: 'l̈eon'

In [3]: import unicodedata

In [4]: unicodedata.normalize("NFC", "noe\u0308l")[::-1]
Out[4]: 'lëon'

Viacej k téme tu.

Implementácia unicode v pythone je podriadená zložitosti O(1). Otázka pre perlistov: akú výpočtovú zložitosť majú reťazce v perle 6? Prístup na určitý index má zložitosť O(n), alebo O(1), alebo sa pri reťazci ukladá index na pozíciu?

[mirec]

OK, odpoviem si sám. Perl vymyslel vlastnú 4-bytovú novmalizovanú formu NFG (Grapheme Normal Form), ktorá má na rozdiel od ostatných foriem zložitosť indexácie O(1). V podstate by malo ísť vraj o rozšírenie formy NFC. Forma NFC nepodporuje kompozíciu niektorých znakov preto Perl zaviedol vlastnú formu, ktorá je v rozsahu 0x00000000 - 0x7FFFFFFF identická s NFC. Chýbajúce znaky sú generované v rozsahu 0x80000000 - 0xFFFFFFFFF od najvyšších pozícií smerom dole. Pri konverzii reťazca z NFC do NFG sa dynamicky vytvára tabuľka grafemov, ktorá môžem mať max veľkosť 2147483648 položiek.

PS. akého dílera má unicode konzorcium? Tiež by som chcel taký matroš.

[mirec]

Ešte pre PHP-čkárov

$s = "noe\xcc\x88l";
echo $s;
# noël
echo mb_strlen($s);
# 6
echo mb_substr($s, 0, 3);
# noe

Aj v PHP sa musí reťazec normalizovať aby mb_* fungovali ako-tak na väčšinu u nás používaných znakov.

[⧠ A = 0]

Víceméně. Leč cython ho neumí, snad protože gcc je pojebané a neumí unicode.