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
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.
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?
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
> 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.
