Python vs Ruby
2010-09-25T09:34:12+02:00
2010-10-10T09:35:50+02:00
2022-07-04T19:46:52+02:00
  • Jellemzően ... többnyire csak csomagolnak, nem javítanak. De nem csak ők, hanem a többi disztribúció is. Nem is volna sok értelme, mert ha túl sokat javítgatnának, nem lenne egyszerű a módosításokat szinkronban tartani a program (python) készítőjével. Meg irdatlan munka is volna. Nézem. közel 25000 csomagot mutat itt a csomagkezelő. Ha csak egy embert számolunk egy csomagra ... nem nagyon lehetne őket miből fizetni.

    Úgyhogy ehhez valószínűleg hozzá kell szokni opensource vonalon. Pontosabban, ha valami tényleg láthatóan rossz, és tényleg pythonos hiba, írhatsz a pythonosoknak. Azt ők tudják kijavítani.

    Illetve van, hogy meg tudod csinálni magadnak, ha szerencséd van. Ez a nyílt forrás nagy előnye. És akkor legalább nálad menni fog.

    Nem tudom mi a lást.
    Mutasd a teljes hozzászólást!
  • Ö... khm... _Bug_-os egy állítólag hosszútávon supportált rendszer egy csomagja. És látszólag tojnak rá a Canonical-nál.
    Egyébként meg kerülőutat tudok másikat is: python3, windows-on nézem az active python helpjét stb.
    Csakhát lásd fent. Azért ez így akkor sincs rendben.


    (az a szó, hogy "lást", mit jelent magyarul? A FF hejjesirásellenőrzője szerint van ilyen )
    Mutasd a teljes hozzászólást!
  • Könnyen előfordulhat, hogy a maverickes csomag használható lucid alatt. Töltsd le, dpkg -i csomag. Ha függőséget hiányol, töltsd le azokat is, és telepítsd. Ha ez végképp nem megy, leszedheted a .dsc, orig és diff fájlokat, és azokból (jó esetben) gyárthatsz csomagot a saját rendszeredre.

    Mellesleg vagy működjön magától, vagy csinálja azt, amit én akarok, de akkor ne legyek lusta hozzátanulni.
    Mutasd a teljes hozzászólást!
  • Köszi, valami ilyesmire tippeltem. Csak amikor először megláttam az eredményt, finoman szólva felállt a szőr a hátamon.
    Mutasd a teljes hozzászólást!
  • Igen, ez tipikus lábonlövési lehetőség, ez a része nekem se tetszik a nyelvnek.

    A listák cím szerint adódnak át. Tehát például:
    >>> spam = [1,2,3] >>> eggs = spam >>> print spam, eggs [1, 2, 3] [1, 2, 3] >>> eggs[2] = 42 >>> print spam, eggs [1, 2, 42] [1, 2, 42]

    Na most a [0]*3 csinál neked egy listát, aztán a következő *3 ezt a listát rakja háromszor bele a külső listába. Ugyanarra a listára lesz tehát három hivatkozásod.

    Kétdimenziós listákra én általában list comprehensiont használok, bár nem nyilvánvaló elsőre:
    >>> two_dim = [[0]*3 for _ in range(3)] >>> two_dim [[0, 0, 0], [0, 0, 0], [0, 0, 0]] >>> two_dim[1][2] = 42 >>> two_dim [[0, 0, 0], [0, 0, 42], [0, 0, 0]]

    A list comprehension egyik tulajdonsága, hogy a for előtti kifejezés újra kiértékelődik minden elemre, így a külső lista minden eleme egymástól független, új lista lesz.

    Kettőnél nagyobb dimenziószám esetén még macerásabb a dolog, bár ilyenekkel én ritkán találkoztam. Az ilyenek összepakolására talán már érdemesebb saját segédfüggvényt írni.
    Mutasd a teljes hozzászólást!
  • Roppant izgalmas dolgokra bukkanok

    ket_dimenzios_tomb=[[0]*10]*10

    Erről én azt képzeltem, hogy kapok egy olyan 10 elemű listát, amelynek minden eleme egy-egy tíz elemű lista, 0-ra inicializált tagokkal.

    Az olvashatóság kedvéért 3x3-asra csökkentve a méreteket:

    >>> n=[[0]*3]*3 >>> >>> n [[0, 0, 0], [0, 0, 0], [0, 0, 0]] >>> n[1][0]=1
    Erről én azt hittem, hogy mondjuk az első sor 0. elemét állítja 1-re. Ehhez képest:
    >>> n [[1, 0, 0], [1, 0, 0], [1, 0, 0]]

    WTF??

    Mindenesetre az a tény, hogy mind a 2.6.5-ös, mind a 3-as python ezt eredményezi, arra enged következtetni, hogy valamit én hagyhattam ki a tutorialok bogarászása során.

    Amit kifelejtettem:
    Ha a
    >>> n=[[0]*3]*3
    helyett
    >>> n=[[0]*3,[0]*3,[0]*3]
    formát használok, akkor viszont pontosan azt teszi, amit elvárok tőle. Érdekes...
    Mutasd a teljes hozzászólást!
  • Azért ennyire nem egyszerű a dolog. Az Ubuntu elvileg egy abszolút tudatlanoknak készített rendszer (a canonical legalábbis anno így adta elő ), ráadásul az LTS (mint Long Term Support) miatt feltételeztem, hogy ez a support valóban azt jelenti, hogy folyamatosan update-elik a bugos csomagjaikat.


    Attól kezdve, hogy egy ennyire alap dolgot, mint a python source-ból rakok fel, gyakorlatilag dobhatom ki az összes függőségeit és rakosgathatom fel azokat is forrásból, tarthatom karban magam az egészet. Na ezt nem akarom. Kerülőútnak jó, épp csak pl. az canonical/ubuntu által karbantartott(?) rendszert verem vele agyon.
    Ráadásul a Maverickben (alias ubi 10.10) már ott virít az újabb python, tehát nem lett volna súlyosan megterhelő a fejlesztők számára, hogy ezt is bedobják az eggyel korábbi, ám LTS-nek kikiáltott verzióba. (szerintem)

    szerk:
    mielőtt valaki belekötne a fentiekbe: a hozzászólásom helyenként költői túlzásokat és lustaságból eredő elemeket is tartalmaz!
    Mutasd a teljes hozzászólást!
  • Hmm, bár nem vagyok otthon Linuxban, azt hittem ott ez az alap hozzáállás. Ahelyett, hogy a lehetséges három csilliárd Linux disztróhoz mind felraknának egy-egy binárist, felrakják a forrást.

    De egyébként melyik rész nehéz abból, hogy
    1. Forrás letölt
    2. Forrás kicsomagol
    3. ./configure
    4. make
    5. su root
    6. make install

    OK, nem két kattintás a csomagkezelőben, de azért egy programozónak ennyi miatt nem kellene kiakadni...
    Mutasd a teljes hozzászólást!
  • Ismét "kellemesen" ki vagyok akadva: egy Ubuntu 10.04 (LTS)-t használnék kísérletezésre. Rajta python 2.6.5. Kissé bugos a help(is). Természetesen többször jelezve az ubuntus supportnak, de ahogy elnézem, valamennyi jelzés lezárva azzal, hogy ez python bug. (elég régi egyébként)

    Najó, akkor kivételesen szakítok a megrögzött szokásaimmal, felrakok egy nem előrecsomagolt verziót. Erre koppanok egy nagyot: python-ból nincs linuxos bináris a python.org-on!
    Szinte az összes létező unix-ba, linux-ba bele van pakolva, a python fejlesztők meg hát... izé... töltsem le a forrást és tegyem fel abból, ha nem tetszik az a bugos izé, amit a rendszeremhez kaptam.
    Hogyismondjamcsak... COOOOL!
    (bár 2.6-ból már elég rég kijött a 2.6.6, tehát simán berakhatnák az ubuntu-ba, hamár LTS)
    Mutasd a teljes hozzászólást!
  • Ezt úúúúúgy imádom.
    Felraktam az összes instant-client csomagot, majd leszedtem őket, kicsit később újra visszaraktam. Kivéve a -devel* csomagot, ami nélkül a ruby-oci8 nem telepíthető.
    Hát ezt még gyakorolni kell.
    Mutasd a teljes hozzászólást!
  • Mutasd a teljes hozzászólást!
  • Egyrészt megtanulni valamelyiket a kettőből (mert miért ne? - időm, gépem van, munkám nincs ), másrészt tesztadatokat generálni, amiknek a végállomása egy Oracle adatbázis.
    ---
    jellemző... ahogy én tudok fogalmazni... A "kettőből" az a ruby-python párosra vonatkozik, nem a scriptelés-adatbáziskezelésre
    Mutasd a teljes hozzászólást!
  • Most scriptelni akarsz, vagy adatbáziskezelni. Ha adatbáziskezelni, akkor szerintem arra a C# vagy a Java való és nem ezek a scriptnyelvek.
    Mutasd a teljes hozzászólást!
  • Most kezdek hajlani rá, hogy hanyagoljam a ruby-t, mint olyat.
    Pythonból - leszámítva a figyelmetlenségből eredő hibákat - villámgyorsan sikerült működőképessé tenni az oracle kapcsolatot.
    A ruby-val már órák óta nyűglődök, de mindig van valami baja.
    Ráadásul ami használhatónak tűnt oracle témában (ruby-oci8.rubyforge.org) háááát... mondhatni érdekes. Béta, nem tudom telepíteni az instantclient mellé és ami a legvadítóbb: a procject homepage angol változata (japánul nem tudok) a http://localhost:8001 címre van írányítva...
    Kár, mert sok tekintetben szimpátikusabb vótt... ("Lófejű, de szimpátikus..." )
    No, hajrá kígyók! Előre a Python útján!
    Mutasd a teljes hozzászólást!
  • Asszem, a python okoz még pár meglepetést. Végül kiderült, hogy az importálandó cx_Oracle valójában egy egyszerű shared library (cx_Oracle.so néven), aminek az elérési útját kellett a PYTHONPATH változóba betenni. Így már működik.
    Mutasd a teljes hozzászólást!
  • Pythonhoz most találtam egy jó kis könyvtárat:
    matplotlib: python plotting - Matplotlib 1.3.1 documentation

    Ha adatgenerálásra kell, akkor az se hátrány, ha a kimenetet fel tudod dolgozni és szépen meg tudod jeleníteni.
    Mutasd a teljes hozzászólást!
  • Rubyhoz:
    http://github.com/rsim/ruby-plsql
    a lenti példákból látszik hogy mi ez.
    pl.:

    plsql.package.eljárás(paraméterek) # és még sok más

    lényegében a nyelvből hívhatod a tárolt eljárásaidat.
    illetve az oracle eljárások tesztelésére is használhatod, RSpec-cel kiegészítve tudsz így unit teszteket írni igen könnyedén és elegánsan (plsql-ben való teszt írás (ami szerintem szívás) helyett)

    amúgy meg sima adatbáziskapcsolatot is tudsz csinálni, illetve van könyvtár ORM-hez is, nem kell a táblákhoz objektumokat csinálni, csak kapcsolódsz, aztán megy. :D pl. Sequel ( http://sequel.rubyforge.org/ )
    Mutasd a teljes hozzászólást!
  • Kösz, ilyen alapon lehetne perl is.
    (régebben játszottam PHP-vel is, perl-lel is, de most inkább maradok a python-ruby körökben, ha maradok... )

    Mindenesetre izgalmas egy játék párhuzamosan próbálgatni a kettőt. Gyakran okoz meglepetést, hogy a python nem eszi a ruby kódot és viszont.
    Jobb esetben már az interpreter kiabál. Rosszabb esetben csak nem működik (pl. az __init__ konstruktor a ruby alatt)
    Mutasd a teljes hozzászólást!
  • Akkor legyen a php
    Mutasd a teljes hozzászólást!
  • Azt hiszem igen... illetve így fejből nem tudom, van egy cx_Oracle csomag, ami elvileg egy python-oracle drivert tartalmaz. Szépséghibája a dolognak, hogy ubuntura telepítve (.rpm-ből, aliennel konvertálva) ugyan felmászott, de az import közli, hogy nem találja az importálandót. (és nem csak ő, én sem )
    A forrásból telepítéshez, ODBC-hez, egyebekhez - a jdbc thin drivertől eltérően - kellene egy oracle kliens arra a gépre, ahol telepíteni/használni szeretném. Ettől kezdve már több energiát kell belefektetni, mint amennyit számomra ér a dolog. (lásd eredeti cél: java tanulmányozáshoz tesztadatok generálása/adatbázisba töltése)
    Amennyit az elmúlt napokban ezzel foglalkoztam, java-ban már rég összerakhattam volna amit akarok.
    (csak ez most érdekesebbnek tűnt, ezért foglalkoztam velük ennyit)


    szerk: helyesbítek. Ezt még nem néztem, én valahol a sourceforge.net-en kötöttem ki egy wiki-s oldalon talált linkről.
    Mutasd a teljes hozzászólást!
  • Ezt nézted már? A Google ezt hozta első találatnak a "python oracle driver" kérdésre.

    A másik lehetőséged, hogy Jython-t használsz, ahonnan el tudod érni a javás könyvtárakat, beleértve a JDBC-t is. Nem lesz olyan kényelmes, mert az API Javára van szabva, nem Pythonra, de legalább új drivert nem kell vadászni hozzá.
    Mutasd a teljes hozzászólást!
  • Úgy egyébként most épp ott akadtam el, hogy az eredeti célomra nem fogom tudni használni egyiket sem.
    Az elképzelésem az volt, hogy miután az oracle-lel viszonylag jóban vagyok és tudom, hogy jdbc thin driverből könnyen elérem, egy oracle adatbázissal támogatnám meg a későbbi java próbálkozásaimat. Ebbe az adatbázisba töltögetnék ezt-azt pythonból v. ruby-ból. Én kis naiv... azt hittem, ha a perl-hez nem is, ezekhez már létezik könnyen használható oracle interface. Egyelőre ott tartok, hogy igencsak nagyot koppantam miatta.
    Mutasd a teljes hozzászólást!
  • Ááááá, semmi... csak eszembe jutott, hogy valamikor azt tanították: a matematika egzakt tudomány.
    Mutasd a teljes hozzászólást!
  • Most már kiváncsivá tettél, írjad csak!
    Mutasd a teljes hozzászólást!
  • Köszi... (írtam volna még valamit, de inkább kihagyom a poénkodást, mielőtt valaki véresen komolyan veszi. )
    Mutasd a teljes hozzászólást!
  • példádban a=-7 b=3 így q=-2

    de ha az egész osztásnál mindig lefelé kerekítünk, akkor q=-3, ekkor c-re 2 jön ki. De mondom -1 = 2 modulo 3. Vagyis az önkényes, hogy az eredménynek 2-t vagy -1-et adunk meg, de nem adhatunk meg viszont pl. 1-et vagy -2-őt.
    Mutasd a teljes hozzászólást!
  • Az igaz, hogy -7%3 = -1

    a/b = q
    a%b = c

    esetén definíció szerint azt várjuk c-től ugye, hogy

    q*b+c = a

    példádban a=-7 b=3 így q=-2

    vagyis:
    (-2)*3+c= -7
    egyenlet megoldását keressük.

    -6 + c = -7
    c = -1


    A zavart az okozza, hogy modulo 3 aritmetikában a 2 és a -1 ugyanaz a szám.

    modular arithmetic

    modulo 3 aritmetikában igazából 3 szám van: a 0, az 1 és a 2.
    A 1-et írhatod úgy is, hogy -2, a 2-őt úgy is, hogy -1, de ez nem számít, ebben az aritmetikában 3 elem van.

    A modulo aritmetika olyan, mint az óra lapján a 12 szám. mínusz két óra, az végülis 10 óra. Namost kb. arról van szó, hogy valamelyik programozási nyelv azt mondja, hogy 11 óra meg 11 óra az mínusz 2 óra, egy másik programozási nyelv azt mondja, hogy 11 óra meg 11 óra az 10 óra. Mindkettőnek igaza van, mert -2 = 10 modulo 12.
    Sajnos meg kell tanulni, hogy melyik programozási nyelv hogyan kezeli ezt a műveletet arra a ritka esetre, ha negatív számokkal akar az ember modulózni.

    A wiki-n amúgy külön oldal van a modulo operátorról különféle nyelvekben:
    modulo operation
    Mutasd a teljes hozzászólást!
  • Nekem ezt adja a Python interpreterem (3.1.2-es verzió):
    >>> 7%3 1 >>> -7%3 2 >>> 7%-3 -2 >>> -7%-3 -1

    Kipróbáltam egy online ruby interpreterrel, és ugyanezeket a számokat kaptam.

    Gondolj bele:
    7-1=6, 6 osztható hárommal, tehát ez helyes maradék. A másik helyes maradék a -2 lenne, mivel 7-(-2)=9 megint osztható hárommal.
    -7-2=-9, -9 osztható hárommal. A másik helyes maradék a -1 lenne, mivel -7-(-1)=-6.
    A harmadik és a negyedik eset ugyanaz, mint az első és a harmadik, mivel a három és a mínusz három többszörösei ugyanazok.

    Igazából a két maradék közti döntés önkényes, feltéve hogy az egészosztás művelet is megfelelően van implementálva. (Ugye annak meg kell maradnia, hogy a hányadost visszaszorozva az osztóval, majd hozzáadva a maradékot az osztandót kell visszakapni.) Az ember intuitíve azt várja, hogy pozitívat osztva pozitívval pozitív lesz a maradék is, tehát ez az eset adott. A Python (és a jelek szerint a Ruby) készítői úgy döntöttek, hogy az eredmény előjele mindig egyezzen az osztó előjelével.

    A legegyszerűbb, ha nem osztasz negatív számmal
    Mutasd a teljes hozzászólást!
  • Feladom... én úgy emlékszem, hogy a maradékképzés az előjeltől független dolog. Ehhez képest Ruby-ban és pythonban és perlben a -7%3 eredménye 2. Bash és a gcc által fordított kód szerint (-)1. Szerintem is.
    Nem értem.
    Mutasd a teljes hozzászólást!
  • Végigmentem a python alapjain, most elkezdtem nézegetni ugyanezen a szinten a ruby-t is, de kissé kiakasztott már az elején: a % operátor kiss "érdekesen" dolgozik benne.
    Hogy a tutorial konkrét példáját említsem:
    7%3, az normális körülmények közt 1.
    Ha nem vagyok túlságosan lemaradva a matematikával, akkor a -7 mod 3 szintén 1, esetleg -1. De hogy jön ki a ruby-féle logikával ebből a 2, esetleg -2 (attól függően, hogy melyik operandus negatív)???

    Hmmm... lehet, hogy sokat felejtettem matekból? Végülis nem kizárt.
    Mutasd a teljes hozzászólást!
abcd