Python3: to add, remove and change

MRAB google at mrabarnett.plus.com
Thu Apr 2 10:59:08 EDT 2009


bearophileHUGS at lycos.com wrote:
> Here an informal list in random order of things that I may like to add
> or to remove to/from Python3.x+.
> 
[snip]
> 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]
> 
How about adding [x : y : z] as a shortcut for range(x, y, z)?

 >>> foo = (i for i in [2 : 1000] if all(i % d for d in [2 : 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.
> 
-1.
> 
> 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).
> 
For lazy concatenation/chaining, perhaps +1.
> 
> To add again: tuple unpacking in function arguments: it's handy, hi-
> level, de-clutters the code and shortens it too.
> 
+1.
> 
> To change: I'd like {:} as empty dict literal, and {} as empty set
> literal.
> 
+1.
> 
> 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.
> 
[snip]
Could you wrap tuples in <...>? I'd need to check the syntax to see
whether it's unambiguous.



More information about the Python-list mailing list