B
bearophileHUGS
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:
.... if all(i % d for d in range(2, i)):
.... yield i
....
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
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:
.... for i in range(2, 1000):
.... if all(i % d for d in range(2, i)):
.... yield i
....
[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