Glyph <gl...@twistedmatrix.com> writes: > You could also find some other way to split the argument list but "+" doesn't > seem particularly obscure in this context to me. (If there's really a need > to pass a literal "+" to a plugin we could add an escaping syntax as well.)
I think if we are adding syntax, then we should also add escaping at the same time. On a related note, when designing this kind of syntax, I think it is often valuable to explictly leave some of the space as an explict error, to leave freedom to extend the syntax in the future. I wonder if there is any value in having a syntax that is nestable. I don't see any specific use case, but I can imagine wanting ot pass options to `compose` that are scoped to an individual plugin that it is loading. And then, maybe you want to nest things so that those options apply to a subset of plugins, which might naturally be implemented as compos of a compose. The suggestions in the last paragraph are perhaps somewhat contrived, and certainly not something that should be *implemnted* in a first (or even second pass). But considering the possiblity, and then picking a syntax that might allow those kinds of extension (and then explictly making the extension syntax an error) gives us the ability to add those features without breaking backwards compatibility. Tom _______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
