magmax/python-inquirer

[BUG] choices is not shown properly for multi-dimensional array for >2.8.0 versions

kutysam opened this issue · 3 comments

kutysam commented 
print(version('inquirer'))
import inquirer
notworking = inquirer.list_input(message="TEST", choices=[
                                 ["hello1", "world1"], ["hello2", "world2"]])

Test with the code above.

2.8.0

➜  deploy-scripts git:(master) ✗ python3 deploy.py
2.8.0
[?] TEST: ['hello2', 'world2']
   ['hello1', 'world1']
 > ['hello2', 'world2']

Anything > 2.8.0

➜  deploy-scripts git:(master) ✗ python3 deploy.py               
2.9.0
[?] TEST: hello1
 > hello1
   hello2

Expected: It should show how 2.8.0 is showing.

kutysam commented

2800042

I think its this commit.
I don't think that commit should be merged.

1 case of the above is that i want to show docker tags as [0] and docker image time for [1] which is a valid case.
Lists should be treated as what they are.

Cube707 commented

Hello, interesting find.

This was intreduced to unify behavior for the feature, where a pair of a tag and a prompt can be passed o inquire. This allows for easier and more readbale parsing of the answer while using complex, dynamicaly generated prompts. Originally this was bound to providing the pair as a tuple and the PR wanted to "unify" this behavior.

However I also agree that wanting to prompt for a list is a valid request. As a temporary workaround however, I would recomend switching to constructing a sting prompt, for example:

import inquirer
from time import time

tags = ["dockertag1", "dockertag2"]
choices =  [(f"{tag} (created: {time()})", tag) for tag in tags]

answers = inquirer.list_input(message="TEST", choices=choices)
print(answers)

discussion

@staticdev we should discuss whats the more important feature and adjust the behavior acoringly:

  • should the passing of prompt-tag pairs extend to lists as well as tuples?
  • should list/tuple be promptable?
  • is the feature of using prompt-tag pairs important enough in generall to overrid a build in types usablility?

My opinion

We should remove the list check and limit pairs to tuples of lenght two only. Tuples are imutable and fit this job in that we only accept a special form, where as lists imply that you can change the composition later on.

Alternativly we could intreduce a class PrompTagPair that handles this feature. This would also remove the ambugidedy in the ordering.

staticdev commented

@Cube707 I agree, we can remove the list check and limit the pairs to tuples of two, it is the clearer interface.

  • 👍1