On 02:41 am, zadka.mo...@gmail.com wrote:
OK, so let me once again enumerate the tickets I'm going to open,
because
it seems like we're reaching consensus:
[1] PROVIDES (pretty much as written: exarkun -- the idea is to walk up
the
hierarchy and then back down, so I did mean IService -- go up until you
find a root, then go down and get all descendents)
Oops. You can't get children *or* a parent from IService. But you can
at least get children from IServiceCollection.
Jean-Paul
[2] 3538 -- will do it with a flag to turn on .tac + plugin
[2.1] I'm assuming the deprecation dance is "flag to turn on" -> "flag
to
turn on + warn if .tac+plugin and no flag" -> "make flag no-op" ->
"warn on
flag" -> "remove flag". If someone doesn't want this dance, please let
me
know preferred alternatives.
Glyph referred to the alternative. Here it is fully spelled out:
https://twistedmatrix.com/trac/wiki/CompatibilityPolicy#ProcedureforExceptionstothisPolicy
Alternatively, do it the nice way but not *quite* as you described:
* Make a new flag like --python but that combines with plugins.
* Deprecate --python
* Remove --python
Three steps instead of five and only bother the user once instead of
twice.
Thanks!
Jean-Paul
[3] MAKE -- API for "createServiceFromNameAndOptions" (basically,
compose-as-a-library)
[4] COMPOSE (implements twistd_compose plugin)
I think there's at least rough consensus that these four pieces are
useful,
even if there's still some disagreement on the details, so maybe the
next
step is to open the three to-be-opened tickets, and then to discuss the
details on the tickets. I'm going to do the ticket opening tomorrow,
and
maybe even work on them during the SF Python Meetup (anyone in SF --
you
should [a] go and [b] say hi also [c] optionally, help me with that).
If anyone has serious objections to this plan, let me know!
Thanks,
Moshe Z.
On Tue, May 19, 2015 at 2:35 PM Glyph <gl...@twistedmatrix.com> wrote:
> 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
