Kezdem megszeretni a Python nyelvet

Ugyanis hozza a legszebb tradíciókat:

>>> print(0==False)
True
>>> print(1==True)
True

Na azzal a különbséggel, hogy PHP-ben van ilyen is:

php > print (int)(false==0);
1
php > print (int)(false===0);
0

Bónusz: Pythonban van komplex típus, és van korlátlan számábrázolási tartományú integer. Na de nem egyszerre!


c1=complex(200000002,400000002)
c2=complex(1000000005,3)
c=c1*c2
print("%32.0f" %c.real)

print("Ez lenne a jo: %d" %(int(c1.real)*int(c2.real)-int(c1.imag)*int(c2.imag)))

kimenete:


              200000001800000000
Ez lenne a jo: 200000001800000004

( wladek1 | 2022. 04. 19., k – 21:37 )

A PHP gyengén típusos nyelv. A false == 0 ez esetben tökéletes, csakúgy, mint a === esetén az eredmény. 

Error: nmcli terminated by signal Félbeszakítás (2)

( Nyosigomboc v | 2022. 04. 19., k – 22:04 )

>>> 0==False
True
>>> 0 is False
False
>>> False is False  
True

A strange game. The only winning move is not to play. How about a nice game of chess?

Facepalm.

A ket [1, 2] listad nem azonos, szoval az is operator termeszetesen kulonbozonek fogja venni. A False ojjektumbol egy van (meg persze None-bol, True-bol, stb. is), szoval ket False ertek az igazabol egy False ertekre mutato 2 referencia, es azonosak.

Ha tenyleg az kell, ami a masodik printben van, akkor beteszed egy really_really_equal fuggvenybe, es azt hasznalod.

Esetleg mielott megszereted a Python nyelvet, meg is tanulhatnad..

A strange game. The only winning move is not to play. How about a nice game of chess?

Úgy tűnt, mint ha azt sugallnád, hogy az `is` lenne használható 'tényleg egyenlő, nem csak hasonlít' értelemben. [Az mondjuk lehet, hogy a hozzászólásod szöveges része tömörebb volt a kelleténél, túl sokat bíztál telepatikus kommunikációra.] Erre mondtam, hogy sajnos nem, ki kell írni, hogy type(a)==type(b) and a==b.

Nem szeretnélek megbántani, mert nagyon tisztelem a munkádat, de azt hiszem nem igazán ismered a Pythont.

>>> print([1,2] is [1,2])
False
>>> print([1,2] == [1,2])
True
>>>

Az is azt figyeli, hogy két objektum azonos memóriahelyen van-e, vagyis, hogy a két változó ugyanaz-e. Ha a változók értékét szeretnéd összehasonlítani arra a == szolgál.

“The basic tool for the manipulation of reality is the manipulation of words. If you can control the meaning of words, you can control the people who must use them.”

― Philip K. Dick

Szépen megpróbálja kimagyarázni, de ezt nem nagyon érdemes. Itt jön be az, hogy a jelenlegi okoknak már nincs köze az eredeti célhoz, vagyis hogy a szoftver az embert szolgálja konzekvens módon. Ha fájlból futtatva jó, akkor az interpreternél rossz a design és a koncepció. Nem szépíteni kell hanem újra tervezni mielőbb.

is leggyakoribb hasznalata:

In [3]: timeit a is None
19.9 ns ± 0.238 ns per loop (mean ± std. dev. of 7 runs, 10000000 loops each)

In [4]: timeit a == None
23.2 ns ± 0.0979 ns per loop (mean ± std. dev. of 7 runs, 10000000 loops each)

Ami az ujra tervezest illeti:
https://en.wikipedia.org/wiki/Cython
"which gives a 95 times improvement over the pure-python version. More details on the subject in the official quickstart page."

go rust
 

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

