[Python-3000] unit test for advanced formatting

Talin talin at acm.org
Wed Feb 28 21:37:13 CET 2007


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


More information about the Python-3000 mailing list