Hirdetés

  2. Fórumok
  3. Szoftverfejlesztés
  4. Python programozás
Keresés

Új hozzászólás Aktív témák

  • #2582 cousin333 addikt Tigerclaw #2579
    Új Válasz #2582
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    cousin333

    addikt

    válasz Tigerclaw #2579 üzenetére

    A Python hivatalosan "multi paradigm", de az OOP erősen jelen van már az alapoknál. Tekintve hogy pl. az "egész szám" is egy osztály, saját metódusokkal... stb., inkább tekinteném olyan OO nyelvnek, ami nem tolja ezt az arcodba.

    A Python alapvetően más, mint sok ismert nyelv, és ez az OO terén is megjelenik. Szerintem nagyon is használható OO nyelvként, nem hiányzik belőle semmi, csak bizonyos dolgokat máshogy kezel. Absztrakt osztályok vannak benne, öröklés szintén. Adatrejtés elve is benne van, de Raymond Hettinger szerint a Python egy "consenting adult" nyelv. Szóval nincs olyan, hogy privát változó (csak privát-szerű, lásd _a vagy __a), de a paramétereket, metódusokat szépen modulokba, fájlokba, osztályokba szervezheted, definiálhatsz osztályokat osztályokon belül... stb. Nekem eddig semmi nem hiányzott belőle a legfontosabb, hogy mindent úgy használj, ahogy megtervezték, és ne próbált a C++, Java stb. gondolatiságot beleerőltetni.

    "mint egy klasszikus OOP nyelv"

    És milyen lenne az a klasszikus OO nyelv? :P Mint mondjuk a Java, ahol osztályok nélkül kb. mozdulni se tudsz? Vagy a C++ ami egy tuningolt C?

    "Dobálom ki a metódusokból a visszatérési értéket, az argumentum tipusokat"

    Ami nem kell az minek is :) Kb. mint a váltó, a kettős tömegű lendkerék meg a kipufogórendszer egy villanyautónál.

    nincs abstract osztály

    De van, a célnak szerintem megfelel.

    "nincs többszörös konstruktor"

    De van. Lehet, hogy egy kicsit más jellegű, de lényegét tekintve ugyanaz.

    "Muszáj vagyok commentbe tenni a listák, dictionaryk esetén, hogy milyen tipusra terveztem azokat."

    Ez meg inkább csak egy rossz beidegződés, mint a C-s for ciklus:

    for i in range(len(elemek)):
        print(elemek[i])

    vs.

    for elem in elemek:
        print(elem)

    Pont az a lényeg, hogy nem előre kell típusra tervezni. Duck typing for president :)

    "hogy tudok expliciten tipust kapcsolni a változókhoz"

    Nem tudok ilyesmiről. Gondolom a type hint-re gondolsz, de az nem sokkal több, mint amit a neve sugall. Alapvetően azért van, hogy a statikus kódelemzők, meg az IDE-k működését segítse. Odaírhatod, hogy -> int, aztán visszatérhetsz egy szöveglistával :)

    "Python namespace, scope, hogy aztán visszarakjam a láthatóságot a minimumra."

    Engem meg pontosan ez a fene nagy titkolódzás zavar a többi nyelvbe. Csak arra jók, hogy mindent megbonyolítsanak, és elfedjék a komplexitásból következő problémákat. Egy rendes, jól strukturált Python programmal ezek jórészt kivédhetők, vagy eleve nem jelentenek gondot.

    Tehát a lényeg, hogy a Python nagyon is OOP, a különbség nem a Python OOP és a többi OOP, hanem inkább a Python és a többiek között van. Nem akarom azt sugallni, hogy a Python minden megoldása van olyan jó, mint a többieké, vagy hogy mindent ugyanúgy megtehetsz, mint más nyelvekbe, de a saját logikája alapján jól működik, és szerintem elég jól meg van tervezve, a részek szépen összeillenek. Kivéve talán az enum, meg a switch-case... :)

    Ezért is tűnik kicsit "veszélyesnek", ha 1:1-ben próbálod átfordítani a meglévő programodat. A Pythonnak nem csak a szintaxisa más, hanem a logikája is. Amúgy a Python is erősen típusos, próbálj csak meg összeadni egy sztringet meg egy számot.

  • #2580 samujózsi senior tag Tigerclaw #2579
    Új Válasz #2580
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

    samujózsi

    senior tag

    válasz Tigerclaw #2579 üzenetére

    Muszáj pythonra áttenni?
    Sajnos a python oop az ilyen.

  • #2400 Siriusb veterán Tigerclaw #2399
    Új Válasz #2400
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    Siriusb

    veterán

    válasz Tigerclaw #2399 üzenetére

    A sorvégi kettőspont miatt (el)várja, hogy ezután egy beljebb igazított sor kezdődjön.
    Valamint nem szükséges előre definiálni változókat, hacsak a kód szerkezete meg nem kívánja, menet közben is létrehozhatók.

  • #2397 Siriusb veterán Tigerclaw #2395
    Új Válasz #2397
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    Siriusb

    veterán

    válasz Tigerclaw #2395 üzenetére

    Akkor szándékosan okoztad a hibát. :) Legalább egy pass-t írj oda.

  • #2396 sh4d0w félisten Tigerclaw #2395
    Új Válasz #2396
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    sh4d0w

    félisten

    LOGOUT blog

    válasz Tigerclaw #2395 üzenetére

    Használd a kód taget, különben a fórummotor stringként kezeli a kódodat és nem látjuk, hol az indentálási hiba.

  • #838 cousin333 addikt Tigerclaw #834
    Új Válasz #838
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    cousin333

    addikt

    válasz Tigerclaw #834 üzenetére

    Igen, fel. A megoldás a virtualenv. Az Anaconda csomag - amiből van "mindent bele" és minimalista (aka. Miniconda) minden jelentősebb oprendszerre - elég jól támogatja. Mindegy, hogy a 2.7-et vagy a 3.5-öst teszed fel alapból, könnyen létrehozhatsz egy új környezetet a másik verzióval is. Sőt, még a csomagokat és azok verzióját is megválaszthatod, ha például egy bizonyos feladathoz mindenképpen Numpy 10.1 kell.

    Ami az eredeti kérdésedet illeti, nincsen konkrét válaszom, viszont én azt mondanám, hogy 2.7 a legacy projektekhez (pl. kiegészítő modulokhoz), minden máshoz minimum 3.5.

  • #837 pbalintka csendes tag Tigerclaw #834
    Új Válasz #837
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    pbalintka

    csendes tag

    válasz Tigerclaw #834 üzenetére

    Debian/Ubuntu linuxon felrakhatod mindegyik verziót, nem kell forrásból forgatni se beállítani semmit.
    Elkészíted a programodat és futtatod.

    Python 2-vel:
    # python <progi.py>

    Python 3-al:
    # python3 <progi.py>

  • #836 EQMontoya veterán Tigerclaw #834
    Új Válasz #836
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    EQMontoya

    veterán

    válasz Tigerclaw #834 üzenetére

    Linuxon simán megoldható, max leforgatod forrásból.

    Szerintem egyszerűbb olyat írni, ami működik 2.7 és 3 alatt is. :)

  • #835 concret_hp addikt Tigerclaw #834
    Új Válasz #835
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    concret_hp

    addikt

    válasz Tigerclaw #834 üzenetére

    meg lehet csinálni, kell csinálni egy extra environmentet, de ha rákeresel stackoverflow ad ki megoldásokat (nem emlékszem már pontosan hogyan lett belőve, nem akarok hülyeséget írni)

  • #826 cousin333 addikt Tigerclaw #824
    Új Válasz #826
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    cousin333

    addikt

    válasz Tigerclaw #824 üzenetére

    Ugye milyen jó? :) Kár, hogy sajnos nem teljesen igaz... :U

    Szóval kicsit utána olvasgattam és az jött le nekem, hogy egyes típusok azért immutable-k, mert csak (nyilván emögött van elgondolás, az immutable objektum kb. olyan, mint valami konstans).. Nézzünk pár példát (az id függvény az adott objektum memóriabeli kezdőcímét adja vissza):

    >>> a = [1, 2, 3]
    >>> id(a)
    2238629696072
    >>> id(a[0])
    1970405872
    >>> id(a[1])
    1970405904
    >>> id(a[2])
    1970405936
    >>> type(a)
    <class 'list'>
    >>> type(a[0])
    <class 'int'>
    >>> b = (1, 2, 3)
    >>> id(b)
    2238629604520
    >>> id(b[0])
    1970405872
    >>> id(b[1])
    1970405904
    >>> id(b[2])
    1970405936

    A fenti esetben létrehoztam egy listát (a) és egy tuple-t (b), mindkettőt ugyanazzal a három elemmel. A címeket kiolvasva a következő megállítások tehetők:

    - az a és a b két külön objektum, egymástól viszonylag messze
    - mindkettő elemei int-ek és az elemek ugyanarra a memóriaterületre mutatnak!
    - magyarul csak egy darab 1-es van a memóriában, és mind a lista, mind a tuple ugyanarra hivatkozik
    - úgy tűnik az int objektum tárolására 32 bájtot használ a rendszer

    >>> b[1] = 4
    Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
    TypeError: 'tuple' object does not support item assignment
    >>> a[1] = 4
    >>> id(a)
    2238629696072
    >>> id(a[0])
    1970405872
    >>> id(a[1])
    1970405968
    >>> id(a[2])
    1970405936
    >>> id(b[1])
    1970405904
    >>> id(b[2])
    1970405936

    Itt azt látjuk, hogy a b második elemét nem engedi módosítani (hiszen az egy tuple eleme), az a-ét viszont igen, noha mindkettő ugyanarra az elemre mutatott! Ha a lista módosítása után is megnézzük a címeket, akkor azt látjuk, hogy az 1, 2 és 3 a "helyén" maradt, viszont a rendszer létrehozott egy új, 4 értékű int-et és az a[1] már erre hivatkozik.

    >>> c = "szoveg"
    >>> id(c)
    2238629677408
    >>> for x in c:
    ... print(id(x))
    ...
    2238534181640
    2238539112832
    2238534182144
    2238538540512
    2238534181696
    2238538838680

    A harmadik példa egy sztring objektum, aminek az elemei a memóriában nem egymás mellett, hanem elszórtan helyezkednek el. Ellentétben azzal, amit korábban írtam.

    Python data model: "The value of some objects can change. Objects whose value can change are said to be mutable; objects whose value is unchangeable once they are created are called immutable."

    ui: csak nekem tűnik randomnak a Programkód kapcsoló hatása?

  • #825 sonar addikt Tigerclaw #823
    Új Válasz #825
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    sonar

    addikt

    válasz Tigerclaw #823 üzenetére

    Általánosságban el lehet mondani, hogy a whitelista jobb.
    Tehát ha magad szűröd ki, hogy mi minden mehet be.
    Kivétel kezelés sem rossz, de ott nehezebb felkészülni minden féle kivételre.
    De program függő, van amikor nincs értelme whitelistázni és nehéz karbantartani.
    De amikor túl sok a kivétel és nem átlátható akkor inkább whitelista.

  • #821 cousin333 addikt Tigerclaw #820
    Új Válasz #821
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    cousin333

    addikt

    válasz Tigerclaw #820 üzenetére

    Nem vagyok expert, de valahogy a következőképpen tudom elképzelni (ez most vélhetően elég pongyola lesz): meg kell különböztetni magát az objektumot és az arra mutató referenciát:

    a = 13
    b = a

    A fenti kód esetében a 13 mint egész szám, eltárolódik a memóriába, és erre az a változó hivatkozik. A második sor egy b nevű referenciát hoz létre, ami azonban szintén ugyanarra a 13 objektumra vonatkozik! Ha most az alábbi kódot írod:

    a = "szoveg"

    akkor tulajdonképpen nem az a-t változtatod meg, hanem létrehozol egy "szoveg" tartalmú sztringet és az a ezen túl arra az objektumra fog mutatni. Ha ugyanezt mondjuk a b-vel is eljátszod (ami most még mindig a 13-ra mutat!):

    b = 9.817

    akkor létrejön a 9,817 lebegőpontos szám és a b arra mutat. A 13-ra már nem mutat semmi, azért a szemétgyűjtő (garbage collector) előbb-utóbb összegyűjti ("megsemmisíti").

    Tehát amikor a "sztringből egész számot csinálsz", akkor nem magát a sztringet változatod meg, hanem csak a hivatkozásod (változóneved) már egy más memóriaterületen lévő, másik objektumra fog utalni. Ha egy karaktert írnál át akkor viszont ugyanazt az objektumot módosítanád, ami nem lehet, hiszen immutable. "Módosítani" csak úgy tudod, ha létrehozol egy teljesen új sztringet, ami már tartalmazza a kívánt módosítást (pl. "alma" -> "elme") és azt ugyanúgy nevezed el, ahogy a régit hívták. Ekkor az eredeti sztring még ott van, csak már nem kell senkinek és megy a "kukába". Tehát:

    a = "alma"
    a = "elme"

    A két sztring objektum teljesen különbözik, az l és az m sem "közös". Csak mindkettőt ugyanúgy hívják, a Python meg "elfelejti" az elsőt és mindig csak az utolsóra emlékszik.

    Azon objektumokat, amiket helyben nem, csak másolással és aközbeni módosítással lehet "módosítani" nevezzük immutable-nak.

    Ezzel szemben egy Python lista például nem olyan mint pl. a C tömb, ahol azonos típusú elemek vannak egymás után a memóriában. A lista egy viszonylag bonyolult objektum, ami többek között mutatókat tartalmaz az egyes listaelemekre. Ezért tartalmazhat egy lista tetszőleges típusú elemeket, akár listákat is vegyesen. Ebben az esetben egy listaelem módosítása tulajdonképpen az adott elem referenciájának módosítását jelenti (pl. mostantól a 23 helyett a "szöveg" sztringre mutat), viszont minden más elemet érintetlenül hagy. Volt erről egy jó kis Youtube videó valahol.

    Remélem érthető volt valamelyest és nem is írtam totális hülyeségeket. :B

Új hozzászólás Aktív témák

Hirdetés