u0_a182@localhost:~$ python
Python 3.10.1 (main, Dec  9 2021, 15:28:13) [Clang 12.0.8 (https://android.googlesource.com/to
olchain/llvm-project c935d99d7 on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> 0 is False
<stdin>:1: SyntaxWarning: "is" with a literal. Did you mean "=="?
False
>>> a=0
>>> a is False       
False

Egyszeruen szol, hogy egy fixen odairt ertekkel (literal) hasznalod, es biztos ezt akartad-e, mert ez a kododban valoszinuleg felesleges. Ezert warning.

A strange game. The only winning move is not to play. How about a nice game of chess?

( uid_6201 v | 2022. 04. 20., sze – 09:56 )

Szerkesztve: 2022. 04. 20., sze – 10:20

Sőt tovább is van: kedves példám, miután egyszer belecsúsztam egy ilyesmi eltérésbe, ami hibás számításhoz vezetett.

#include <stdio.h>

int main() {
    float a = 1.0/3.0;
    int b = 4.0 / a;
    printf("4.0 / (1.0/3.0) = %d\n", b);  // eredmény itt 11 lesz.
}

Szintén az automatikus típuskonverzió kulisszatitkai. Ha szigorúan azonos típussal dolgozik a nyelv, akkor ez sem marad a kulisszák mögött.
https://play.rust-lang.org/?version=stable&mode=release&edition=2021&gi…

Ruby ezek szerint tud float-ot és double típust kezelni?

Itt jegyzem meg érdekességként, Lua 5.2-ig kizárólag double típust ismert, integeres feladatokat is double-val számolta, hiszen az 53 bites mantissza veszteség nélkül bírta a 32 bites integert kezelni.
Aztán az 5.3-ban lett bevezetve az integer alacsony szintű típus.

Nem tudom, meg ugy 2009-2010 korul nezegettem a luat komolyabban, hogy mikrokontrolleren mennyire konnyu c-vel keverve hasznalni, kiszervezni a kod egy reszet, akkor ugy dontottem, hogy nem eri meg. Most mar tudom, hogy fejlodott (ESP-n pl.).

Par evvel kesobb meg iGO-hoz irtam kodot (beepitetten lua-t hasznal scriptelesre), aminel lua oldalrol lehet Androidos intentet kuldeni. Nem volt bonyolult, csak meg kellett oldani, hogy a lua->c->java hivas menjen.

Kb. ennyi tapasztalatom van a nyelvvel.

A strange game. The only winning move is not to play. How about a nice game of chess?

Arra tippelnék hogy csak double van, az MRI implementációban ezt nem néztem meg. Lehet hogy a matematikai kerekítésekkel operál inkább. Lásd az alábbit, ahol veszteség nélkül vissza tudja szorozni:

a = 2 / 3.0

=> 0.6666666666666666

a * 3

=> 2.0

Szerk.: Megnéztem, csak double-t használ.

https://ruby-doc.org/core/Float.html

A Float object represents a sometimes-inexact real number using the native architecture's double-precision floating point representation.

Ilyen az élet, amikor az ember nem csak 1..2 nyelvet ismer. Látja, mi van eltalálva és mi az, ami az évek során kevésbé mutatkozik elegáns megoldásnak.
Az biztos, ha lenne Pythonból erősen típushű változat, arra tuti áttérnék. A mypy megtetszett, de sajnos ez sem kényszeríti ki eléggé.

Az a trend, hogy az ujabb verziok egyre inkabb kikenyszeritik, ha megadsz tipust. Ugy ertve, hogy ha rossz tipus kerulne oda, akkor szol. Szoval nyugodtan ird tipussal a kododat, es valtoztatas nelkul menni fog kesobb is.

A strange game. The only winning move is not to play. How about a nice game of chess?

( persicsb | 2022. 04. 20., sze – 10:18 )

Az 1 tényleg nem true, és nem is false, mert az egész szám az nem logikai érték. Nem értem a problémádat.

( p2pking | 2022. 04. 20., sze – 14:03 )

PHP mellett az egyik leginkabb nem zold programnyelv.

Tessek rustot hasznalni.

Every single person is a fool, insane, a failure, or a bad person to at least ten people.

Igen, ez is igaz. Siman tud egy automata tesztelo, biologus, fizikus is python kodot irni. Vagy hasznalhatja kicsit okosabb szamologepkent. Igazabol meg terminal sem kell, Jupyterbe bongeszobe is irhato.

A strange game. The only winning move is not to play. How about a nice game of chess?

( kantal | 2022. 04. 20., sze – 22:15 )

Python 3.9.7 (default, Sep 10 2021, 14:59:43)  
Type 'copyright', 'credits' or 'license' for more information
IPython 7.20.0 -- An enhanced Interactive Python. Type '?' for help.

In [1]: int(True)
Out[1]: 1

In [2]: bool(1)
Out[2]: True

 

eutlantis

Egy 0-as szamjegyet tartalmazo string int-re konvertalva a 0-as szam lesz, a 0 boolkent meg False.

A 0-as szamjegyet tartalmazo string nem ures, marpedig az ures string lenne False. Bool-ra konvertalva az erteke igy True lesz, ami int-kent 1.

szerk: Akkor mar ez viccesebb:

>>> int(bool(str(0)))
1

A strange game. The only winning move is not to play. How about a nice game of chess?

A standard típusú objektumok, az üres string, az üres lista, az üres dict, az üres sokaság (tuple), az üres készlet (set) stb. bool értéke mind False. Ha nem üresek, akkor meg True. (Ha saját objektumot készít az ember, akkor definiálhatja annak a bool értékét is, annak függvényében, hogy az objektumot milyen állapotában tekinti "üresnek" vagy "nem üresnek".)

eutlantis

Nekem is készlet, de biztosan azért, mert az egyik első python tankönyvem kantal műve volt. :) Ezúton is köszönöm, szuper könyv, hatalmas tudásanyag.

“The basic tool for the manipulation of reality is the manipulation of words. If you can control the meaning of words, you can control the people who must use them.”

― Philip K. Dick

Pontosabbnak vélem a készlet elnevezést. Egy halmaz tartalmazhat azonos elemeket, de a pythonos set objektum nem, éppen ez a lényege. A halmaz elnevezéssel inkább a pythonos listát lehet illetni, mert abba mindent bele lehet dobálni, még saját magát is. De a hétköznapi meggondolás alapján is, például egy szerszámkészletnél arra gondolok, hogy minden eszközből csak egyet tartalmaz; no persze, ez már az étkészletre nem igaz :-)

