Here an informal list in random order of things that I may like to add or to remove to/from Python3.x+.
The things I list here don't come from fifty hours of thinking of mine, and they may be often wrong. But I use Python2.x often enough, so such things aren't totally random either. To remove: map and filter (ex-ifilter/imap). I don't use them often enough, because generator expression are an obvious way to map and filter, and to me they seem usually good enough. (So far ShedSkin has done well without map/filter). (they can be moved into the itertools module, of course). To add: I use groupby often enough, so I may like to see it as a builtin. To change and improve: the API of the "re" module. I think several of its APIs can be improved and made more intuitive, reducing both memory and cognitive load. Despite having used the re module many times I need still to look up details into the docs. So its API may be bad. To add: Python3 is much more lazy-flavour than Python 2.x (see lazy range, lazy dict views, etc). So islice becomes even more useful and more commonly used. So I may like to have a lazy slicing as built-in. But if you make it built-in, then why not add a syntax too? So I'd like the usual slicing syntax [::] to be added to all lazy generators too (to generator expressions, as an automatically created method of iterators, and of course usable by iterable classes too). Examples: >>> foo = (i for i in range(2, 1000) if all(i % d for d in range(2, i))) >>> list(foo[3: 14]) [7, 11, 13, 17, 19, 23, 29, 31, 37, 41, 43] >>> def bar(): ... for i in range(2, 1000): ... if all(i % d for d in range(2, i)): ... yield i ... >>> list(bar()[3: 14]) [7, 11, 13, 17, 19, 23, 29, 31, 37, 41, 43] To change: + is a commutative operation, while the concatenation of two sequences is not. So after using the D language for some time I have started to not appreciate anymore to use + to concatenate strings and lists. D language uses ~ for such operation (this isn't a perfect symbol, because I don't have it on my keyword, so on Windows I have to type ALT+126 to insert it, or I have to redefine/remap a keyboard key). D also has a specific operator that can be overloaded: opCat, opCat_r and opCatAssign, that map to ~ and ~= (the _r is the inverted order, like the __radd__): http://www.digitalmars.com/d/2.0/operatoroverloading.html#Binary So if you define a vector-like collection you can define both opAdd and opCat, the first may the sum between two vectors and the opCat is their joining. To add: in Python3 you use lazy constructs much more often, so itertools.chain may become more used. So it may be good to have chain as built-in. But then it can be good to have a better syntax support too. So I'd like all lazy iterables to support chaining. If you use the ~ operator you can write: range(100) ~ (i for i in range(2, 1000) if all(i % d for d in range(2, i))) (I have implemented most of itertools in D language, and I have added this ~ operator to all lazy constructs, plus I have added an easy way to add it to user-defined lazy iterables). Unladen Swallow for official CPython 2.x/3.x: yes, thank you, if it will be good enough. It can be what Psyco isn't able to become, and what PyPy has so far failed to be (PyPy seems Open Souce public-money- funded vaporwere that has tried to do too much). To add again: tuple unpacking in function arguments: it's handy, hi- level, de-clutters the code and shortens it too. To change: I'd like {:} as empty dict literal, and {} as empty set literal. To do nothing: probably I will never fully like the syntax of tuple literals. It's not clean. But in practice I can live with it, and I have so far failed to invent a better syntax. The main problem is that ASCII (and keyboards too, maybe) was created for business purposes and it has too few delimiters. While the sytax for lists: [] [1] [1, 2, 3] is perfect. To add: I use defaultdicts often enough, so I may even like to see it as built-in. But this isn't essential, using the import from the collections module is usually acceptable. Bye, bearophile -- http://mail.python.org/mailman/listinfo/python-list