Mailman 3 October 2021 - Python-ideas

Allow regex group name redefinitions
by vencik＠razdva.cz 02 Oct '21

02 Oct '21

Hello everybody, I've got a suggestion for the std. re module developers: to consider allowing match group name redefinitions, especially in alternatives. While you may not see the point at first glance, let me try to reason such a thing using a real-world example from my practice: Imagine a company, using certain codes for their products/product components (unfortunately, I'm not at liberty to disclose the true nature of them, but bare with me). Let's say that they may have the following forms: r"(?P<type>AB|C|D)[- ](?P<prefix>[A-Z])?(?P<number>\d+)(?P<postfix>[A-Z])?" So far so good. But now, imagine that a particular type of code has a bit different syntax: r"(?P<type>E)[- ](?P<prefix>[A-Za-z])?(?P<number>\d+)[- ](?P<postfix>[A-Za-z])?" As you can see, the prefix & postfix may be lowercase in case of code type E and moreover, a space or dash is required before the postfix. If I merged the definitions, I'd have to allow that syntax even for the AB, C and D code types---but that would've been incorrect and would require post-matching checks. Ideally I'd like to have the opportunity to define the regex as an alternative: r"(?P<type>AB|C|D)[- ](?P<prefix>[A-Z])?(?P<number>\d+)(?P<postfix>[A-Z])?|(?P<type>E)[- ](?P<prefix>[A-Za-z])?(?P<number>\d+)[- ](?P<postfix>[A-Za-z])?" I can't, of course, getting the re.error: redefinition of group name error upon the regex compilation. But is that really a problem, especially in such alternatives? If you imagine the regex as a FSA, the code type branches into completely independent sub-trees of the automaton state transitions. There's no problem with efficiency; the regex might look a bit complex, but the matching is perfectly efficient---definitely more so than if I match multiple expressions. The redefinition of the match group names is IMO technically perfectly possible and note that in such alternatives, re-assignments won't really happen. And finally, even if they would happen, what's the problem with that? Might be a logical error in the regex definition of course, but that's the programmer's lookout in general... So what do you think? If the match group name redefinition was allowed, I could just match a single regex, getting match group dict and read out parsed parts of the codes by name---nice and easy. Currently, my 2 choices are: 1/ Use uniquely named groups, which requires me to do a post-match group name consolidation of sort or 2/ Match multiple reg. expressions, which is unnecessary Therefore, I ask you to reconsider issuing the error, which I deem redundant and unnecessarily limiting a justified use-case, IMO. Also note that doing that won't break any old code---anything that worked before will continue to work with unchanged semantics; so such a change would be perfectly safe. Thanks, Best Regards vasek

3 2

Reusing more builtins for type-hinting
by Matt del Valle 02 Oct '21

02 Oct '21

In the spirit of 3.9 allowing builtin collections like `list`, `dict`, `tuple`, and `set` to be subscripted for type-hinting to remove the need for importing their equivalents from `typing`, I'd like to propose the same thing for a few other builtin objects, namely: `type` (for use instead of`typing.Type`) `any` (for use instead of `typing.Any`) `callable` (for use instead of `typing.Callable`) (I'm aware that a better syntax for type-hinting callables using arrow-syntax is potentially currently in the works, so maybe this last one can be ignored) Having to explicitly import objects from `typing` for basic type-hinting use-cases is a not-inconsiderable source of frustration preventing their uptake, especially by beginners. 3.9 made a valuable step forward in reducing this friction, but I think we can go further.

7 14

pathlib update idea: iterable Path that returns subpaths
by Aaron Stacy 02 Oct '21

02 Oct '21

I’d like to propose an enhancement to the wonderful pathlib module: make Path instances iterable, where the iterator returns subpaths. This would be functionally very similar to Path(some_directory).rglob(‘*’). Why not just use rglob(‘*’)? While globs are an extremely useful shorthand, in my experience they’re a bit of an artifact of Unix shells that programmers frequently aren’t aware of or don’t understand. Python does a great job of distilling the concept of what it means to iterate over an object. IO objects come to mind, where [line for line in sys.stdin] very intuitively iterates through each line of input. I believe making Path iterable over its sub paths provides a similarly intuitive concept of iterating over a path. Strawman implementation: class Path: # ... def __iter__(self): return self.rglob('*') Questions: If this were added, where in the Path class hierarchy[1] would it belong? [1]: https://docs.python.org/3/library/pathlib.html#module-pathlib

3 2

define an idiomatic way to make a generator that throws StopIteration immediately and add it to PEP8
by Thomas Grainger 01 Oct '21

01 Oct '21

the way to make an (aysnc)generator that immediately raises Stop(Async)Iteration immediately is to insert an unreachable `yield` statement, however there's two ways to do it: def example(): if False: yield or: def example(): return yield currently test_asyncgen.py uses both, eg: @types.coroutine def __anext__(self): if False: yield "this is a generator-based coroutine" if self.yielded >= 2: raise StopAsyncIteration() else: self.yielded += 1 return self.yielded or: async def agenfn(): try: await _async_yield(1) except MyError: await _async_yield(2) return yield the `if False: yield` version has a disadvantage in that it can be anywhere in the function, if this one is chosen then an additional caveat is that it should be the first two statements in a function if `return; yield` version has an disadvantage in that the unreachable yield could be inserted after any `return`, if this one is chosen then an additional caveat is that it should be the last two statements in a function and de-dented as much as syntactically possible. Which alternative do you prefer? I prefer `return; yield`

3 3