eutlantis

> egy halmaznak egy objektum csak egyszer eleme.

Ez bizony így van, ezért írhatjuk le nyugodtan azt, hogy R\{0}, nem kell aggódnunk, hogy esetleg egy másik 0 is eleme a halmaznak.

És a set szerintem is halmaz, de inkább set.

Debian - The "What?!" starts not!
http://nyizsa.blogspot.com

na, de legalabb kiderult, hogy ez a sajat magyaritasod. szerintem ez helytelen, es a halmaz helyes - ahogy persicsb is irta, egy elemet egyszer tartalmazhat matematikailag, es 100%-ig biztos vagyok, hogy a python keszitoi (mint minden mas nyelv keszitoi is) ezert hivjak halmaznak a strukturajukat, nem mondjuk zoknisfioknak.

Doksi szerint:

Set objects also support mathematical operations like union, intersection, difference, and symmetric difference.

 

Az, hogy nevesitett matematikai halmazmuveleteket lehet vegezni rajta, az nem volt kicsit gyanus neked? :)

NetBSD - Simplicity is prerequisite for reliability

Az első gondolatom nekem is az volt, hogy legyen az objektum neve magyarul "halmaz", de mivel a fejemben összekeveredett a halmaz elavult és újkori definíciója (több évtizede tanultam már),  és a "halmaz" kifejezés, ahogy korábban írtam, hétköznapi értelemben az "összehordottság" érzetét kelti, és mivel a 'set'  egyik jelentése a "készlet", így ez mellett döntöttem.

