[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