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@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@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
