Brendan Miller: > Currently people slice and dice with well... slices, but those are > copying, so if you want to operate over part of a range you make a > copy, perform the operation, then copy the results back in. > > I was thinking you'd want something like random access iterators in > c++, or pointers in c, to write typical in place algorithmic code. To > me, something like non-copying slices (maybe you'd call it a list > view?) would seem functionally similar and maybe more pythonic.
There are surely ways to modify the current situation, introducing views, and other kind of iterators (C++ design in this regard can be improved, see the last works of Andrei Alexandrescu about D). This can lead to a certain increase of the performance of Python programs, but it also surely makes writing programs harder and introduces new bug sources. Modern languages are now doing something kinda different from what you ask for, introducing more immutable data (that in theory lead to more copying, but in practice allow for more data sharing too, because there's less need to actually copy data when the data is immutable), see Clojure. An hypothetical Python language designed today probably copies more stuff from Haskell and Clojure. Python is kept intentionally simple, because it's designed to be usable by people that are not just professional programmers, but for example a biologist that needs to perform some computations and doesn't want to use all the time learning how to use the language itself (think about C++ again). So Python programmers live with a less performing language. When performance of the code is not enough (even with the future Unladen Swallow), they use another language (often to write extensions used from Python code). Bye, bearophile -- http://mail.python.org/mailman/listinfo/python-list