Az elnevezés ilyetén megválasztása a könyvemben semmilyen logikai- vagy értelmezési problémát nem okoz, minden teljesen helytálló.

A matekot jól és/vagy a több programnyelvet ismerő olvasóban azonban felmerülhet a kérdés, hogy miért nem "halmaz" lett a "set", azaz miért nem a többi programnyelvben szokásos elnevezést választottam. Egy programozási nyelvben több olyan objektumtípus is létezhet, és tetszőleges mennyiségben definiálhatunk olyan újabbakat, amelyeken halmazműveleteket lehet végezni, és nyilván nem nevezhetjük mindannyiukat "halmaznak", bár megpróbálhatjuk ezt az elnevezésbe valahogy beleerőltetni (pl. "frozen set" -> "befagyasztott halmaz"). Az kétségtelenül igaz, hogy legalább egy standard objektumnál, mint amilyen a set, meg kellett volna említenem a "halmaz" elnevezést is, és ez meg is fog történni a könyv 3. kiadásában, egyetlen mondatban, valahogy így: "Egy 'set' típusú objektumra a továbbiakban halmazként illetve készletként fogunk utalni."

eutlantis

Sajnos a "szakmai" fordítások általában meghagyják az eredeti kifejezéseket, vagy ha nem, akkor inkább félrefordítanak vagy egyáltalán nem magyaros kifejezést eredményeznek; ezért voltam kénytelen a magyarításba belefogni, azaz éppenhogy nem l'art pour l'art módon.

eutlantis

Sajnos a "szakmai" fordítások általában meghagyják az eredeti kifejezéseket

És ez így van rendjén, különösen azoknál a kifejezéseknél, amiket az IDE-be beírva működő programkódot kapunk.

Ebből lesznek az olyan remekművek, mint a sendmail->levélküld vagy a többi leiterjakab.

Semmiféle programkódról nem volt szó. Nem keyword-öket magyarítottam, minden kódpéldában a 'set' szerepel, minden művelet megnevezése "halmazművelet", csupán a magyarázó szövegben szerepel a "készlet" szó.

"Ebből lesznek az olyan remekművek, mint a sendmail->levélküld vagy a többi leiterjakab." Ezektől engem is kiráz a hideg.

De lassan már a háborút is a nyakamba varrod.

eutlantis

Most NagyZ-vel értek egyet, annyi különbséggel, hogy lehetőleg maradjon set, ha mindenképpen le akarjuk fordítani, akkor viszont halmaz. A készlet egy esetben elfogadható, ha a másik alternatíva a szett. :))

Debian - The "What?!" starts not!
http://nyizsa.blogspot.com

( kantal | 2022. 04. 21., cs – 16:00 )

No, nem külön-külön, hanem egyszerre válaszolok a "set" elnevezésével kapcsoltos előző kritikákra.

Matematikai szempontból jogos az a felvetés, hogy inkább "halmaznak" kellene nevezni a set-et, de én nem a matematikai névmegfelelést tartottam elsődleges szempontnak. A könyvem megírása előtt a Pythonnal kapcsolatos írásokban leginkább a "set" kifejezéssel találkoztam, és nem a "halmazzal". Nem csak matematikusok programoznak Pythonban, és a tapasztalatom szerint a nem matematikusok többségének fejében a halmaz valami "összehordott", rendezetlen kupac. A "készlet" ezzel szemben sugall valamiféle struktúrát. A könyvemben ugyan az objektumot készletnek nevezem, de a rajta végezhető műveleteket következetesen halmazműveleteknek, és ez nem ellentmondás, egy objektum orientált nyelvben, mint a Python, bárki készíthet saját osztályt, amelyre halmazműveleteket is deklarálhat, és ezért még nem lesz kötelező ezen típusú objektumokat halmaznak neveznie. A set egy python objektum, a halmaz egy matematikai, nem lehet őket egy az egyben megfeleltetni, mert más dimenzióban léteznek. Például egy halmazba bármilyen matematikai objektum betehető (javítsatok ki, ha nem így van), de egy pythonos set-be csak hashable típusú pythonos objektumok, és biztosan találnánk még más eltéréseket is.
Egyébként társalgáskor senkit sem szoktam kijavítani, hogy más elnevezést kellene használnia, mert szerintem egyformán megfelelő mindhárom, a legegyértelműbb természetesen a 'set', csak ugye, az nem magyarul van, és itt most a magyarításról volt szó.
Milyen definícióját tanultam a halmaznak? Az előbb leírtak szerint ennek nincs nagy jelentősége.

