[Python-3000] unit test for advanced formatting

Brett Cannon brett at python.org
Wed Feb 28 23:29:28 CET 2007

On 2/28/07, Talin <talin at acm.org> wrote:
> >
> > 5. The "strict mode" activation through a global state on the string object
> > is a bad idea. I would prefer some sort of "flags" argument passed to each
> > function. I would prefer the "strict" mode where exceptions are raised by
> > default. But I do not want the strict behavior of requiring all
> > arguments to
> > be used.
> Here's my primary issue with this: I wanted a way to enable strictness
> on an application-wide level, without having to go and individually
> revise the many (typically hundreds) of individual calls to the string
> formatting function.
> A typical example of what I am talking about here is something like a
> web application server, where you have a "development" mode and a
> "production" mode. In the development mode, you want to find errors as
> quickly as possible, so you enable strict formatting. In production,
> however, you want the server to be as fault-tolerant as possible, so you
> would enable lenient mode.
> Moreover, I would want this strict/lenient decision to apply to all of
> the code modules that I am using, including libraries that I didn't write.
> The problem with a flags argument is that most people aren't going to
> bother using it, since it destroys some of the convenience and
> simplicity of the string formatting function. Thus, if I am calling a
> library function, and that library wasn't written using the flag
> argument, then I have no way to control the setting except through some
> kind of global.
> A more ideal solution would be to allow some kind of 'security context',
> i.e. apply strictness to all code which is running within a given
> context. However, I don't know of a way to do that in Python.
> If someone can think of a better way to accomplish this, I'd love to
> hear it.

Insert a value into __builtin__ and reference that in all format
calls.  That way it is global to the application if you want it but
does not force this level of granularity on people who want a more
fine-grained configuation at a per-method level.


More information about the Python-3000 mailing list