noahmorrison / chevron

A Python implementation of mustache
MIT License
486 stars 52 forks source link

Render any iterable except a string as a list #34

Closed gber closed 5 years ago

gber commented 5 years ago

This should address issue #33

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

gber commented 5 years ago

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.

coveralls commented 5 years ago

Coverage Status

Coverage increased (+0.01%) to 99.149% when pulling 5abf7ebfc0f2196ae3cc0cfd1141090052ea6be2 on gber:master into 467ea90d23f575dea028f42be9fe4fe587a5b3df on noahmorrison:master.

gber commented 5 years ago

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.

gber commented 5 years ago

Hi, would you mind taking a look at the fixed version?