Hi Pete,
These look very good. My comments to your comments below,
> 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.
I just sort of assumed it would be possible to do. Hopefully someone
can add it to the spec officially.
> 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.
I agree. It feels kind of Perl-like. I have nightmares of someone
setting strict mode on the string and having unrelated modules start
blowing up. Could the strict formatting string be a subclass of
string?
strictformat("my format string {0}").format(...)
Alternately maybe strings should be strict by default and you'd have a
lenientformat type for lenient mode. Old-style formatting would blow
up when you were missing arguments. New format should be just as
strict unless you ask it to be nice.
Just my 2c.
Mike.
On 2/27/07, Pete Shinners <[EMAIL PROTECTED]> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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/mike.verdone%40gmail.com
>
>
>
_______________________________________________
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
