Type casting

[DavidtheGoliath]

When trying to reverse this JSON
[
{
"Key": "2",
"A": "B"
},
{
"Key": "1",
"A": "B"
}
]
array we get this error [<list_reverseiterator object at 0x3eb14f722f70>]

[pwwang]

Are you using the standard mode?

Could you share the python code how you call and render your template?

[frikky]

Are you using the standard mode?

Could you share the python code how you call and render your template?

Hey @pwwang!

We're running it in wild mode with python in the https://github.com/frikky/shuffle project, where this issue shows up. The code that runs it all can be found here: https://github.com/frikky/Shuffle/blob/581f97be8029da91ecd43c64abe1359ca1cb5a29/backend/app_sdk/app_base.py#L1767

Hope it helps! :)

[pwwang]

@frikky Thanks for providing the information. It is helpful.

We didn't implement the reverse filter. It is actually a jinja filter:

https://jinja.palletsprojects.com/en/3.0.x/templates/#jinja-filters.reverse

It returns an iterator, instead of a list. If you want a list:

>>> from liquid import Liquid, defaults
>>> defaults.MODE = 'wild'
>>> defaults.FROM_FILE = False
>>> Liquid("{{x | reverse}}").render(x=[1,2,3])
'<list_reverseiterator object at 0x7ff91960c880>'
>>> Liquid("{{x | reverse | list}}").render(x=[1,2,3])
'[3, 2, 1]'

[pwwang]

Assume it is solved. Closing.

[frikky]

Assume it is solved. Closing.

Thanks! Parsing straight to | list will indeed be our goto explainer for now.

Our docs are coming along btw. Here's an extensive list of what we aim to implement and use: Liquid docs. We will also add examples of each and every one of them long-term.

Quick Q about strings: How do you think we could solve the problem of e.g. running something with a filter, but the data is not a string? I'd ideally like to see some kind of auto-casting system, where it assumes something is a string (and e.g. adds the quotes itself), without the need of perfect information left of the pipe. Just wondering how that could be implemented well, as I'm not a parser expert ;)

[pwwang]

The docs look awesome. I will see if I could also contribute to that.

[pwwang]

So here it's a little bit confusing. For example:

out = Liquid("{{ x | plus: 1}}").render(x=1)
# out == "2"
# isinstance(out, str)

Are you talking about auto-casting "2" (str) to 2 (int) for the python variable out, or are you expecting the following case to work, instead of a TypeError?

out = Liquid("{{ x | plus: 1}}").render(x="1")
# TypeError: can only concatenate str (not "int") to str

[pwwang]

Was indeed wondering if this could be possible.

Are you referring to the second case where x = "1" is to be casted to x = 1, so that we can do {{ x | plus: 1}}, instead of {{ x | int | plus: 1 }}?

[frikky]

Indeed! {{ "1" | plus: 1 }} and {{ 1 | plus: 1}} would essentially be the same to the end-user

[pwwang]

I see. So my suggestion will be to (re-)implement the set of filters that need auto-type-casting.

For example:

>>> from liquid import Liquid, defaults
>>> defaults.MODE = 'wild'
>>> defaults.FROM_FILE = False
>>> from liquid.filters.standard import standard_filter_manager
>>>
>>> def plus(a, b):
...     a = int(a)
...     b = int(b)
...     # Re-use the builtin filter
...     return standard_filter_manager.filters["plus"](a, b)
... 
>>> Liquid("{{ '1' | plus: 1}}", filters={"plus": plus}).render()
'2'

[frikky]

This would be amazing. Does this basically mean overwriting them during runtime on our side, or do you think should it be done in the library itself?

PS: We do have a rather long list of features we would like to add ourselves (not in default Liquid). Would it be best to add fork and add them with pull requests, or as with the above, add them during runtime locally for us? Wondering how much it may impact speed (again: I'm ignorant on the architecture here :))

[pwwang]

For this specific type-casting thing, I would not recommend merging it into liquidpy. The reason is that liquidpy is more like an API library, your scenario is just one of its use-cases (which is more focused on the end users). But there are many others, where auto-type-casting may confuse people, especially python developers who are type-aware (they might think how I am supposed to do "1" + 1).

But PRs are absolutely welcome for other enhancements, bug fixes, and filters that liquidpy is lacking. And you are also welcome to share your list of features and we will see which ones can be added to liquidpy itself.

Here is a sort of "best practice" to extend/overwrite the filters:

You can put all your filters in one file, say liquid_filters.py:

from liquid.filters.manager import FilterManager
from liquid.filters.standard import standard_filter_manager

shuffle_filters = FilterManager()

@shuffle_filters.register
def plus(a, b):
  a = int(a)
  b = int(b)
  return standard_filter_manager.filters["plus"](a, b)

# # register your other filters
# @shuffle_filters.register
# def minus(a, b):
#  a = int(a)
#  b = int(b)
#  return a - b

Then when you call Liquid constructor:

from liquid_filters import shuffle_filters 
# other imports and preparation

liq = Liquid(..., filters=suffle_filters.filters)

In terms of the speed, you don't have to worry about the impact of these additional filters on the baseline speed, as they are implemented the same way as built-in filters and won't change the runtime architecture.