Konwersja tekstu na liczbę całkowitą pojawia się wszędzie tam, gdzie dane przychodzą z formularza, pliku CSV, API albo z funkcji input(). W Pythonie zamiana string na int sprowadza się zwykle do jednego wywołania int(), ale w praktyce ważniejsze od samej składni są: poprawny format wejścia, obsługa błędów i świadomy wybór podstawy liczbowej. W tym artykule pokazuję, kiedy taki zapis działa od razu, kiedy trzeba najpierw oczyścić dane i jak uniknąć błędów, które początkujący popełniają najczęściej.
Najważniejsze informacje w skrócie
-
int()zamienia tekst na liczbę całkowitą, ale tylko wtedy, gdy napis rzeczywiście wygląda jak liczba. -
input()zawsze zwraca tekst, więc przy danych od użytkownika konwersja jest zwykle konieczna. - Najczęstszy problem to
ValueErrorprzy znakach, którychint()nie potrafi zinterpretować. - Spacje na brzegach, znak
+lub-i pojedyncze podkreślenia między cyframi mogą być akceptowane. - Jeśli liczba ma inny zapis niż dziesiętny, użyj
int(tekst, base), na przykład dla binarnego lub szesnastkowego formatu. - Przy danych z przecinkiem, spacjami wewnątrz liczby albo separatorami tysięcy najpierw trzeba je normalizować.
Co naprawdę oznacza zamiana tekstu na liczbę
Żeby dobrze rozumieć tę operację, trzeba odróżnić dwa światy: tekst i typ liczbowy. str przechowuje znaki, a int jest liczbą całkowitą, więc interpreter nie zgaduje wartości, tylko próbuje odczytać zapis zgodnie z regułami liczb całkowitych. Dlatego int("123") działa bez problemu, a int("123px") już nie.
Warto też pamiętać o różnicy między tekstem a liczbą, która już istnieje w pamięci jako obiekt numeryczny. Gdy argumentem jest float, int() nie zaokrągla klasycznie, tylko obcina część ułamkową w stronę zera. int(3.9) da więc 3, a int(-3.9) zwróci -3. To drobny szczegół, ale w praktyce często decyduje o tym, czy wynik jest poprawny, czy tylko „prawie poprawny”.
Ja patrzę na to tak: jeśli mam napis, który ma reprezentować liczbę, to nie „konwertuję” go magicznie, tylko parsuję, czyli odczytuję jego znaczenie według reguł liczbowych. Gdy już wiadomo, jak działa mechanizm, można przejść do najprostszego użycia int().
Najprostszy sposób w Pythonie
Najkrótsza odpowiedź brzmi: użyj int(). To wystarcza, jeśli tekst naprawdę zawiera liczbę całkowitą, na przykład int("42") albo int(" -7 "). W przypadku danych od użytkownika często łączę to od razu z input(), bo ta funkcja zawsze zwraca tekst, nawet gdy ktoś wpisuje same cyfry.
liczba = int(" -12_345\n")
print(liczba) # -12345
wiek = int(input("Podaj wiek: "))
print(wiek + 1)Ten przykład dobrze pokazuje dwie praktyczne rzeczy. Po pierwsze, int() potrafi zignorować białe znaki na brzegach i przyjąć zapis z -. Po drugie, pojedyncze podkreślenia między cyframi nie są przeszkodą, więc int("1_000") też działa. To przydatne, ale ja i tak nie polegam na tym bez potrzeby, jeśli dane przychodzą z zewnętrznego systemu.
| Wejście | Wywołanie | Wynik | Co pokazuje |
|---|---|---|---|
"42" |
int("42") |
42 |
Najprostszy przypadek |
" -7 " |
int(" -7 ") |
-7 |
Spacje na brzegach są dozwolone |
"1_000" |
int("1_000") |
1000 |
Pojedyncze podkreślenia między cyframi |
"12.5" |
int("12.5") |
Błąd | To nie jest liczba całkowita |
Jeśli potrzebujesz innego zapisu niż dziesiętny, int() przyjmie też drugi argument określający podstawę. To już prowadzi do szerszego tematu: co zrobić, gdy konwersja się nie powiedzie albo wejście nie jest czystą liczbą.
Skąd bierze się ValueError i jak go obsłużyć
Najczęstszy problem to ValueError. Pojawia się wtedy, gdy ciąg znaków nie pasuje do oczekiwanego zapisu liczby całkowitej, na przykład "12a", "" albo "3.14". Komunikat w stylu invalid literal for int() oznacza po prostu, że tekst nie wygląda jak poprawny zapis liczby dla tej funkcji.
Ja zwykle obsługuję to tam, gdzie dane wchodzą do programu, a nie kilka funkcji później. Najprostszy wariant wygląda tak:
tekst = input("Podaj liczbę: ").strip()
try:
liczba = int(tekst)
except ValueError:
print("To nie jest poprawna liczba całkowita.")
else:
print(f"Przyjęta wartość: {liczba}")Warto unikać zbyt naiwnych testów, takich jak samo isdigit(). Taka metoda nie obsłuży liczby ujemnej, nie uwzględni spacji i potrafi sprawiać wrażenie bezpiecznej wtedy, gdy wcale nie rozwiązuje problemu. W praktyce lepiej zaufać int() i złapać ValueError niż pisać własną, niepełną walidację.
Jeśli dane pochodzą z formularza, pliku lub API, obsługa błędów powinna być częścią normalnego przepływu, a nie wyjątkiem dodanym „na wszelki wypadek”. Żeby ograniczyć liczbę takich przypadków, zwykle najpierw przygotowuję dane do konwersji.
Jak przygotować dane przed konwersją
W realnych projektach wejście bywa brudne: z dodatkowymi spacjami, separatorami tysięcy albo lokalnym formatem liczby. Najbezpieczniej zacząć od prostych operacji typu strip(), a dopiero potem decydować, czy potrzebny jest replace(), wyrażenie regularne, czy zupełnie inny parser.
Ja rozdzielam dwa scenariusze. Jeśli mam wpływ na format danych, upraszczam go do jednego standardu. Jeśli danych nie kontroluję, normalizuję je bardzo ostrożnie, bo zbyt agresywne usuwanie znaków potrafi zmienić znaczenie liczby. To szczególnie ważne przy separatorach tysięcy i przecinku dziesiętnym.
| Przykład wejścia | Co zrobić | Dlaczego |
|---|---|---|
" 15 " |
strip() |
Usuwa zbędne białe znaki na brzegach |
"1 000" |
Usuń spacje tylko wtedy, gdy format jest pod kontrolą | Spacja może oznaczać separator tysięcy albo błąd danych |
"1,234" |
Normalizuj tylko wtedy, gdy przecinek jest separatorem tysięcy | W innym kontekście przecinek może mieć znaczenie dziesiętne |
"12,5" |
Nie wrzucaj bezpośrednio do int()
|
To zapis liczby ułamkowej, więc trzeba najpierw ustalić regułę parsowania |
"1_000" |
Można użyć int(), ale przy danych z zewnątrz lepiej zachować jednolity format |
Python akceptuje ten zapis, lecz nie każdy system go generuje |
Jeśli liczba może mieć część ułamkową, najpierw parsuję ją jako float albo Decimal po normalizacji zapisu, a dopiero potem decyduję, czy chcę zaokrąglenie, obcięcie czy odrzucenie wartości. To drobna decyzja, ale bardzo ważna, bo int("12,5") nie rozwiązuje problemu, tylko go maskuje.
Po oczyszczeniu danych zostaje jeszcze jeden ważny temat: system liczbowy.
Kiedy przydają się inne podstawy liczbowe
Nie każda liczba pojawia się w zapisie dziesiętnym. W kodzie technicznym często spotyka się zapis binarny, ósemkowy albo szesnastkowy, więc wtedy zamiast zwykłegoint("42") używam drugiego argumentu funkcji.
print(int("1011", 2)) # 11
print(int("17", 8)) # 15
print(int("FF", 16)) # 255
print(int("0xFF", 0)) # 255Drugi argument base pozwala też na automatyczne rozpoznanie prefiksów, gdy ustawisz 0. To przydatne, jeśli dane mogą przyjść w jednej z kilku postaci i nie chcesz pisać kilku osobnych parserów. Warto pamiętać, że Python akceptuje podstawy od 2 do 36, więc takie rozwiązanie jest bardziej elastyczne, niż wielu początkujących zakłada.
W praktyce oznacza to, że zapis 0b1010 stanie się liczbą dziesiętną 10, a 0xFF zamieni się w 255. Jeśli pracujesz z flagami bitowymi, identyfikatorami zapisanymi szesnastkowo albo danymi z urządzeń, ta umiejętność bardzo ułatwia życie. W codziennym kodzie najczęściej wystarcza jednak prosty schemat decyzyjny.
Jak wybieram właściwy wariant w praktyce
Jeśli mam streścić to w jednym zdaniu, to najpierw sprawdzam, czy wejście jest już poprawnym tekstem liczby, a dopiero potem decyduję o czyszczeniu lub zmianie podstawy. To pozwala uniknąć dwóch skrajności: zbyt luźnego parsowania i przesadnego kombinowania tam, gdzie wystarcza zwykłe int().
- Jeśli dane są czystym zapisem liczby całkowitej, używam
int()bez dodatkowych kroków. - Jeśli wejście pochodzi od użytkownika, dodaję
strip()itry/except. - Jeśli format zawiera separatorem tysięcy albo lokalne znaki, normalizuję go przed konwersją.
- Jeśli liczba może być ułamkowa, nie udaję, że da się ją bezpiecznie wrzucić do
int()bez decyzji o zaokrągleniu. - Jeśli pojawia się zapis binarny albo szesnastkowy, jawnie ustawiam
base.
To podejście jest proste, ale właśnie dlatego działa w praktyce. Przy konwersji tekstu na liczbę całkowitą najważniejsze nie jest samo wywołanie funkcji, tylko rozpoznanie, jaki dokładnie format danych masz przed sobą i czy wolno go bezpiecznie przekształcić bez utraty sensu.
