Param objects could have ability to provide containers for multiple objects. about graceful

[swistakm]

@dreamwalker, @mihau: I will glad to hear your opinion on this feature draft because I know that you are the users of graceful.

[swistakm]

I found even more simpler solution. Knowing that functions in Python are descriptors we can allow to specify containers both as class (type) objects and custom methods using only one class attribute: container. The BaseParam implementation for that feature would be as follows:

class BaseParam():
    container = list
    ...

If someone wants to have more complex behaviour he can still implement it as a method. That way we get rid of additional class attribute and extra method call for default behaviour.

I was thinking also about adding additional container keyword argument to BaseParam.__init__ that would allow us to override default container type without the need of subclassing.

Anyone want's to comment on that? @mihau? @tomislater?

[tomislater]

Hmm, looks right for me. If someone wants to get more values (not list), he/she can create a function for this (container).

I have another idea. What if we would have value and values methods?
Then, if someone passes param many=True, he has to implement values method.

For example:

class BaseParam:
    def value(self, raw_value):
        raise NotImplementedError

    def values(self, values):
        # raw_values is a list
        raise NotImplementedError

class MyParam(BaseParam):
    def value(self, raw_value):
        return my_magic_function(raw_value)

    def values(self, values):
        return my_magic_function_for_list(values)

I understand that with this approach, we will have to change the logic in BaseResource.require_params method concerning getting params.

[swistakm]

It seems interesting but I don't know if I get the whole point of this idea. Does values is supposed to:

1. get the list of deserialised values (results of calling value() for each one of them)?
2. get list of raw strings from query string params via request req.get_param_as_list()?

If this is (1.) then I think that this is almost the same solution as the proposed with container but named differently.

If it is (2.) then I think that right now there is very limited gain from such splitting of implementation. I worry that this would make easier for users to take bad design decisions about how their params work. Generally param instances are used to describe parsing/deserialization of single query string parameter and such behaviour should not change with custom many setting.

Anyway, I do not say definitive no to any of these options. I think we should keep such idea in mind and revisit it later in future if someone finds really practical use case for that.

[tomislater]

Yeah, I have meant the first point. I have thought about the second approach (raw values), but it could be difficult to understand.