Mailman 3 December 2019 - Python-ideas

lowercase exception names trip-up .
by Matthias Bussonnier 07 Dec '19

07 Dec '19

I've been tripped up a couple of time by a few Exception names being lower case both in code and tracebacks. In particular `error` (all lower case) I tend to read `error` as a function instead of a class. According to my non-scientific grep-foo, I find that ~ 300 descendant from Exceptions start with an upper case: ~/dev/cpython[master ✗] $ rg '^[ ]*class [A-Z][a-zA-Z]+\(' | grep Excep | wc -l 333 18 of those are `Error` uppercase: ~/dev/cpython[master ✗] $ rg '^[ ]*class Error\(' | wc -l 18 but 4 are lower case: ~/dev/cpython[master ✗] $ rg '^[ ]*class [a-z][a-zA-Z]+\(' | grep Exception Lib/sre_constants.py:class error(Exception): Lib/imaplib.py: class error(Exception): pass # Logical errors - debug required Doc/faq/design.rst: class label(Exception): pass # declare a label Lib/dbm/__init__.py:class error(Exception): ... there are probably others if they don't directly inherit from Exception of course. My question is in two part: 1) For consistency would it make sens to try to capitalize – where possible – Exceptions names ? For example `error` to `Error` (keeping error as an alias for backward compatibility for now). 2) If (1), would it be ok to actually give a better name to some of those exceptions ? e.g: Lib/sre_constants.py:class error to CompileError for example. Thanks.

5 8

Argumenting in favor of first()
by Juancarlo Añez 06 Dec '19

06 Dec '19

I just found this code: def get_product_item(jsonld_items): for item in jsonld_items: if item['@type'] == 'Product': return item else: return {} My argument is that the intent is clearer in: def get_product_item(jsonld_items): return first((item for item in jsonld_items if item['@type'] == 'Product'), {}) As a reminder, first()'s definition in Python is: def first(seq, default=None): return next(iter(seq), default=default) It could be optimized (implemented in C) if it makes it into the stdlib. -- Juancarlo *Añez*

8 12

Allow user extensions to operators [related to: Moving PEP 584 forward (dict + and += operators)]
by Random832 05 Dec '19

05 Dec '19

What if there was a general mechanism to allow operators to be implemented by user code that does not belong to the class? If the name [e.g.] __operatorhook_or__ is defined anywhere in a module, within that module all calls to that operator are replaced with a two-step process: call __operatorhook_or__(dict1, dict2) if it returns a value, use that value if it returns NotImplemented use the ordinary operator lookup process, i.e. dict1.__or__ and dict2.__ror___ [if __operatorhook_or__ is not defined, treat the same as if it had returned NotImplemented] Then a user could simply do: def __operatorhook_or__(obj1, obj2): if isinstance(obj1, dict) and isinstance(obj2, dict): return {**obj1, **obj2} return NotImplemented def __operatorhook_ior__(obj1, obj2): if isinstance(obj1, dict): obj1.update(obj2) return obj1 return NotImplemented

8 15

Archiving Threads / Closing Threads
by Abdur-Rahmaan Janhangeer 05 Dec '19

05 Dec '19

I suggest we find a way to close a mail thread. Obviously we can't stop people from sending mails, but, like when a mod sees the topic has been juiced out, he closes the topic which practically means: if mailman sees mails being sent to a topic closed by a mod, it does not relay it to the list. It is normally difficult to say when a topic has been juiced out (the essentials have been said, with no new inputs). One might close the topic prematuraly. So, a time-based automatic closing might be better. Example: After 5 days, a topic is closed. A mod can extend the closing though. Abdur-Rahmaan Janhangeer http://www.pythonmembers.club | https://github.com/Abdur-rahmaanJ Mauritius

11 15

Re: Fwd: re.findfirst()
by Guido van Rossum 05 Dec '19

05 Dec '19

Well said! On Wed, Dec 4, 2019 at 16:33 Juancarlo Añez <juancarlo.anez(a)gmail.com> wrote: > > > On Wed, Dec 4, 2019 at 3:02 PM Guido van Rossum <guido(a)python.org> wrote: > >> Fair enough. I’ll let the OP defend his use case. >> > > The OP thinks that the case for wanting just the string for a first regex > match, or a verifiable default if there is no match, is way too common, > that the advice on the web is not very good (it should be "write a > findfirst() using next() over finditer()", and that novices default to > using findall(..)[0], which is troublesome. > > The proposed implementation of a findfirst() would handle many common > cases, and be friendly to newcomers (why do I need to deal with a Match > object?), specially if the semantics are those of *findall()*: > > next(iter(findall(...)), default=default) > > BTW, a common function in extensions to *itertools* is *first():* > > def first(seq, default=None): > return next(iter(seq), default= default) > > That function, *first()*, would also be a nice addition in *itertools*, > and *findfirst()* could be implemented using it. *first()* avoids most > use cases needing to check if a sequence or iterator is empty before using > a default value. MHO is that *first()* deals with so many common cases > that it should be a builtin. > > Note that the case for *findfirst()* is weaker if *first()* is available. > Yet *findfirst()* solves the bigger problem. > > -- > Juancarlo *Añez* > tel:+58(414)901-2021 > skype:juancarloanez > -- --Guido (mobile)

3 2

Fwd: re.findfirst()
by Juancarlo Añez 04 Dec '19

04 Dec '19

There are many ugly recipes about to handle the common use case that could be handled by: def findfirst(regex, text, default=None, flags=0): return next(finditer(regex, text, flags=flags), default=default) The matching and return value semantics would be the same as those of *re.findall()*, but the search would stop on the first match, or return "default" if there wasn't a match (*findfirst()* will return a tuple when more than one group is matched). Typically programmers will use: matched = re.findall(regex, text)[0] which is inefficient, and incorrect when there is no match. Typically, the pattern for the use case will be: m = re.search(regex, text) if m: matched = m.groups() else: matched = default nowadays: matched = m.groups() if (m := re.search(regex, text)) else default The semantics of *findall()* are nicer, and so would be those of *findfirst()*. -- Juancarlo *Añez*

8 15

math.copysign not to introduce float
by Marein 04 Dec '19

04 Dec '19

The math.copysign(x, y) function always returns a float, even when the given x is an int, i.e. math.copysign(3, -1) gives -3.0. This is documented behaviour, but I find it somewhat surprising given that the name suggests that it only copies a sign, and it's also annoying in situations when an int is strictly needed (i.e. as the step argument to range), requiring an additional cast. I'm interested to hear whether it might be a good idea to preserve the int/float type of the argument in math.copysign.

7 8

PEP's shouldn't require a sponsor
by Batuhan Taskaya 03 Dec '19

03 Dec '19

Why do i need to convince a core developer for my PEP? AFAIK the steering council can include non core developers (i know it isn't that current case but for the future this is important). And if the last authority who will approve my PEP is the steering council i just need to convince them not core developers. Sponsors can stay (and they should because guidance is important) but thy shouldn't be mandatory. Let everyone to send their peps.

22 29

namedtuple for dict.items()/collections.abc.Mappings.items()
by Soni L. 01 Dec '19

01 Dec '19

I have a lot of code that looks like this: def filter(self, it, defs): for x in it: for y in _match_helper(self.key, defs, x[0]): yield (y, x[1]) def filter(self, it): for el in it: try: if self.compiled.search(el[0]): yield el elif not self.skippable: raise ValidationError except TypeError: if not self.skippable: raise ValidationError def filter(self, it, ty): for el in it: # this may TypeError if ty is not a type nor a tuple of types # but that's actually the programmer's error if isinstance(el[1], ty): yield el elif not self.skippable: # and this one is for actual validation raise ValidationError It'd be quite nice if dict.items() returned a namedtuple so all these x[0], x[1], el[0], el[1], etc would instead be x.key, x.value, el.key, el.value, etc. It would be more readable and more maintainable.

8 12

Access to member name/names via context during Enum instance initialization
by Steve Jorgensen 01 Dec '19

01 Dec '19

I brought this up before, but I had a kind of weak understanding of `enum.Enum` at the time, so my expression of the issue and proposal for a solution were pretty awkward. Basically, with the current implementation of `Enum` and supporting classes, the only way that a member can have access to its own name during or prior to its initialization is if/when its value is auto-generated, so if you want to specify a value rather than having it auto-generated (e.g. to generate a label attribute) then there's no convenient way to do it. One can work around that by writing the code to make use of the `name` property after installation, but why should we force the developer to write code in an awkward manner when we could simply make the name available to the `__new__ method. It might also be nice to supply the list of all names (in case the value is assigned to multiple names) as well as the primary name. The idea that comes to mind is to pass a `context` object argument to `__new__` with `name` and `names` attributes. To preserve backward compatibility, there could be have a class attribute named something like `_use_context_` (`False` by default) to enable or disable passing that parameter. Going forward, additional attributes could be added to the context without additional backward compatibility concerns. Of course, the exact mechanism could be something completely different, but I'd like to see this or some other mechanism that addresses the concern.

5 12