Python - jak rozdzielić liczbę na jej cyfry (jedności, dziesiątek itd.)

Question

Moje pytanie jest zasadniczo proste a mianowicie jak rozdzielić liczbę na jej cyfry (jedności, dziesiątek itd.)  i nie chodzi mi o byle jaki sposób tylko taki który by zajmował jak najmniej czasu na wykonanie. Z góry dziękuje za pomoc.

Answer 1

Myślę że sposób z dzieleniem przez 10 oraz modulo był by najszybszy.

def rozdziel(n):
    cyfry=[]
    while n>0:
        cyfry.append(n%10)
        n//=10
    return cyfry[::-1]

liczba=123
print(rozdziel(liczba))

 

Comments

Tylko gdzie jest napisane że używanie angielskich zmiennych to dobra praktyka? To jest subiektywne zdanie.

Moje poirytowanie wynika z czegoś innego. Nie wiem czy to zrozumiesz czy nie, ale zajmuję się programowaniem dłużej niż większość z tu dyskutujących żyje na tym świecie. Angielskiego za Komuny w szkole nie było i programiści z tamtych czasów nie używali nazw zmiennych innych niż polskie. I jakoś dało się pisać dobre kody. A dzisiaj przyjdzie na takim forum nastolatek młodszy od moich dzieci i mówi mi że jestem złym programistą bo nie używam angielskiego...

---

A dzisiaj przyjdzie na takim forum nastolatek młodszy od moich dzieci i mówi mi że jestem złym programistą bo nie używam angielskiego...

Nikt nie mówi, że ty personalnie jesteś złym programistą. Nikt kto to dobrze przemyśli, nie powie też, że pisanie kodu po polsku lub łamanie jakiejś dobrej praktyki z automatu czyni z kogoś złego programistę.

Tylko gdzie jest napisane że używanie angielskich zmiennych to dobra praktyka? To jest subiektywne zdanie.

Jak już mówiłem, przecież dobre praktyki nie są zapisane w jednym miejscu w jakiejś świętej księdze. Mogą się zmieniać, ewoluować i z swej natury są pewnym uogólnieniem. Za tego typu zasadami stoją pewne argumenty, nie jest to jakaś nienawiść do języka polskiego, ani chęć bycia postępowym na siłę.

Pisanie kodu po polsku, w czasach komunizmu w Polsce, oczywiście mogło nie być złą praktyką, (wszyscy chyba są w stanie zrozumieć, że kiedyś nie było takiej globalizacji jak dziś) i nie też ma problemu żeby rozmawiać o tym czy teraz jest czy nie jest.

W dzisiejszych czasach nie musimy nawet zbyt dobrze znać angielskiego, żeby stosować go w kodzie. Znajomość tego języka zaczyna być jedną z podstawowych umiejętności w dzisiejszym świecie i jest coraz bardziej rozpowszechniona.

Nie jest więc to problemem żeby pisać kod po angielsku. A skoro nie jest to problem, to jeśli pisanie kodu po polsku ma jakieś wady, to pisanie kodu po angielsku automatycznie staje się dobrą praktyką.

Teraz więc przedstawię dwie najczęściej podawane wady programowania w języku polskim/zalety pisania po angielsku.

1) Kod może czytać każdy. W czasach githuba jest to bardzo ważne. Nawet nasz najmniejszy projekt może być obejrzany przez kogoś z antypodów

2) języki programowania mają słowa kluczowe po angielsku. Tak częste przestawianie się pomiędzy słówkami w różnych językach nie rozwija mózgu, tylko jest obciążające

---

1) Kod może czytać każdy. W czasach githuba jest to bardzo ważne. Nawet nasz najmniejszy projekt może być obejrzany przez kogoś z antypodów

1a) Są również szczególne przypadki w postaci: jeśli chcesz zgłosić issue na githubie lub pytanie na stackoverflow, to angielski automatycznie zrozumieją :)

---

1) Kod może czytać każdy. W czasach githuba jest to bardzo ważne. Nawet nasz najmniejszy projekt może być obejrzany przez kogoś z antypodów

To już zakrawa na absurd. Jak będę wystawiał kod na świat to oczywiście będę pisał po takiemu żeby świat zrozumiał. Póki co to wystawiam tylko na polskie forum. Analogcznie można powiedzieć że polskie gwiazdy youtuba co mają miliony wejść powinny nagrywać po angielsku...

---

To już zakrawa na absurd

Wcześniej w mojej wypowiedzi wykazałem, że jeśli oba rozwiązania wydają się być równie łatwe do zastosowania, to wystarczy jedna wada, żeby uznać drugie rozwiązanie za dobrą praktykę (co nie oznacza, że trzeba je wszędzie na siłę stosować.

Jeśli jest to dobra praktyka, to ją stosujmy, dzięki temu stanie się ona normą i osoby początkujące również będą ją stosować.

 

 

To nie jest taki absurd jak może się wydawać. Dość często przeglądam różne projekty na githubie  i mogę wiedzieć o co chodzi w kodzie, właśnie dzięki temu, że twórcy nie piszą w swoim ojczystym języku. Mimo iż może się wydaważ, że pojedyńcze repozytorium, ma małe szanse na to, że zobaczy je ktoś zza granicy.

 

Moje postawę mocno utwierdziła pewna sytuacja sprzed kilku miesięcy. Znajoma z Ukrainy zaczęła uczyć się C++'a i pokazała mi kilka programów. Pewnie domyślasz się, że zmienne były ponazywane cyrylicą. I można kłócić, że i tak mogę wiedzieć gdzie są wykorzystywane konkretne zmienne i co robią, ale chyba rozumiesz o co mi chodzi...

Answer 2

Najmniej czasu na wykonanie?
Przekonwertuj liczbę na napis. Pobierz każdą cyfrę osobno. I na koniec przekonwertuj ją na liczbę.

Comments

Stanowczo nie!

---

Dopiero teraz zwróciłem uwagę, że autor pytania chciał najwydajniejsze rozwiązanie a nie najszybsze do napisania 

---

A gdzie to jest napisane? Ja tam widzę że chodzi na jak najmniej czasu na wykonanie. Ale wykonanie czego? Wg mnie wykonanie napisania funkcji. A nie czas wykonania konwersji przez program. Dodatkowo za tym przemawia fakt że autor to jest jakiś noname z nowym kontem nowicjusz w programowaniu.

---

We fragmencie

i nie chodzi mi o byle jaki sposób

na który zupełnie nie zwróciłem uwagi

---

To o niczym nie świadczy

---

Mocno sugeruje.

Właśnie dlatego w dziedzinach ścisłych trzeba być precyzyjnym podczas opisu problemu.

Zdanie

sposób (...)który by zajmował jak najmniej czasu na wykonanie

można zrozumieć na dwa sposoby:
- najwydajniejszy algorytm (shortest runtime execution)
- najszybszy do napisania (shortest development)

Właśnie przez tą niejednoznaczność wybraliśmy drugą opcję.
Ale spokojnie, nie ma się co denerwować.

---

Masz racje. Ale moje rozwiązanie (najkrótsze do napisania)ktoś zminusował jak rozumiem właśnie z powodu innego zrozumienia zadania, a to już nie jest fajne.

Answer 3

def rozdziel(liczba):
    return list(str(liczba))

print(rozdziel(32821))