Python-ideas October 2019

python-ideas@python.org

70 participants
44 discussions

Add collections.abc.Struct as virtual base class of namedtuple classes and dataclass-decorated classes.

by Steve Jorgensen

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

1 year, 12 months

Additional meanings for "in" operator and ability to customize implementation

by Steve Jorgensen

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

2 years

Add Scalar to collections.abc with str, bytes, etc. being both Scalar and Sequence (therefore also Container)

by Steve Jorgensen

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)

2 years

Set operations with Lists

by Richard Higginbotham

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

2 years

Why not accept lists or arbitrary iterables in str.endswith?

by Soni L.

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?

2 years

Resolve append/add API inconsistency between set and list

by Steve Jorgensen

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.

2 years

Allow with block (context manager) to return a value (e.g. to use as a builder)

by Steve Jorgensen

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.

2 years

Re: Add Subscriptable ABC

by Neil Girdhar

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

2 years

Add Subscriptable ABC

by Steven D'Aprano

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

2 years

Simple feature for argparse.py

by brent bejot

Hello all, Aspiring contributor here. I am not at all certain that this is the right place to discuss this. Do refer me to a better location if I'm out of place. I would like to add a simple feature to the argparse library. I frequently find myself writing small utilities, stylistically similar to unix's "rm" whose main parameter(s) get bundled into a list and it doesn't matter if flags are sprinkled throughout. e.g. "rm foo.txt -f bar.txt" removes both foo.txt and bar.txt forcefully. Doing this in argparse currently is cumbersome at best (though I would be happy to be proved wrong on that), so I rarely implement it as a feature. Of note, calling parser.add_argument with nargs="..." or nargs="A..." or nargs="*" gets close, but will not allow you to intermix other flags between your list. I have a working modification of argparse.py that I could commit, but I know there's several steps between here and there - I just don't know what those steps are. Any direction would be very much appreciated. Thanks!

2 years

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

Python-ideas October 2019