[Barry] > > What can't you do with PEP 292 as it now stands? [Erik] > Examples from previous posts: sh-style safe variables, ml entities. As > you really can't reuse anything now, it would be like starting from > scratch. It took a good while to refine the existing implementation to handle all the nuances of the $var format. My suspicion is that a format with opening and closing delimiters would have its own share of issues (nesting and escaping for example) and would warrant its own separate solution. The current implementation is pretty darned good and strikes a nice balance between extensibility goals and simplification goals (using $var instead of a %(var)s format). The API is clean and friendly for most purposes. Barry has made it possible to create unicode coercing subclasses, to substitute alternate identifier patterns (such as dotted names), to specify an alternative delimiter, and to use polymorphism for changing the implementation without changing client code. That is quite a bit of extensibility. Further hypergeneralization would stray too far from the original simplification goals. After experimenting with alternative approaches and writing subclasses, I learned that no design easily accommodated the most complex use cases. The pattern, convert function, flags, and invocation are so tightly coupled that you really are better off coding from scratch. Fortunately, with the string.py source available as a model, it is not hard to do. So, for applications beyond the limits of the current design, my suggestion is to use regexes to roll your own. At some point, it is easier to write a regex than to write a subclass overriding all existing behaviors. Raymond
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4