Paras vastaus
Kysymys on melko epämääräinen. Pythonissa olevat merkit sisältyvät tavallisesti merkkijonoihin. len () -funktio (sisäänrakennettu) palauttaa useimpien Pythonissa olevien säilöjen (mukaan lukien merkkijonot) pituuden. Joten se on eräänlainen ”laskenta”.
Jos haluat laskea jokaisen merkin esiintymät erikseen, esimerkiksi histogrammitietojen luomiseksi, voit rakentaa sanakirjan, yhdistää kukin merkki omaan lukumäärääsi, iteroida merkkijonojen tai tekstin yli ja päivität sanakirjan arvot mennessäsi. Tai voit käyttää vain Laskuri -esimerkkiä standardin kokoelmat -moduulille. kirjastot.
from collections import Counter
counts = Counter(somestring)
# counts now contains a dictionary like mapping of item counters
counts.update(morestuff)
# counts have been updated with new items and additional occurrences of previously
# seen item.
Laskuriluokan esiintymät voivat laskea kaiken, mikä voidaan arvioida hajautettavien objektien iteroitavaksi.
Jos aiot laskea merkkejä jollakin muulla tavalla, joidenkin muiden kriteerien mukaan, sinun on oltava paljon tarkempi.
Vastaa
No, voit käyttää len () mutta suosittelen, että menet ja jätät kyseisen kielen niin nopeasti kuin olet kirjoittanut sen tällä tavalla:
> echo -n "hello world"|python -c "import os; os.system("wc -c")"
11
Haha, nah. Louis Parkes teki hyvän vastauksen. Mutta voin kertoa sinulle, mitä tapahtuu, jos soitat Pythonille:
11263> valgrind python -c "print(len("hello world"))" 2>&1|tail -n15
==31376== HEAP SUMMARY:
==31376== in use at exit: 417,246 bytes in 199 blocks
==31376== total heap usage: 3,324 allocs, 3,125 frees, 3,807,322 bytes allocated
==31376==
==31376== LEAK SUMMARY:
==31376== definitely lost: 0 bytes in 0 blocks
==31376== indirectly lost: 0 bytes in 0 blocks
==31376== possibly lost: 528 bytes in 1 blocks
==31376== still reachable: 416,718 bytes in 198 blocks
==31376== suppressed: 0 bytes in 0 blocks
==31376== Rerun with --leak-check=full to see details of leaked memory
==31376==
==31376== For counts of detected and suppressed errors, rerun with: -v
==31376== Use --track-origins=yes to see where uninitialised values come from
==31376== ERROR SUMMARY: 529 errors from 43 contexts (suppressed: 0 from 0)
Tuhlaat 3,8 Mt RAM-muistia vain soittamalla siihen.
> valgrind lua5.2 -e "print(#"hello world")" 2>&1|tail -n15
==32388== Memcheck, a memory error detector
==32388== Copyright (C) 2002-2017, and GNU GPL"d, by Julian Seward et al.
==32388== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
==32388== Command: lua5.2 -e print(#"hello\ world")
==32388==
11
==32388==
==32388== HEAP SUMMARY:
==32388== in use at exit: 0 bytes in 0 blocks
==32388== total heap usage: 305 allocs, 305 frees, 34,487 bytes allocated
==32388==
==32388== All heap blocks were freed -- no leaks are possible
==32388==
==32388== For counts of detected and suppressed errors, rerun with: -v
==32388== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
34 kb, se on ”pieni” ero saman tekemisessä. Kerroin 100. Ja tämä pahenee ja pahenee, mitä isompiin projektiisi tulee. Enkä vielä maininnut jaettujen kirjastojen kokoa, jotka ovat … valtavia ja monet legioonana. Python tekee enemmän tai vähemmän saman kuin LuaJIT, mutta se on 30 kertaa hitaampi. Olisin käyttänyt valgrindia LuaJIT: ssä, mutta LuaJIT: ssä kaatuu tunnettu valgrind-vika, joten otin 5.2. Mutta eroa ei ole paljon. Enkä aio käsitellä Pythonissa virallisia dramaattisia muistivuotoja eikä niitä satoja megatavuja, jotka ladataan järjestelmäkirjastoiksi tälle ja jotka pysyvät järjestelmässäsi.
Käynnistysajat ovat myös paljon hitaampia Pythonissa, puhun yli 10-kertaisesta tekijästä, josta tulee tuskallista, jos käyttöjärjestelmässäsi on käynnissä paljon pieniä komentosarjoja, joita jotkut nero tekivät Pythonissa ja jotka hidastavat käynnistyskerroin kertoimella 10. En ole siitä vaikuttunut, voitte kuvitella. Opi jotain parempaa, älä tuhlaa kykyjäsi siihen, jos professori tai opettaja ei pakota käyttämään sitä.
En sano: opi Lua. Tarkoitan, että toimii minulle, mutta en ole sinä. Sanon vain, oppia jotain muuta. Kaikki, todella. Ei vain hypedit, kuten Julia, Go, Haskell tai vade retro satanas Java. Silti kaikki ovat parempia kuin Python. On vain yksi kieli, joka on huonompi kuin Python, ja se olisi Ruby, joka on vain vähän huonompi kuin Malbolge. Jos kieli onnistuu olemaan hitaampi kuin Python, siinä on jotain vakavasti vikaa ja kehittäjät paskaavat kaikkea, mikä jopa kaukaa kaipaa tehokkuutta. Pahin koodaus tällä kielellä, minulla ei ole vakavasti aavistustakaan, kuinka he onnistuivat saamaan tavaransa niin hitaasti, ehkä he lainaavat osan laskentatehosta taustalla olevalle bitcoin-kaivosmiehelle? Minulla ei ole aavistustakaan.
Ajattele siis kahdesti.