Python-ideas October 2019

python-ideas@python.org

70 participants
45 discussions

Add kwdefaults parameter to function constructor
by Gus Wiedey 18 Oct '19

18 Oct '19

I was recently playing around with decorators and experimenting with defining a function's signature dynamically at runtime, and came across the builtins.function class constructor (more easily accessible through the types.FunctionType alias). I quickly realized, however, that even though the constructor has a parameter (argdefs) that is used to specify default values for the resulting function's positional arguments, there is no corresponding parameter for keyword-only argument defaults. This seems like a glaring omission, especially considering the fact that argdefs takes a tuple that is directly assigned (unmodified) to the __defaults__ attribute. I can't find any obvious reason why there shouldn't be a similar "kwdefs" parameter that takes a dict and assigns it to __kwdefaults__. I downloaded the cpython repo, made this change myself as proof-of-concept, and compiled it, and it appears to work fine. This brings me to two questions: 1. Is there a reason for this disparity that I'm not seeing (e.g. breaking some other feature), or is it just an oversight? 2. If I wanted to submit this as an actual language change, would I need to write a full PEP or is it small enough that it could go to the issue tracker? (Note that the documentation says this constructor can vary between implementations, so the change would only apply to cpython if that matters.) Also, if this is the wrong place to ask this, please feel free to set me straight; I'm completely new to this whole process, so any help on where to start would be appreciated.

4 5

Add collections.abc.Struct as virtual base class of namedtuple classes and dataclass-decorated classes.
by Steve Jorgensen 17 Oct '19

17 Oct '19

I feel like this proposal is not quite right, but maybe the idea will provoke some thoughts about something similar that -would- be right. The idea first came to me upon realizing that since `namedtuple` classes have no special base class beyond `tuple`, there should be some way of identifying them as being primarily structural, even though they are instances of `tuple` which, in other cases, usually means something that is primarily sequential. It is easily possible to identify a namedtuple by checking to see whether it has an `_asdict` method, but it might be nice to formalize the way that struct-like objects are identified in a virtual base class and be something that had application beyond just checking whether a `tuple` is a `namedtuple`.

8 15

Additional meanings for "in" operator and ability to customize implementation
by Steve Jorgensen 15 Oct '19

15 Oct '19

Note that I'm new to this system, so I'm not sure if this will format correctly or whether I'll be able to edit it afterward to format it properly if not. Fingers crossed. Examples: import re from collections import Sequence # Equivalent of re.compile(r'b.d').search(<str>) re.compile(r'b.d') in 'abcdef' # -> <_sre.SRE_Match object; span=(1, 4), match='bcd'> re.compile(r'b.d') in 'xyz' # -> None # Equivalent of isinstance([1, 2], Sequence) [1, 2] in Sequence # -> True class BrightColorsMeta(type): def __rin__(self, other): other.startswith('bright ') class BrightColors(metaclass=BrightColorsMeta): pass 'red' in BrightColors # -> False 'bright blue' in BrightColors # -> True

12 24

Add Scalar to collections.abc with str, bytes, etc. being both Scalar and Sequence (therefore also Container)
by Steve Jorgensen 15 Oct '19

15 Oct '19

This is a far more modest alternative to https://mail.python.org/archives/list/python-ideas@python.org/thread/ZP2OKY… and is also something that could be reasonably & easily implemented in 3.x. Add `Scalar` to `collections.abc`. The meaning of `Scalar` is that the object is generally to be treated as an atomic value, regardless of whether it is also technically a container. The obvious application of an object being both a `Container` and a `Scalar` is to stringlike objects, but there might also be other kinds of standard object for which it would be useful and that I have not thought of. One reason for wanting to designate strings as `Scalar` is for navigating a hierarchy of collections in which, even though a string is a collection, we want to treat it as a leaf of the tree rather than drilling down into its characters (each of which is represented as a string of 1 character — `type('xyz'[1])` -> `str`) Example implementation (for addition to _collections_abc.py): class Scalar(metaclass=ABCMeta): __slots__ = () @classmethod def __subclasshook__(cls, C): if cls is Scalar: if not issubclass(C, Collection): return True return NotImplemented Scalar.register(str) Scalar.register(bytes) Scalar.register(bytearray)

6 14

Set operations with Lists
by Richard Higginbotham 14 Oct '19

14 Oct '19

I'm not sure if there is any interest by others but I have frequently come across cases where I would like to compare items in one list in another similar to relational algebra. For example are the file names in A in B and if so return a new list with those items. Long story short, I wrote some functions to do that. They are quite simple and fast (due to timsort in no small part). Even the plain python code is faster than the built in set functions (afaik). I created a github and put the ones I thought the community might like in there. https://github.com/ponderpanda/listex an example would be a = [1,2,3,4,5,6] b = [1,3,7,4] list_intersection(a,b, sorta=True, sortb=True) returns [1,3,4] The complexity ends up being about the longer of list a or b. if they are over some thousands the speed difference with set() operations becomes significant. There are some details about naming, unique values (not necessary), and sort order that would probably need to be ironed out if they were to be included with the built in list type. I'm not qualified to do that work but I'd be happy to help. Best Regards, Richard Higginbotham

10 65

