[Python-3000] unit test for advanced formatting

[Mike Verdone]

Hi Talin,

Some more thoughts...

> 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.

Personally, I think this is something that application writers should
worry about. Like this:

def fmtString(string):
    return lenientformat(string) if applicationInProduction else string

fmtString("my format {0}").format(...)

Now the application can turn on and off strict mode from one place for
all strings that call fmtString. I don't think I'd ever want to change
between lenient and strict mode across the board. What if a module
writer writes code that depends upon format strings being strict and
raising exceptions? When you switch your application to lenient mode,
the entire functioning of the module could change. With an across the
board switch module writers will have to assume two completely
different failure modes for every use of format().

Mike.


On 2/28/07, Talin <talin at acm.org> wrote:
> Pete Shinners wrote:
> > I've gone over PEP3101 to create an initial unittest for the advanced
> > formatting. Based on this intro to the formatting syntax, I thought I'd
> > also
> > share my thoughts. I've also experimented with this against the python
> > prototype of the formatting.
> >
> > I have commented out the tests where that implementation fails, but should
> > work (by my interpretation). If anything these tests will provide a preview
> > look at the way the formatting looks.
> >
> > 1. The early python implementation does not allow "reusing" an argument
> > either by index or by keyword name. The PEP has not defined this
> > behavior. I
> > think it is important to be allowed to reuse any of the argument objects
> > given to format.
>
> Sounds good to me. I think that may have been a side effect of trying to
> insure that all arguments were used at least once.
>
> > 2. The implementation we have always requires a "fill" argument in the
> > format, if a width is specified. It would be a big improvement if space
> > characters were default.
>
> Concur.
>
> > 3. The specification is deep. It will take an intense amount of unit
> > testing
> > of corner cases to make sure this is actually doing what is correct. It may
> > be too complex, but it is hard to know what might be yagni.
>
> Well, all I can say is - it could have been a lot deeper. I had to
> restrict myself to limiting the scope as it was, as there are a lot of
> related issues that weren't covered.
>
> > 4. The PEP still leaves a bit of wiggle room in the design, but since an
> > implementation is underway, I think more experimentation would be better
> > before locking down the design.
> >
> > 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.
>
> > 6. Security on the attribute lookups is probably an unending topic. A
> > simple
> > minimum would be to not allow attribute lookups on names starting with an
> > underscore.
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Python-3000 mailing list
> > Python-3000 at python.org
> > http://mail.python.org/mailman/listinfo/python-3000
> > Unsubscribe: http://mail.python.org/mailman/options/python-3000/talin%40acm.org
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe: http://mail.python.org/mailman/options/python-3000/mike.verdone%40gmail.com
>