New DSL in requestargs in coaster.views

[Kiran Jonnalagadda]

Today I introduced another tiny DSL in coaster with the '[]' string suffix in requestargs:

http://coaster.readthedocs.org/en/latest/views.html#coaster.views.requestargs

This is the second instance: load_models accepts parameters in the "parent.child" convention to look up the child object inside the parent object.

DSLs are an anti-pattern because they introduce custom parsers that will require maintenance over time, but both these instances are tiny and I couldn't find an obviously better way to express them.

Thoughts?

-- 

Kiran Jonnalagadda

+91-99452-35123

http://hasgeek.com

[Anand Chitipothu]

On Wed, May 8, 2013 at 2:27 PM, Kiran Jonnalagadda <ki...@hasgeek.com> wrote:

Today I introduced another tiny DSL in coaster with the '[]' string suffix in requestargs:

http://coaster.readthedocs.org/en/latest/views.html#coaster.views.requestargs

This is the second instance: load_models accepts parameters in the "parent.child" convention to look up the child object inside the parent object.

DSLs are an anti-pattern because they introduce custom parsers that will require maintenance over time, but both these instances are tiny and I couldn't find an obviously better way to express them.

Thoughts?

How do you specify list of integers?

Anand

[Anand Chitipothu]

Got it. ('param3[]', int).

Doesn't look very pythonic though.

Anand

[Kiran Jonnalagadda]

On Wed, May 8, 2013 at 2:48 PM, Anand Chitipothu <anand...@gmail.com> wrote:

Got it. ('param3[]', int).

Doesn't look very pythonic though.

Exactly. But, how else?

('param3', int, list)

('param3', int, True)

('param3', int, 'list')

('param3:list', int)

('param3:int', True)

All of which look questionable. Lists in request parameters are a unique case so the '[]' syntax felt like a decent compromise. There won't be anything else in future.*

* Assuming we never get to complex record decoding, the path that led to Rails's YAML vulnerabilities.

Kiran

[Anand Chitipothu]

On Wed, May 8, 2013 at 3:54 PM, Kiran Jonnalagadda <ki...@hasgeek.com> wrote:

On Wed, May 8, 2013 at 2:48 PM, Anand Chitipothu <anand...@gmail.com> wrote:

Got it. ('param3[]', int).

Doesn't look very pythonic though.

Exactly. But, how else?

('param3', int, list)

('param3', int, True)

('param3', int, 'list')

('param3:list', int)

('param3:int', True)

All of which look questionable. Lists in request parameters are a unique case so the '[]' syntax felt like a decent compromise. There won't be anything else in future.*

* Assuming we never get to complex record decoding, the path that led to Rails's YAML vulnerabilities.

If you are using 'params3[]', then why not do it for type as well? Why a tuple?

@requestargs('param1', 'param2:int', 'param3[]:int', ...)

Or 

@requestargs(param1=str, param2=int, param3=[int], ...)

Anand

[Kiran Jonnalagadda]

On Wednesday, 8 May 2013 at 4:58 PM, Anand Chitipothu wrote:

If you are using 'params3[]', then why not do it for type as well? Why a tuple?

Because lists were a recent addition. requestargs has been in coaster for a few months.

@requestargs('param1', 'param2:int', 'param3[]:int', ...)

If the type is passed as a string, requestargs will need a list of valid strings. The current format accepts a callable so it's user-extensible. 

@requestargs(param1=str, param2=int, param3=[int], ...)

This is better, but the special-casing of [int] means it's still a DSL.

Kiran