Podstawowa sk\u0142adnia<\/td> isinstance(obiekt, typ)<\/code><\/td><\/tr>Sprawdzenie wielu typ\u00f3w<\/td> isinstance(obiekt, (int, float, str))<\/code><\/td><\/tr>Wynik<\/td> True<\/code> albo False<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nZwracana warto\u015b\u0107 to zawsze typ logiczny.<\/p>\n\n\n\n
Najwa\u017cniejsze jest to, \u017ce funkcja nie por\u00f3wnuje tylko \u201enazwy typu\u201d, ale bierze pod uwag\u0119 r\u00f3wnie\u017c dziedziczenie klas. To odr\u00f3\u017cnia j\u0105 od prostego por\u00f3wnania z u\u017cyciem type()<\/code>.<\/p>\n\n\n\nPrzyk\u0142ad podstawowy:<\/p>\n\n\n\nJ\u0119zyk<\/th> Kod<\/th><\/tr><\/thead> Python<\/td> python\\nx = 10\\nprint(isinstance(x, int))\\n<\/code><\/td><\/tr>C++ (odpowiednik idei przez RTTI)<\/td> cpp\\n#include <iostream>\\nusing namespace std;\\n\\nclass Base {};\\nclass Derived : public Base {};\\n\\nint main() {\\n Base* obj = new Derived();\\n if(dynamic_cast<Derived*>(obj)) {\\n cout << \\\"Tak\\\";\\n }\\n}\\n<\/code><\/td><\/tr>C (manualna kontrola typu)<\/td> c\\n#include <stdio.h>\\n\\nint main() {\\n int x = 10;\\n printf(\\\"int\\\\n\\\");\\n return 0;\\n}\\n<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nW C nie ma wbudowanego mechanizmu refleksji typ\u00f3w jak w Pythonie, dlatego kontrola typu jest zwykle r\u0119czna. W C++ rol\u0119 zbli\u017con\u0105 pe\u0142ni dynamic_cast<\/code>, ale dzia\u0142a inaczej i g\u0142\u00f3wnie dla klas polimorficznych.<\/p>\n\n\n\nTypowy przypadek u\u017cycia w Pythonie to walidacja argument\u00f3w funkcji:<\/p>\n\n\n\nJ\u0119zyk<\/th> Kod<\/th><\/tr><\/thead> Python<\/td> python\\ndef dodaj_vat(cena):\\n if not isinstance(cena, (int, float)):\\n return \\\"B\u0142\u0119dny typ danych\\\"\\n return cena * 1.23\\n\\nprint(dodaj_vat(100))\\nprint(dodaj_vat(\\\"100\\\"))\\n<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nBez tego sprawdzenia program mo\u017ce zako\u0144czy\u0107 si\u0119 wyj\u0105tkiem lub – co gorsza – wykona\u0107 b\u0142\u0119dne obliczenia bez widocznego b\u0142\u0119du.<\/p>\n\n\n\n
W praktyce to drugie jest gro\u017aniejsze. Awaria jest widoczna. Z\u0142y wynik finansowy zapisany w bazie ju\u017c nie.<\/p>\n\n\n\n
Dlaczego samo type() cz\u0119sto nie wystarcza<\/h3>\n\n\n\n Wiele os\u00f3b zaczyna od takiego zapisu:<\/p>\n\n\n\nKod<\/th><\/tr><\/thead> python\\nif type(x) == int:\\n print(\\\"liczba ca\u0142kowita\\\")\\n<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nTechnicznie dzia\u0142a, ale ma istotne ograniczenie: nie uwzgl\u0119dnia dziedziczenia.<\/p>\n\n\n\n
Je\u017celi klasa potomna rozszerza klas\u0119 bazow\u0105, type()<\/code> uzna je za r\u00f3\u017cne typy, nawet je\u015bli logicznie obiekt powinien by\u0107 akceptowany.<\/p>\n\n\n\nisinstance()<\/code> dzia\u0142a szerzej i zwykle bezpieczniej.<\/p>\n\n\n\nTo szczeg\u00f3lnie wa\u017cne w wi\u0119kszych projektach, bibliotekach i systemach, gdzie klasy s\u0105 rozwijane przez wiele miesi\u0119cy.<\/p>\n\n\n\n
Isinstance \u2013 sprawdza, czy obiekt jest instancj\u0105 okre\u015blonego typu tak\u017ce wtedy, gdy dzia\u0142a mechanizm dziedziczenia klas<\/h2>\n\n\n\n To miejsce, w kt\u00f3rym r\u00f3\u017cnica mi\u0119dzy type()<\/code> a isinstance()<\/code> staje si\u0119 naprawd\u0119 istotna.<\/p>\n\n\n\nZa\u0142\u00f3\u017cmy prost\u0105 hierarchi\u0119:<\/p>\n\n\n\nJ\u0119zyk<\/th> Kod<\/th><\/tr><\/thead> Python<\/td> python\\nclass Zwierze:\\n pass\\n\\nclass Pies(Zwierze):\\n pass\\n\\nobj = Pies()\\n\\nprint(isinstance(obj, Zwierze))\\nprint(type(obj) == Zwierze)\\n<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nWynik:<\/p>\n\n\n\n
\nisinstance(obj, Zwierze)<\/code> \u2192 True<\/code><\/li>\n\n\n\ntype(obj) == Zwierze<\/code> \u2192 False<\/code><\/li>\n<\/ul>\n\n\n\nTo poprawne zachowanie.<\/p>\n\n\n\n
Obiekt Pies<\/code> faktycznie jest specjalnym przypadkiem klasy Zwierze<\/code>, wi\u0119c kod biznesowy powinien zwykle go akceptowa\u0107.<\/p>\n\n\n\nGdy programista u\u017cywa type()<\/code>, cz\u0119sto przypadkowo blokuje klasy potomne i p\u00f3\u017aniej pojawiaj\u0105 si\u0119 trudne do znalezienia b\u0142\u0119dy:<\/p>\n\n\n\n\nsystem nie akceptuje poprawnych danych,<\/li>\n\n\n\n API odrzuca obiekty,<\/li>\n\n\n\n testy przechodz\u0105 lokalnie, ale nie w \u015brodowisku produkcyjnym.<\/li>\n<\/ul>\n\n\n\nW projektach opartych o OOP to bardzo cz\u0119sty problem.<\/p>\n\n\n\n
Praktyczny przyk\u0142ad z systemem p\u0142atno\u015bci<\/h3>\n\n\n\n Wyobra\u017amy sobie klas\u0119 bazow\u0105:<\/p>\n\n\n\nKod<\/th><\/tr><\/thead> python\\nclass Platnosc:\\n def wykonaj(self):\\n pass\\n<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\noraz klasy potomne:<\/p>\n\n\n\nKod<\/th><\/tr><\/thead> python\\nclass Karta(Platnosc):\\n pass\\n\\nclass BLIK(Platnosc):\\n pass\\n<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nWalidacja:<\/p>\n\n\n\nKod<\/th><\/tr><\/thead> python\\ndef obsluz(p):\\n if isinstance(p, Platnosc):\\n print(\\\"P\u0142atno\u015b\u0107 zaakceptowana\\\")\\n else:\\n print(\\\"Niepoprawny obiekt\\\")\\n<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nTakie podej\u015bcie pozwala rozwija\u0107 system bez ci\u0105g\u0142ego przepisywania warunk\u00f3w.<\/p>\n\n\n\n
Je\u015bli za p\u00f3\u0142 roku pojawi si\u0119 nowa metoda p\u0142atno\u015bci, kod nadal b\u0119dzie poprawny.<\/p>\n\n\n\n
To oszcz\u0119dza czas i zmniejsza liczb\u0119 regresji.<\/p>\n\n\n\n
Isinstance \u2013 sprawdza, czy obiekt jest instancj\u0105 okre\u015blonego typu r\u00f3wnie\u017c dla wielu typ\u00f3w jednocze\u015bnie i struktur mieszanych<\/h2>\n\n\n\n Bardzo praktyczna mo\u017cliwo\u015b\u0107 to sprawdzanie kilku typ\u00f3w naraz.<\/p>\n\n\n\n
Zamiast pisa\u0107:<\/p>\n\n\n\nKod<\/th><\/tr><\/thead> python\\nif isinstance(x, int) or isinstance(x, float):\\n print(\\\"liczba\\\")\\n<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nlepiej u\u017cy\u0107:<\/p>\n\n\n\nKod<\/th><\/tr><\/thead> python\\nif isinstance(x, (int, float)):\\n print(\\\"liczba\\\")\\n<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nDrugi argument mo\u017ce by\u0107 krotk\u0105 typ\u00f3w.<\/p>\n\n\n\n
To rozwi\u0105zanie jest czytelniejsze, kr\u00f3tsze i \u0142atwiejsze w utrzymaniu.<\/p>\n\n\n\n
Wa\u017cny szczeg\u00f3\u0142 dotycz\u0105cy bool i int<\/h3>\n\n\n\n W Pythonie:<\/p>\n\n\n\nKod<\/th><\/tr><\/thead> python\\nprint(isinstance(True, int))\\n<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nwynik to:<\/p>\n\n\n\n
True<\/code><\/p>\n\n\n\nDla wielu os\u00f3b jest to zaskoczenie.<\/p>\n\n\n\n
Dlaczego tak si\u0119 dzieje?<\/p>\n\n\n\n
Poniewa\u017c bool<\/code> dziedziczy po int<\/code>.<\/p>\n\n\n\nFormalnie:<\/p>\n\n\n\nKod<\/th><\/tr><\/thead> python\\nprint(issubclass(bool, int))\\n<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nzwraca:<\/p>\n\n\n\n
True<\/code><\/p>\n\n\n\nTo historyczna decyzja projektowa j\u0119zyka.<\/p>\n\n\n\n
W praktyce oznacza to, \u017ce walidacja typu liczbowego mo\u017ce przypadkowo przepu\u015bci\u0107 warto\u015bci logiczne.<\/p>\n\n\n\n
Je\u015bli to problem, trzeba sprawdza\u0107 dok\u0142adniej:<\/p>\n\n\n\nKod<\/th><\/tr><\/thead> python\\nif isinstance(x, int) and not isinstance(x, bool):\\n print(\\\"prawdziwa liczba ca\u0142kowita\\\")\\n<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nPrzy systemach ksi\u0119gowych, raportach lub analizie danych ten detal ma realne znaczenie.<\/p>\n\n\n\n
B\u0142\u0105d typu True + 100 = 101<\/code> potrafi przej\u015b\u0107 niezauwa\u017cony.<\/p>\n\n\n\nPraca z listami i kolekcjami<\/h3>\n\n\n\n Cz\u0119sto sprawdzamy nie tylko pojedyncze warto\u015bci, ale ca\u0142e struktury:<\/p>\n\n\n\nKod<\/th><\/tr><\/thead> python\\ndane = [1, 2, 3]\\n\\nif isinstance(dane, list):\\n print(\\\"to lista\\\")\\n<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nTrzeba jednak pami\u0119ta\u0107, \u017ce to sprawdza typ kontenera, a nie typ jego element\u00f3w.<\/p>\n\n\n\n
Je\u015bli chcemy walidowa\u0107 zawarto\u015b\u0107:<\/p>\n\n\n\nKod<\/th><\/tr><\/thead> python\\nif all(isinstance(x, int) for x in dane):\\n print(\\\"same liczby ca\u0142kowite\\\")\\n<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nTo wa\u017cne np. przy danych z JSON, CSV albo formularzy webowych.<\/p>\n\n\n\n
Typowe pu\u0142apki i b\u0142\u0119dy, kt\u00f3re regularnie pojawiaj\u0105 si\u0119 w codziennej pracy<\/h2>\n\n\n\nNadu\u017cywanie sprawdzania typu zamiast projektowania interfejsu<\/h3>\n\n\n\n Nie ka\u017cdy problem nale\u017cy rozwi\u0105zywa\u0107 przez isinstance()<\/code>.<\/p>\n\n\n\nCzasem lepiej sprawdzi\u0107, czy obiekt posiada potrzebn\u0105 metod\u0119, zamiast pyta\u0107 o jego typ.<\/p>\n\n\n\n
To podej\u015bcie nazywa si\u0119 duck typing.<\/p>\n\n\n\n
Przyk\u0142ad:<\/p>\n\n\n\nKod<\/th><\/tr><\/thead> python\\nif hasattr(obj, \\\"zapisz\\\"):\\n obj.zapisz()\\n<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nZasada jest prosta:<\/p>\n\n\n\n
je\u015bli obiekt zachowuje si\u0119 poprawnie, jego dok\u0142adny typ mo\u017ce by\u0107 mniej istotny.<\/p>\n\n\n\n
Zbyt agresywne sprawdzanie typ\u00f3w cz\u0119sto prowadzi do sztywnego kodu.<\/p>\n\n\n\n
Mylenie isinstance() z issubclass()<\/h3>\n\n\n\n To dwa r\u00f3\u017cne narz\u0119dzia:<\/p>\n\n\n\nFunkcja<\/th> Sprawdza<\/th><\/tr><\/thead> isinstance()<\/code><\/td>obiekt<\/td><\/tr> issubclass()<\/code><\/td>klas\u0119<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nPrzyk\u0142ad:<\/p>\n\n\n\nKod<\/th><\/tr><\/thead> python\\nissubclass(bool, int)\\nisinstance(True, int)\\n<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nOba mog\u0105 zwr\u00f3ci\u0107 True<\/code>, ale odpowiadaj\u0105 na inne pytania.<\/p>\n\n\n\nZak\u0142adanie, \u017ce dane z API maj\u0105 w\u0142a\u015bciwy typ<\/h3>\n\n\n\n To cz\u0119sty b\u0142\u0105d.<\/p>\n\n\n\n
JSON nie gwarantuje jako\u015bci danych. Pole liczbowe mo\u017ce nagle sta\u0107 si\u0119 tekstem albo null<\/code>.<\/p>\n\n\n\nWalidacja typu powinna by\u0107 \u015bwiadoma, szczeg\u00f3lnie:<\/p>\n\n\n\n
\nw integracjach z zewn\u0119trznymi systemami,<\/li>\n\n\n\n przy imporcie danych,<\/li>\n\n\n\n w automatycznych raportach,<\/li>\n\n\n\n w kodzie finansowym i administracyjnym.<\/li>\n<\/ul>\n\n\n\nTu b\u0142\u0119dy kosztuj\u0105 nie tylko czas, ale cz\u0119sto pieni\u0105dze.<\/p>\n\n\n\n
Kr\u00f3tkie uwagi praktyczne z perspektywy utrzymania kodu<\/h2>\n\n\n\n Je\u017celi warunki typu pojawiaj\u0105 si\u0119 w wielu miejscach, warto przenie\u015b\u0107 je do jednej funkcji pomocniczej.<\/p>\n\n\n\n
Przyk\u0142ad:<\/p>\n\n\n\nKod<\/th><\/tr><\/thead> python\\ndef poprawna_kwota(x):\\n return isinstance(x, (int, float)) and not isinstance(x, bool)\\n<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nDzi\u0119ki temu:<\/p>\n\n\n\n
\nlogika jest sp\u00f3jna,<\/li>\n\n\n\n \u0142atwiej zmieni\u0107 regu\u0142\u0119,<\/li>\n\n\n\n testy s\u0105 prostsze.<\/li>\n<\/ul>\n\n\n\nDruga rzecz: nie sprawdza\u0107 typu \u201ena zapas\u201d.<\/p>\n\n\n\n
Walidacja powinna pojawia\u0107 si\u0119 tam, gdzie naprawd\u0119 istnieje ryzyko b\u0142\u0119du, a nie wsz\u0119dzie bez wyj\u0105tku.<\/p>\n\n\n\n
Nadmierna kontrola typu potrafi zamieni\u0107 prosty kod w trudny do utrzymania system warunk\u00f3w.<\/p>\n\n\n\n
FAQ<\/h2>\n\n\n\nCzy isinstance() dzia\u0142a tylko dla typ\u00f3w wbudowanych?<\/h3>\n\n\n\n Nie. Dzia\u0142a r\u00f3wnie\u017c dla w\u0142asnych klas, klas dziedzicz\u0105cych oraz obiekt\u00f3w pochodz\u0105cych z bibliotek zewn\u0119trznych.<\/p>\n\n\n\n
Czy mo\u017cna sprawdzi\u0107 kilka typ\u00f3w jednocze\u015bnie?<\/h3>\n\n\n\n Tak. Drugi argument mo\u017ce by\u0107 krotk\u0105 typ\u00f3w, na przyk\u0142ad (int, float, str)<\/code>.<\/p>\n\n\n\nCzy isinstance() jest lepsze od type()?<\/h3>\n\n\n\n W wi\u0119kszo\u015bci przypadk\u00f3w tak, poniewa\u017c uwzgl\u0119dnia dziedziczenie. type()<\/code> ma sens wtedy, gdy potrzebne jest sprawdzenie dok\u0142adnie jednego konkretnego typu bez klas potomnych.<\/p>\n\n\n\nDlaczego True jest traktowane jak int?<\/h3>\n\n\n\n Poniewa\u017c bool<\/code> dziedziczy po int<\/code>. To cecha j\u0119zyka Python, a nie b\u0142\u0105d programu.<\/p>\n\n\n\nCzy isinstance() spowalnia program?<\/h3>\n\n\n\n Koszt jest bardzo ma\u0142y i w typowych zastosowaniach praktycznie pomijalny. Znacznie wi\u0119kszym problemem s\u0105 b\u0142\u0119dy wynikaj\u0105ce z braku walidacji.<\/p>\n\n\n\n
Czy warto u\u017cywa\u0107 isinstance() w ka\u017cdej funkcji?<\/h3>\n\n\n\n Nie. Najlepiej stosowa\u0107 je tam, gdzie dane pochodz\u0105 z niepewnego \u017ar\u00f3d\u0142a albo gdzie b\u0142\u0119dny typ mo\u017ce wywo\u0142a\u0107 kosztown\u0105 awari\u0119.<\/p>\n\n\n\n
Dobrze u\u017cyte isinstance()<\/code> nie jest dodatkiem kosmetycznym, ale elementem bezpiecze\u0144stwa programu. Szczeg\u00f3lnie w Pythonie, gdzie elastyczno\u015b\u0107 typ\u00f3w jest zalet\u0105 i jednocze\u015bnie \u017ar\u00f3d\u0142em wielu subtelnych b\u0142\u0119d\u00f3w, \u015bwiadoma kontrola typu pozwala unikn\u0105\u0107 problem\u00f3w, kt\u00f3re zwykle wychodz\u0105 dopiero na produkcji.<\/p>\n\n\n\n\u0179r\u00f3d\u0142o Foto: Freepik<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"