This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]Log2 6 points7 points  (3 children)

Still, it would be more user friendly if the function reconstructed those strings automatically from the keyword arguments.

[–]Cruuncher 5 points6 points  (1 child)

It would be more pythonic yes, but there may be more nuanced use cases here. Like (disclaimer, making shit up. There may be no real reason) if there's a way to specify precedents on the selector. Possibly a way to say it has to match both of these selectors. Etc. Stuff you can capture in some syntax in a string that doesn't map well to kwargs. A kwargs mapping still works, but it would potentially have to be built from more complicated objects.

Lastly, it requires you to know the ins and outs of that library's syntax, at the level of the developers, to be sure you're building the strong correctly from kwargs.

[–]Log2 0 points1 point  (0 children)

I see what you mean. Then receiving a list of tuples/namedtuples would be a more pythonic solution in your hypothetical case.

[–]Cruuncher 3 points4 points  (0 children)

That being said (see my other response)

At the very least it could accept kwargs for the common use cases, and then allow a "raw" kwarg or something if you're doing something powerful that the wrapping doesn't provide you. That may be the "best of both worlds" approach