Nejlepší odpověď
Otázka je poměrně vágní. Znaky v Pythonu jsou obvykle obsaženy a zpracovávány v řetězcích. Funkce len () (integrovaná) vrací délku většiny kontejnerů v Pythonu (včetně řetězců). To je tedy jeden druh „počtu“.
Pokud chcete počítat výskyty každého znaku zvlášť, například za účelem generování histogramových dat, můžete vytvořit slovník, který namapuje každý znak na váš počet a iteruje přes řetězce nebo text a průběžně aktualizujte hodnoty svého slovníku. Nebo můžete použít instanci třídy Counter pro modul sbírky ve standardu knihovny.
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.
Instance třídy Counter mohou počítat cokoli, co lze vyhodnotit jako iterovatelný hashovatelných objektů.
If máte na mysli počítat znaky jiným způsobem, podle některých dalších kritérií budete muset být mnohem konkrétnější.
Odpověď
No, můžete použít len () funkce, ale navrhuji, abyste tento jazyk opustili tak rychle, jak jste jej zadali takto:
> echo -n "hello world"|python -c "import os; os.system("wc -c")"
11
Haha, nah. Louis Parkes udělal dobrou odpověď. Ale mohu vám říci, co se stane, když zavoláte Pythonu:
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)
Ztratíte 3,8 MB RAM za pouhé volání.
> 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, to je „nepatrný“ rozdíl, když děláte totéž. Faktor 100. A toto bude čím dál tím horší, čím větší budou vaše projekty. A to jsem ještě nezmínil velikost sdílených knihoven, které jsou … obrovské a mnoho jako legie. Python funguje víceméně stejně jako LuaJIT, ale je třicetkrát pomalejší. Použil bych valgrind na LuaJIT, ale existuje známá chyba valgrind, která havaruje na LuaJIT, takže jsem vzal 5.2. Ale není tam velký rozdíl. A nezačnu podrobně popisovat drastické úniky paměti, které jsou v Pythonu oficiální, a ne stovky megabajtů, které se načtou jako systémové knihovny a které zůstanou ve vašem systému rezidenty.
Spouštěcí časy jsou také mnohem pomalejší s Pythonem, mluvím o faktoru více než 10krát, což se stává bolestivým, pokud ve vašem OS běží spousta malých skriptů, které v Pythonu udělal nějaký „génius“ a který zpomaluje čas zavádění faktorem 10. To mě nijak neimplikuje, dovedete si představit. Naučte se něco lepšího, neztrácejte na tom svůj talent, pokud vás k tomu profesor nebo učitel nepřinutí.
Neříkám: učte se Luo. Myslím tím, že funguje pro mě, ale nejsem ty. Jen říkám, naučit se něco jiného. Opravdu cokoli. Jen ne ty humbuk jako Julia, Go, Haskell nebo vade retro satanas Java. Přesto jsou všechny lepší než Python. Existuje pouze jeden jazyk horší než Python, a tím by byl Ruby, který je o něco horší než Malbolge. Pokud je jazyk schopen být pomalejší než Python, je v něm něco vážně špatného a vývojáři se vysmívají všemu, co dokonce i zdaleka páchá jako efektivita. Nejhorší kódování v tomto jazyce, nemám vážně tušení, jak se jim podařilo dostat své věci tak pomalu, možná půjčují část výpočetní síly bitcoinovému horníkovi v pozadí? Nemám tušení.
Takže si to rozmyslete.