Python alapok

Python alapok
2005-01-13T21:38:46+01:00
2005-02-12T11:11:38+01:00
2022-11-01T04:25:38+01:00
  • Ezt a dolgot már tényleg kitárgyaltuk egy párszor és én sem szeretnék már erről beszélni!
    Mutasd a teljes hozzászólást!
  • Hát igen ha kellőképp ki lenne optimalizálva, de azért vannak kétségeim a JIT-el kapcsolatban! Szvsz soha nem fog tudni 100%-ban kihasználó kódot csinálni!

    Azért tegyük hozzá az X86-64 lefelé kompatibilis, másrészt szerintem nem egyhamar lesz platformváltás az asztali PC-k terén! (Bár egy IA-64 -nek örülnék)
    Mutasd a teljes hozzászólást!
  • és arról sem hogy a Zope-t túl sűrűn használná valaki élesben, mondjuk hasonló mértékben mint az Apache+PHP vagy a java servlet/JSP, esetleg az IIS+ASP/ASP.NET kombinációt


    Mo-n en sem tudok olyan helyrol, ahol hasznalnak, bar volt Zope-os fejlesztesre ajanlat itthonrol.
    Kulfoldon viszont sok helyen nyomjak. A Zope alapbol joval lassabb, mint a fent emlitett kombinaciok (viszont Apache+PHP-nal jobban skalazhatobb), ezert egyszeru feladatokra (forum, webbolt, stb) nem erdemes hasznalni. Megvan a maga terulete ennek is.
    Mutasd a teljes hozzászólást!
  • A sebesség szép dolog, de a felhasználói programok 90%-nál semmit nem érnél egy mégoly optimalizált assembly kóddal sem, ugyanis sebesség szempontjából a szűk keresztmetszett nem a gép, hanem a felhasználó (+ a perifériák, a külső adatok elérése, hálózati kapcsolat, stb.). Bár ez mondjuk eélhangzott már párszor a fórumon Ahol pedig fontos a sebesség, ott nem fognak bájtkódot használni.
    Mutasd a teljes hozzászólást!
  • Hogy használod így ki rendesen a vasat? Sehogy!


    Eh, ez csak _egyetlen_ szempont. Penzert keszulo szoftvereknel ennel joval fontosabb, hogy mennyi ido alatt keszul el. Szerver oldali fejleszteseknel meg az, hogy mennyire skalazhato, stb.

    netchan
    Mutasd a teljes hozzászólást!
  • Híve vagy vagy nem, nem fogsz tudni hosszabb távon 99 féle platformra fejleszteni. Lesz x86, x86-64 meg még kismillió proci és nem fogsz tudni mindegyikre optimalizált kódot csinálni.
    Az igazság az hogy szvsz már ma is jobb kódot tudna csinálni egy JIT ha kellőképp ki lenne optimalizálva mint egy általános fordító. Ki tudná használni az egyes procik, Pl. Intel, AMD utasításkészletét.
    Mutasd a teljes hozzászólást!
  • Én nem vagyok ennek a fene nagy platformfüggetlenségnek a híve, amit ezek a byte kódos fordítók képviselnek! Nem jön be a szemlélet és kész! Hogy használod így ki rendesen a vasat? Sehogy! Lassan már ott tartunk hogy még bytekód sem lesz az egész mögött hanem majd valami interpreter futtatja az egészet! Meg ott a sebesség "probléma"! Persze-persze itt most lehet azt mondani hogy annyival úgysem lassabb, meg ott a nagy gép az majd úgyis kiszámolja, de ennyi erővel írjunk gány kódot úgyis minimális lesz a sebességkülönbség igaz kedves netchan!
    Mutasd a teljes hozzászólást!
  • Voltak/vannak javából natív kódot csináló programok. Ilyen Pl. a gcj is, de régebben volt valami windowsos RAD eszköz aminek már elfelejtettem a nevét, de szintén tudott ilyet csinálni. Nincs ennyire éles határvonal, ha a JIT a köztes kódból gépi kódot csinál, pláne ha még le is cacheli. Vagy ott van a vizuális bézik ami tud interpreterként is futni de tud natív exe-t is csinálni. De légy erős: láttam én már olyan pascal fordítót ami bytekódot csinált (sőt, ezeknek a bytekódoknak a neve eredetileg p-kód volt, és itt a P a pascal-ból ered, a régi szép 8 bites időkben elég sűrűn előfordult ilyen elvű megvalósítás, lást Pl. a ZX-Spectrumon a HiSoft pascal fordítói). De láttam én már C interpretert is.
    Szvsz a scriptnyelv nem azért scriptnyelv mert értelmeződik és nem fordítódik, hanem azért mert nincs benne normális típuskezelés. Ennek ellenére persze lehet bennük nagy rendszert is írni ha muszály - láttam én már olyan ügyviteli szofot aminek a nagy részét az RSX-11 parancsértelmezőjében írták - ami kb. a bash scriptelési lehetősége környékén járt - és bár nem volt épp a megbízhatóság és a sebesség szobra, de működött. Nem is szólva Pl. az xBase-ről (dBase, Clipper, és társai), ami szintén dinamikus típuskezelést használt.
    Az persze igaz hogy mára rendelkezésre állnak normálus típuskezeléssel rendelkező programnyelvek, de ettől elszánt emberek még írhatnak scriptnyelvben is nagy méretű dolgokat. Más kérdés hogy a zope-n és a bittorrenten kívül nem nagyon tudok nagyobb pythonos dologról (és arról sem hogy a Zope-t túl sűrűn használná valaki élesben, mondjuk hasonló mértékben mint az Apache+PHP vagy a java servlet/JSP, esetleg az IIS+ASP/ASP.NET kombinációt), és legalábbis a freshmeat.net-en a nagyobb dolgok azok inkább C++-ban vannak...
    Mutasd a teljes hozzászólást!
  • GCJ: The GNU Compiler for Java - GNU Project - Free Software Foundation (FSF)

    GCJ is a portable, optimizing, ahead-of-time compiler for the Java Programming Language. It can compile:

    * Java source code directly to native machine code,
    * Java source code to Java bytecode (class files),
    * and Java bytecode to native machine code.
    Mutasd a teljes hozzászólást!
  • Számomra a szkriptelés != programozás!
    Mutasd a teljes hozzászólást!
  • És ha megvalósult volna a Java processzor, akkor egycsapásra beléphetne a Java az elit kategóriába, anélkül, hogy a nyelvben bármi változás történt volna? Vagy scriptnyelvvé válik bármely nyelv, ha a vele elkészített natív futattható állományt egy emulátorban indítják? Nem tudom emlékszel-e pl. Spectrumos, C64-es, de még akár PC-s Pascal és C interpreterekre - most akkor a Pascal és a C scriptnyelv?

    Az, hogy mi fordul natív kódra és mi nem, teljes egészében a fordítón és az adott fejlesztőeszközön múlik, nem pedig a nyelven. Bármelyik ún. scriptnyelvhez készíthető lenne natív fordító. Persze ezt a véleményt nem akarom rád erőszakolni, mindenkinek meglehet a maga magánvéleménye (akár némileg megalapozatlanul is )
    Mutasd a teljes hozzászólást!
  • Az én felfogásomban az a script nyelv amely fordításából nem áll elő natív kód! Tudom feltalálták már a JIT-et is, de az számomra már nem ugyanaz!
    Mutasd a teljes hozzászólást!
  • És mitől nem programozás a programozás egy olyan nyelvben, amely mögött byte kód van? Van a virtual machine és a real machine között valami olyan fundamentális különbség, ami az egyik programozását programozássá teszi, a másikat meg nem?

    Egyébként, mivel nincs rá definíció, hogy pontosan mit tekintünk szkriptnyelvnek, ezt a szót nem is érdemes használni. Szerintem valami olyasmit értenek rajta, hogy olyan nyelv, amelyben nincs túl sok compile time ellenőrzés, olyan nyelv amelyben nagyon hatékonyan lehet nagyon gyorsan változó - változékony kódot írni.
    Mutasd a teljes hozzászólást!
  • Ez természetesen szigorúan magánvélemény volt! Az én felfogásomban a Java is egy szkriptnyelv mivel byte kód van mögötte!
    Mutasd a teljes hozzászólást!
  • Termeszetesen ha valaki mircscriptbe irogat nemtudom miket, vagy bashal makrosit egy tobbsoros muveletet, az nyilvan nem programozas
    Mutasd a teljes hozzászólást!
  • Mert szvsz legtobben azt hiszik h a scriptnyelvek egyszeru feladatokra, gyakran hasznalt muveletek makrositasara, cgi-ra vagy mittomen meg mire valok csak, es komoly dolgokra nem hasznalhatok.
    Pedig ezek a mai "scriptek", egyaltalan nem ugyanolyanok mint amit regen az interpreteres nyelvek alatt ertettek.
    Pythonban is kitermeltek mar par igen komoly projectet (zope, bittorent),
    es en az o munkajukat is ugyanugy programozasnak tartom mint azet aki pl assemblyzik.
    Mutasd a teljes hozzászólást!
  • Igen valóban Object Pascal-t kellett volna írnom!

    Számomra a szkriptelés != programozás! Én személy nem szeretem a szkript nyelveket!
    Mutasd a teljes hozzászólást!
  • Bevallom nem olvastam meg vegig az osszes hozzaszolast, mert eleg sok szuletett, de nekem ugytunik eddig inkabb magarol a nyelvrol (objectpascal) volt szo es nem a delphi mind ide kepessegeirol, 2 nyelvet pedig miert ne lehetne osszehasonlitani egymassal?

    Amikor egy nyelvre aztmondjak h scriptnyelv nekem mindig ugytunik mintha lenne vmi pejorativ tartalma.
    A javara sem mondjak h scriptnyelv, holott ott sincs szo gepikodrol. A python is csinal bytekodot, es ha jolremlik JITelesre (Psyco) is van lehetoseg, szoval ittsem egyszeru soronkenti interpretalasrol van szo.
    Mutasd a teljes hozzászólást!
  • Hmmm érdekes a vita, de számomra nem világos hogy mi értelme a Delphi-t összehasonlítani egy script nyelvvel!
    Mutasd a teljes hozzászólást!
  • Nincs az a szofisztikalt IDE, ami ubereli az egyszeruseget.
    Mutasd a teljes hozzászólást!
  • Ilyenkor a key-eket bele lehet rakni egy kulon interfacebe es azt kulon implementalni ahol szukseg van ra, es ha ezt gepeli el az ember arra a pychecker utility figyelmeztet.
    Mutasd a teljes hozzászólást!
  • Jól van, na, igazatok van !
    Nagy projektnél tényleg nem könnyű ezt átlátni. És valóban, egy IDE sokat segíthet, de csak a típusorientált cuccoknál.

    De nekem néha akkor is jobban tetszik az egyszerűség, és a 10-szer gyorsabban gépelés, mint ez hypertámogatott 200 KM-es forráskód.

    Én már csak ilyen beteges vagyok...

    Mutasd a teljes hozzászólást!
  • Ez szép. És ha van 10000 különféle függvényed az objektumaidban akkor honnan tudod hogy az xxxx által visszaadott táblában milyen elemek vannak ? Mert amíg van három ilyen függvényed addig ez nem gond... Másrészt pedig mi van ha a hivatkozásban valahol a size-t lecserélted méretre ? Ez max. akkor fog neked kiderülni ha a program végrehajtja az adott utasítást. Az elgépelésre pedig jó esélyed van, mivel kissé kétlem hogy létezne annyira intelligens IDE ami ilyen helyzetben ki tud segíteni code completitionnal. A refactoringról már nem is szólva...
    Mutasd a teljes hozzászólást!
  • Ha már ilyen jó példát vettél elő, akkor közlöm veled, hogy elég kényelmesen támogat minket a Delphi IDE-je, azaz a a függvény implementációjánál pl nem is kell újraírnom a fv-ét, elég egy Ctrl+Shift+C páros, és akkor még ott van a Code Insight.

    Tehát nem hiszen, hogy py alatt gyorsabban lehet gépelni
    Mutasd a teljes hozzászólást!
  • Íme itt egy példa arra, mikor lehet gyorsabban gépelni Py alatt, és hogy mire a jó a dictionary:

    Delphiben 500 km-es fejléc (és persze kétszer), amit át lehetne adni valami hash table-ben is sokkal kényelmesebben:
    function LoadJPEGToThumbBitmap(FN:string;jpg:TJPEGImage;var FileSize:Int64;var FileDate:TDateTime;var OrgSize:string):boolean;

    És egyszerűbben:

    def LoadJPEGToThumbBitmap(FN): r={} r['jpg']=LoadJPEG() ... r['filesize']=size ... return r



    Mutasd a teljes hozzászólást!
  • Egyebkent ha van valakinek otlete valami kozepesen komplex, par ora alatt megirhato problemara, ahol maga nyelv kap teret, erdemes lenne osszerakni az itt felsorolt kornyezetekben (Delphi, Java, Python, kinek mihez van kedve).


    Ez jo jatek a nyelvekkel valo ismerkedesre (azert nehany csapda helyzet nem jon elo, mert ezek kis feladatok, es ebben sokkal jobbak a dinam,ikus nyelvek). erdemes megnezni szerintem a www.topcoder.com-ot ott rengeteg feladat van (inkabb azert algoritmus jelleguek), vagy a Dave Thomas fele 'code Kata' gyujtemenyt: http://blogs.pragprog.com/cgi-bin/pragdave.cgi/Practices/Kata

    (A katanak hivjak japanul a formagyakorlatot, ami eleg fontos szerepet kap a tradicionalis keleti harcmuveszetekben - a gyakrolas legfontosabb formaja. Ahhoz, hogy jo legyel, hogy fejlodj folyamatosan gyakorloni kell - ezek pedig pont ilyen kis gyakorlo feladatok, amiket akar tobbfelekepp is megprobalhatsz megirni, tobb nyelven, sebessegre optimalizalva, kodmeretre optimalizalva, stb. :) )
    Mutasd a teljes hozzászólást!
  • Egyebkent ha van valakinek otlete valami kozepesen komplex, par ora alatt megirhato problemara, ahol maga nyelv kap teret, erdemes lenne osszerakni az itt felsorolt kornyezetekben (Delphi, Java, Python, kinek mihez van kedve).

    Ez egy elfogult pelda, de kivancsi lennek, hogy hogy nezne ki az alabbi dolog mas nyelveken:
    Implementing "Future"s with decorators

    Kis magyarazat: A kodreszlet egy dekoratort implemental. Ez nagyjabol a C# atributumainak felel meg, tehat valami nyelvi objektumhoz (valtozo, osztaly, metodus, stb) kapcsolhato, azt modosito kod.
    Mit csinal a future? Tegyuk fel, hogy van egy hosszan futo muveletunk, amit elkezdunk vegrehajtani egy kulon szalban, aztan majd kesobb, amikor szukseg lesz ra, "bevárjuk" a főthreadben (ha addig nem vegzett volna). Azt szeretenenk, ha a threading dolgok nem ronditananak bele a kodba.
    A fenti linken talalhato future dekorator ezt teszi, _barmely_ fuggvenybol/metodusbol ilyen pahuzamosan vegrehajtott thread-et csinal, egyetlen extra sor hozzaadasaval.
    A kodban az elso "@future"-tol kezdve van a pelda a mukodesre, a printekbol lehet latni, hogy mi tortenik.

    netchan
    Mutasd a teljes hozzászólást!
  • A cím szerinti paraméter visszaadás pont arra lett kitalálva hogy több értéket tudjon a hívott függvény visszaadni a hívónak. És nagyon is természetes


    En is pont igy lattam a dolgokat a Python elott
    Mutasd a teljes hozzászólást!
  • Most nem azért a 20 fillérért, de idáig hányszor volt tényleg szükséged arra, hogy egy vektor v. tömb indexe/kulcsa is tetszőleges típusú legyen? Mert én így hirtelen nem tudok real-life példát mondani erre..


    Pythonban aranyaiban sokkal tobbszor hasznal az ember listat es tuple-t mert nem igenyel extra kodolast es nem maceras. Ezert van az, hogy erre a funckiora szukseg van Pythonban, de nem hianyzik annyira mondjuk Delphiben egy ahhoz szokott embernek.

    Gyakorlati pelda: sokszor van az, hogy f1 hivja f2-t ugy, hogy felhasznal nehanyat a kapott parameterek kozul, amiket nem feltetlenul akar ertelmezni:

    def f1(status, metadata): print "result: %i" % status print "metadata:" f2(**metadata) def f2(name, age): print "\\\\tname: %s" % name print "\\\\tage: %i" % age f1(1, {'name':'Jani', 'age': 22})

    Ez itt egy pelda arra, amikor a dictionaryban kulonfele elemek vannak.
    Ilyenkor a castolas nem lenne megoldas, mert a name barmi lehet, aminek van __srt__() metodusa (kb mint a toString()), akar sima string, akar barmilyen mas ojjektum.
    Mutasd a teljes hozzászólást!
  • Ez igy van, csak ez mar tulmutat a dolgokon. En mar azzal is nagyon boldog lettem volna a C# eseteben, ha tamogatna a tobb visszateresi erteket, dehat ugye ez elvbol nem fog menni.


    Én is ezt érzem a Delphivel kapcsolatosan.
    A Java más tészta, mivel ott minden osztály.

    De Delphiben pl. mindent, ami osztály, létre kell hoznod; és ez eltér attól, hogy pl. a Delphi az alaptípusokat kezeli (int/double).
    És a stringről nem is beszélek, meg a dina tömbökről.

    Szóval az a zavaró, hogy ahhoz, hogy konzekvens legyen, kéne írni Int/String/Double osztályokat, és az eljárás, vagy tömb ilyen pointereket fogadna. Aztán eldöntené, hogy mihez kezd velük.

    A másik megoldás lenne, és ez az, ami szép a Pythonban, hogy elrejti előled ezeket.
    Vagyis a Delphi is megteszi helyetted, hogy a string-nek memóriát foglal, áthelyezi, stb; meg a dina tömböket is kezeli - nem kell lefoglalnod, létrehoznod.
    Definálnod kell, és van.

    Én azt utálom, hogy ennél leragadtak.
    Szerintem egy értelmesebb fordító, ha beírnám, hogy:

    var
    x:DoubleClass;

    Le tudná generálni a DoubleClass-t, ami speciális class volna (ref. számlált).
    És szépen fel is tudná számolni, ha kellene.

    Így már be tudnám tenni szépen listába, mint object.

    De amíg keverednek a natív típusok, meg félnatív típusok, és az osztályok, addig mindig lesz anyázás.

    Ebből a szempontból jobb a Py és Java féle megközelítés.
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd