Mailman 3 April 2017 - Python-ideas

What about regexp string litterals : re".*" ?
by Simon D. April 3, 2017

April 3, 2017

Hello, After some french discussions about this idea, I subscribed here to suggest adding a new string litteral, for regexp, inspired by other types like : u"", r"", b"", br"", f""… The regexp string litteral could be represented by : re"" It would ease the use of regexps in Python, allowing to have some regexp litterals, like in Perl or JavaScript. We may end up with an integration like : >>> import re >>> if re".k" in 'ok': ... print "ok" ok >>> Regexps are part of the language in Perl, and the rather complicated integration of regexp in other languages, especially in Python, is something that comes up easily in language comparing discussion. I've always felt JavaScript integration being half the way it should, and new string litterals types in Python (like f"") looked like a good compromise to have a tight integration of regexps without asking to make them part of the language (as I imagine it has already been discussed years ago, and obviously denied…). As per XKCD illustration, using a regexp may be a problem on its own, but really, the "each-language a new and complicated approach" is another difficulty, of the level of writing regexps I think. And then, when you get the trick for Python, it feels to me still to much letters to type regarding the numerous problems one can solve using regexps. I know regexps are slower than string-based workflow (like .startswith) but regexps can do the most and the least, so they are rapide to come up with, once you started to think with them. As Python philosophy is to spare brain-cycles, sacrificing CPU-cycles, allowing to easily use regexps is a brain-cycle savior trick. What do you think ? -- Simon Descarpentries +336 769 702 53 http://acoeuro.com

14 24

pathlib.Path.walk
by Michel Desmoulin April 3, 2017

April 3, 2017

Like os.walk, but from a Path instance. We have Path.iterdir, but it's not recursive. Which you use either os.scandir, or os.walk. In any case, you end up doing: import os import pathlib directory = pathlib.Path(get_dir()) # do things with directory for root, dirs, files os.walk(directory): root = Path(root) for f in files: f = root / f # do something with file Which is not that bad, but you waste a lot of time discovering how to do that since you look first for something like Path.walk.

2 2

Introduce BaseTimeoutError
by Ram Rachum April 2, 2017

April 2, 2017

Today I got burned because I had code that did this: except TimeoutError: When it should have done this: except socket.timeout: There's also another timeout error class in asyncio. Initially I thought, why not make them all use the same exception class? But Guido objects to that: I considered this, and decided against unifying the two TimeoutErrors. First the builtin TimeoutError is specifically a subclass of OSError representing the case where errno is ETIMEDOUT. But asyncio.TimeoutError means nothing of the sort. Second, the precedent is concurrent.futures.TimeoutError. The asyncio one is used under the same conditions as that one. I think we should just update the links in the docs to be correct. So here's my idea: Define a new base class `BaseTimeoutError` and have it be a base class of all other timeout errors. This way people could do: except BaseTimeoutError: And it'll catch all of them. I thought of doing it myself as an abc, but if I remember correctly the except logic ignored __subclasshook__ or __instancecheck__ or whatever is used by abc, so I think this can only work by modifying CPython. What do you think?

5 4

Construct a matrix from a list: matrix multiplication
by Chris Angelico April 1, 2017

April 1, 2017

This keeps on coming up in one form or another - either someone multiplies a list of lists and ends up surprised that they're all the same, or is frustrated with the verbosity of the alternatives. Can we use the matmul operator for this? class List(list): def __matmul__(self, other): return [copy.copy(x) for x in self for _ in range(other)] >>> x = List([[0]*4]) @ 2 >>> x [[0, 0, 0, 0], [0, 0, 0, 0]] >>> x[0][0] = 1 >>> x [[1, 0, 0, 0], [0, 0, 0, 0]] If this were supported by the built-in list type, it would be either of these: >>> x = [[0] * 4] @ 2 >>> x = [[0] @ 4] @ 4 (identical functionality, as copying an integer has no effect). The semantics could be either as shown above (copy.copy()), or something very simple and narrow like "lists get shallow-copied, other objects get referenced". Thoughts? ChrisA

5 5

Re: [Python-ideas] unify usage of mutable and immutable objects
by 语言破碎处 April 1, 2017

April 1, 2017

> To me, 'pop' implies mutation. Tuples do not have a pop method, and it > is not obvious to me that either tuples or frozensets should. What are > the use cases that are not better served by converting to list or set? > -- > Terry Jan Reedy 1) coverting to set or list is O(n) in time 2) if I have to keep the old copy, standard set solution will be O(n) both in time and space! working examples: 1) priority queue: insert and pop occur 2) share immutable data to difference subroutines: each one can modify local copy safely and concurrency.

3 3