eutlantis

Majdnem jol tippeltem. Kell neki egy __eq__ is.
https://docs.python.org/3/glossary.html#term-hashable

hashable

An object is hashable if it has a hash value which never changes during its lifetime (it needs a __hash__() method), and can be compared to other objects (it needs an __eq__() method). Hashable objects which compare equal must have the same hash value.

Hashability makes an object usable as a dictionary key and a set member, because these data structures use the hash value internally.

Most of Python’s immutable built-in objects are hashable; mutable containers (such as lists or dictionaries) are not; immutable containers (such as tuples and frozensets) are only hashable if their elements are hashable. Objects which are instances of user-defined classes are hashable by default. They all compare unequal (except with themselves), and their hash value is derived from their id().

A strange game. The only winning move is not to play. How about a nice game of chess?

Tudtommal nincs, de nem ismerem annyira a Python belso mukodeset, csak hasznalom.

A tisztan OO Java az, ahol kenyelmes, hogy van egy Object osztaly, amibol minden szarmazik. Leszarmazottat ugye hasznalhatsz barhol az os helyett, emiatt jo, ha van ilyen hierarchia (ami Java eseten fa, mert nincs tobbszoros orokles). Ezen kivul nem tudom, hogy mas nyelven van-e ilyen kozos os, nem talalkoztam mashol vele.

A Python nem tisztan objektum-orientalt, es egy csomo dolog csak futasidoben derul ki a nyelv jellege miatt. Viszont pont ezert nem erdekli a hierarchia, a kulonbozo interface-ek, ha jelen van a megfelelo metodus, onnantol orul neki. Extrem esetben amugy None-ra tudsz allitani metodusokat, szoval meg az is lehet, hogy a leszarmazott nem jo oda, ahova az os meg jo volt (persze ezt csak direkt tudod elrontani, veletlenul nem).

szerk:
Hulyeseget irtam, kiprobaltam egy ures osztallyal, es van. builtins.object a neve, egy __dict__ meg egy __weakref__ jott belole.

A strange game. The only winning move is not to play. How about a nice game of chess?

A tisztan OO Java az, ahol kenyelmes, hogy van egy Object osztaly, amibol minden szarmazik.

Kivéve a primitív típusok (int, boolean stb.), amik miatt nem is szokás a Javát "tisztán OO"-nak tekinteni. :) (Egyébként a static metódusok sem igazán "tisztán OO" konstrukciók, de ebbe a nyelvi "workaroundba" ritkábban szokás belekötni ebből a szempontból, pláne, ha nagyon akarjuk, akkor be lehet erőszakolni őket a modellbe, csak épp számos alapelvet sértenek.)

Leszarmazottat ugye hasznalhatsz barhol az os helyett, emiatt jo, ha van ilyen hierarchia (ami Java eseten fa, mert nincs tobbszoros orokles).

Azért ebbe a zárójeles részbe az interface-ek default metódusai Java 8 óta egy picit belepiszkálnak, azóta lehet "többszörös öröklés" implementáció tekintetében is, és okozhat is gondot (aminek a feloldása programozói feladat). Előtte csak "interfész" vagy másnéven "típus" tekintetében volt erre lehetőség.

 

