"As you can see above, each Strategy is optionally configurable through its constructor."
This is perfectly fine/normal, and is in fact one of the cornerstones that makes polymorphic types flexible: you enter the parameters that vary across the hierarchy via the constructor, and you then pass the resulting object to clients that only rely on the abstract interface (dependency injection).
"This is different from all the examples of the Strategy patterns I saw, where concrete sub-Strategies only ever implemented the "main interface" (in the example above, the match function)."
The internet is full of oversimplified toy examples that don't address the more subtle points.
The original Design Patterns book also gives a toy example, but the authors give 3 strategies that have disparate constructors:
// They have an abstract Compositor class (which plays the role of the Strategy)// and 3 derivatives with the following constructors: SimpleCompositor();TeXCompositor();ArrayCompositor(int interval);// Some code then creates one of these, based on its own // needs, and injects the instance into the Context object:class Composition {public: Composition(Compositor*); // note the ctor parameter void Repair();private: // ...};// It can then use the Composition instance itself, or pass the // preconfigured instance to something else that needs it as a dependency"some of my colleagues are uneasy, because supposedly it would be harder to construct these objects using a factory since their constructors aren't exactly the same."
If you impose this restriction on yourself, then there should be a good reason for that. You might not need any sort of factory. And even when it looks like you do, ask yourself if you really need a single factory that creates all these objects, along with the unnecessary coupling this brings? Such a factory would have to be aware of all the subtypes, and you'd have to update it (and possibly code that uses it) whenever you add a new derivative.
A better, more flexible use of factories is in circumstances where some of the constructor parameters are not known when a dependent object needs to be created. So, the dependent object gets injected with a factory that produces the dependency at a later time (in some sense, you can think of it as partial construction). You wrap the dependency's constructor in a factory or a lambda that allows the missing parameters to be plugged in later on, when they become available. These factories are much more subtype-specific, with a narrower responsibility, so they don't impose a particular constructor signature across the hierarchy.
If you don't have such a situation, you can just create the concrete strategy by directly calling the constructor, and inject it into the dependent object manually. Adding a factory without having a good reason does not magically make the code more decoupled.
Another situation where this might be a concern is when you are using some sort of a framework that insists that your objects have the default constructor, or a constructor with a particular signature. But again, that puts an artificial limitation on you - and then it becomes a matter of a cost/benefit analysis. I.e., that framework better be worth it.
Finally, what about DI containers? I'm not particularly familiar with what's available for Python, but if you're using dependency injection with a DI container, most containers don't require a specific constructor signature.