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
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)
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
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?
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.
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.
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.
>>
>
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
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!
Among other places, Python ideas was recommended as a place to goto.
In the meantime I have been discussing this on pypa/pip (mainly), and also on wheel and packaging. Even submitted PRs. But the PRs are only needed if the tag is inadequate.
So, part of my reason for being here is to figure out if I can call the current tag algorithm a bug, or is correcting it a feature?
I am trying to approach this the Python way rather than be seen as a bull in a china shop.
Thanks for replying!
Sent from my iPhone