Closed gber closed 5 years ago
Unfortunately this seems to break things.
I'll play around with it for a bit tonight, but feel free to add more commits yourself if you think you've fixed it.
The problem is that not only string-like but also dict-like types (which are also iterable) need to be excluded in this case. Maybe we could check whether the type is derived from the abstract base class "Sequence" but I don't know whether that works for python2.
I need to have another close look at the python type system when I have a bit more time to see which check would be most appropriate. It would be nice if it worked with as many iterable types as possible and also with generators.
OK, I've reworked the patch and I think I've fixed the checks for the needed functionality while also making this change more general by eliminating the use of type()
altogether. The type()
function only determines the immediate type of the given object and does not even match derived types. This means that e.g. the recently added support for callables does not actually support callables such as class and object methods or callable classes implementing __call__
but only plain functions. A more pythonic approach is to use isinstance()
where necessary (e.g. in order to distinguish strings from other sequences) or to check for the required functionality either by simply using them and catching exceptions or by using isinstance()
in combination with abstract base classes which allow for convenient checking for certain groups of functionality. This makes it possible for library consumers to pass in their custom data types as long as they implement the required functionality without tediously converting them to the exact types the chevron code is explicitly checking for.
Hi, would you mind taking a look at the fixed version?
This should address issue #33