> Pokud by však platila teze, že čtení prvku seznamu pomocí indexu je pro > velké seznamy pomalé, tak by varianta s enumerate mohla být rychlejší. > Důvodem je to, že získává další hodnotu načtením následujícího prvku v > seznamu (rychlá operace) namísto pomalého přístupu přes index. > Test však ukázal, že uvedená tese neplatí, takže pythovský list() asi není > obyčejný obousměrně svázaný seznam.
A není ani důvod aby byl. Každý trochu zkušený programátor by určitě list neimplementoval vnitřně jako obousměrně vázaný seznam, protože tím získá prakticky jenom nevýhody. O vnitřní implementaci list napovídá to, že Python má tuple a list, tedy dva objekty dělající de facto to samé (pomiňte teď konstantnost tuple) a tipnul bych si tedy že spíše jde o to, že list alokuje paměť pro indexy dopředu, a že se jedná o obyčejné pole s empiricky vyladěnými algoritmy pro minimální počet alokací a trochu plýtvající pamětí, zatímco tuple bude vnitřně to samé co list, akorát alokuje paměť na indexy přesně. Jinak už jen úvaha, že přístup přes index je pomalejší, než cokoli jiného je úchylná, protože si fakt neumím představit, že by někdo implementoval pole (tj. něco s neměnnou lineární řadou celočíselných indexů) tak, aby přístup přes indexy nebyl superrychlý. Zvlášť když přístup k poli přes index je suverénně nejčastěji vyžadovaná operace v programu a tím pádem je logické, že je implmentována s ohledem na maximální rychlost. Ing. Miloslav Ponkrác _______________________________________________ Python mailing list [email protected] http://www.py.cz/mailman/listinfo/python