Why not accept lists or arbitrary iterables in str.endswith?
by Soni L. 14 Oct '19

14 Oct '19

I'm parsing configs for domain filtering rules, and they come as a list. However, str.endswith requires a tuple. So I need to use str.endswith(tuple(list)). I don't know the reasoning for this, but why not just accept a list as well?

3 6

Resolve append/add API inconsistency between set and list
by Steve Jorgensen 14 Oct '19

14 Oct '19

Currently, it is not possible to use a single method name to add an item to a collection that might be a set or a list. There have been other requests for a "push" method to be a complement to "pop", so if that were added to both set and list (synonym for <set>.add and <list>.append) that would solve the issue. Additionally, there have been other requests for an operator for adding to a collection, and in some other languages such as C++ and Ruby, "<<" is used for the same or similar purposes. Perhaps both "push" and "__lshift__" could be added as synonymous operations.

12 33

Allow with block (context manager) to return a value (e.g. to use as a builder)
by Steve Jorgensen 13 Oct '19

13 Oct '19

it would be nice to be able to use the "with" block syntax to do things like implement a builder. To do this, the with block must be able to return a final value to the surrounding context ass part of its __exit__ behavior. obj = with builder() as b: … This would be a little like what can be done in Ruby by passing a {…} block argument to a function.

5 7

Re: Add Subscriptable ABC
by Neil Girdhar 11 Oct '19

11 Oct '19

On Fri., Oct. 11, 2019, 2:38 a.m. Neil Girdhar, <mistersheik(a)gmail.com> wrote: > > > On Fri, Oct 11, 2019 at 2:28 AM Andrew Barnert <abarnert(a)yahoo.com> wrote: > >> > On Oct 10, 2019, at 22:13, Neil Girdhar <mistersheik(a)gmail.com> wrote: >> > >> > That's funny, I always thought of that as legacy. The iterator >> protocol has been a special case in so many proposals I've seen on this >> list. I think it's really ugly. Instead of >> collections.abc.OldStyleSequence, what do you think of adding something >> like InfiniteSequence to collections.abc instead? It's basically Sequence >> without __len__, __reversed__, or __count__. I don't see it getting much >> use though. >> >> Are you proposing that this type isn’t allowed to have those methods (as >> opposed to just not being required to)? > > > Not required. Just like if we added a row to the table. So, the point of > this mixin would be to implement __contains__ __iter__ and __index__ given > __getitem__. > > >> If so that would be a unique ABC, and a pretty weird one. If not, isn’t >> this exactly equivalent to the original proposal, but just with a different >> name? And I think it’s a pretty misleading name. Especially if the subclass >> hook is structural (method-check), because then it would pick up Sequence >> and Mapping types even though they aren’t infinite sequences. For that >> matter, not even every useful old-style sequence is infinite; that’s just >> the most obvious example everyone comes up with first. >> > > Yeah, those are all good points. After sending, I realized, that it would > be nicer as a base class of Sequence. I guess I'm for the proposal then. > I skipped reading the big debate about structural checks because I think if > you really care about this, you should probably either inherit from the ABC > or register yourself with it. > > Anyway, I guess we pretty much agree then. I just wanted to push against > legitimizing the sequence protocol in favor of explicitly inheriting from a > mixin (whatever you want to call it, GenericSequence? AbstractSequence? > PossiblyInfiniteSequence?) Inheritance like this is a nice declaration of > intent. Even if you just implemented __getitem__, I think you would have > to have a comment to make the code clear anyway. > > >> Anyway, I don’t want to put words in Steven’s mouth; maybe this would fit >> what he wanted. But I suspect it wouldn’t. >> >

1 0

Add Subscriptable ABC
by Steven D'Aprano 11 Oct '19

11 Oct '19

I keep finding myself needing to test for objects that support subscripting. This is one case where EAFP is *not* actually easier: try: obj[0] except TypeError: subscriptable = False except (IndexError, KeyError): subscriptable = True else: subscriptable = True if subscriptable: ... But I don't like manually testing for it like this: if getattr(obj, '__getitem__', None) is not None: ... because it is wrong. (Its wrong because an object with __getitem__ defined as an instance attribute isn't subscriptable; it has to be in the class, or a superclass.) But doing it correctly is too painful: if any(getattr(T, '__getitem__', None) is not None for T in type(obj).mro()) and besides I've probably still got it wrong in some subtle way. What I'd really like to do is use the collections.abc module to do the check: if isinstance(obj, collections.abc.Subscriptable): ... in the same way we can check for Sized, Hashable etc. Alternatively, if we had a getclassattr that skipped the instance attributes, I could say: if getclassattr(obj, '__getitem__', None) is not None: ... (1) Am I doing it wrong? Perhaps I've missed some already existing solution to this. (2) If not, is there any reason why we shouldn't add Subscriptable to the collection.abc module? I think I have the implementation: class Subscriptable(metaclass=ABCMeta): __slots__ = () @abstractmethod def __getitem__(self, idx): return None @classmethod def __subclasshook__(cls, C): if cls is Subscriptable: return _check_methods(C, "__getitem__") return NotImplemented Comments, questions, flames? -- Steven

18 43

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

Python-ideas October 2019