Add a split filter

[nkakouros]

This is a followup on the discussion here.

The issue with the split method is that is cannot be used with map. There are some use cases on the linked page.

There is a closed PR that could be used.

Template Code

# This is not possible to do with the split method
tuple_list: "{{ list_var | map('split', ' ') | list }}

# This could become more readable with a split filter
 variable_name: "{{ (lookup('file', 'file.txt')).split('\n') }}"

Your Environment

• Python version: 3.7
• Jinja version:2.10

[davidism]

Thanks for the suggestion. After some thought, I don't think this belongs in Jinja. The example here is being way too clever where data should be the correct type to begin with (this is the general advice I've heard from Ansible devs as well). For example, if you have a list, make it a list of lists to begin with, rather than a list of strings.

In full templates where you're not trying to force everything into one expression, or have more control over the data being passed to the template, this becomes much less needed.

[jonathan-s]

As a counterpoint the project cookiecutter uses jinja and can ask the user to input a comma-separated string in the console when a cookiecutter project is generated. It would be useful to be able to take that input and split on the comma to get a list.

[ThiefMaster]

Why not define your own filter for this inside the cookiecutter code though?

[nkakouros]

Let's close all issues and ask people to implement them in their code.

[ThiefMaster]

@nkakouros No need to post passive-aggressive comments. I don't think many people need this filter, so why add it to the core? It's perfectly normal to use Jinja's APIs to register custom filters if you want to use one that is not part of the core.

[nkakouros]

Whatever passive aggressive means, my comment was meant as the extreme application of your logic, sth that is often done to highlight the traps or errors in an argument. Do you have statistics about the use of each filter or Jinja feature? I would like to see them too. But I have seen this issue pop up every now and then both here and in other projects that rely on Jinja. Also it is not only the popularity of a feature that matters but also intuitiveness. It is normal to think (I believe) to expect a split filter when there is a join filter. Maintenance overhead for such a filter will be not even minimal while you will support beautiful code, without nested parentheses for advanced users without asking them to cater for custom plugins. Of course the project is not mine to decide, I am just expressing a use case.

[jonathan-s]

@ThiefMaster For what it's worth, I started to look into that option as well, I'd need to rely on this PR: cookiecutter/cookiecutter#1240 to be able to pull that off. So I'm stuck either way right now.

Since there is a join function it does seem reasonable to be able to do the reverse as well, in my humble opinion.

[KTibow]

It could be useful if you wanted to change something in an array like this:

{% set testing = [[1, 2], [3, 4]] %}
{% set testing = testing | join(';') | replace('[1, 2]', '[5, 6]') %}
{% set testing = testing.split(';') %}
{% set testing = testing | map('split', ',') %}
{{ testing }}