> On May 19, 2015, at 14:01, Tom Prince <tom.pri...@ualberta.net> wrote: > > 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.
We can un-escape '\+' as a token just fine, and if we do that, all of the weird use-cases you just described are possible. I can't think of any options I'd want to pass to 'compose' myself, but it would be easy enough to add some flags to its parser. -g _______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