A pythonhoz nem igazán értek, bár amit leírtál, az a "duck typing" tankönyvi példája. :)

Javaban minden az osztalyokon belul van, meg a main is. Ezert indulnak olyan "elegansan" a java programok a public static void main-nel. Valoban a primitiv tipusok hatekonysag miatt kicsit kulon vannak (azert kellenek a wrapperek, pl. Integer), de ettol fuggetlenul a Javat inkabb tekintem OO-nak, mint a Pythont, ahol az int is objektum (viszont irhatsz egeszen nagy kodokat is anelkul, hogy leirnad, hogy "class"). De javat minimalisan hasznaltam, ahhoz valoszinuleg te ertesz jobban.

A duck typing-ban igazad van, emiatt erdekes kevesbe, hogy ki kibol oroklodik. Ha repul, tud uszni, es hapog, akkor kacsa, hiaba oroklodik a dinoszauruszokbol.

A strange game. The only winning move is not to play. How about a nice game of chess?

A duck typing-ban igazad van, emiatt erdekes kevesbe, hogy ki kibol oroklodik. Ha repul, tud uszni, es hapog, akkor kacsa, hiaba oroklodik a dinoszauruszokbol.

Igen, ez egy dinamikusan típusos nyelvben könnyedén megtehető. Ettől még az öröklés mint koncepció hasznos, és nem feltétlenül szükséges osztályokat használni hozzá, lásd prototípus alapú öröklés pl. JavaScriptben* vagy Luában.

* bár ES 6 óta van class kulcsszó, az lényegében csak syntax sugar, a szemantika maradt a régi.

A tisztan OO Java az, ahol kenyelmes, hogy van egy Object osztaly, amibol minden szarmazik.

Kivéve a primitív típusokat, emiatt van azoknak referencia típus megfeleltetése, autoboxing, külön tömb típusok, stb. Egyébként a Top típus mellett hasznos lenne még egy Unit típus (bár van Void, de azért az nem az igazi), illetve egy Bottom típus is. Példaként említeném a Scala, Kotlin és TypeScript nyelveket ahol teljes a hierarchia.

Leszarmazottat ugye hasznalhatsz barhol az os helyett

Gondolom itt leszármazott példányra gondolsz, amire ez igaz. De ha típusokról beszélünk érdemes megemlíteni, hogy ez kontravariancia esetén megfordulhat és az ős típust is használhatod, pl. override-olt metódus paraméterében.

Huh, ez eléggé nagy káosz. Egy programozási nyelvben, és programozói eszközkészletben ennél nagyobb rend van.

Nem arról van szó, hogy akik használnak pythont, matematikusok-e, hanem arról, hogy a programozók mit értenek set alatt. És matematikai halmazt. Minden programnyelvben, ahol van ilyen nevű kollekció típus, matematikai halmazt jelent.
https://docs.oracle.com/javase/8/docs/api/index.html?java/util/Set.html
A collection that contains no duplicate elements. More formally, sets contain no pair of elements e1 and e2 such that e1.equals(e2), and at most one null element. As implied by its name, this interface models the mathematical set abstraction.

 

https://docs.microsoft.com/en-us/dotnet/api/system.collections.generic…

This interface provides methods for implementing sets, which are collections that have unique elements and specific operations.

 

https://www.cplusplus.com/reference/unordered_set/unordered_set/

Unordered sets are containers that store unique elements in no particular order, and which allow for fast retrieval of individual elements based on their value.

De nézzük meg a Python dokumentációját: 
https://docs.python.org/3/tutorial/datastructures.html#sets
Python also includes a data type for sets. A set is an unordered collection with no duplicate elements.

A fenti kommented csak egy eléggé erőtlen magyarázkodás. A halmaz valóban egy rendezetlen dolog (nincs rendezési reláció definálva az elemekre), és nincs is a halmaznak semmiféle struktúrája. Egyik progrmaozási platformon sem.