Talin wrote:
> The first change is to divide the conversion specifiers into two parts,
> which we will call "alignment specifiers" and "format specifiers". So
> the new syntax for a format field will be:
>
> valueSpec [,alignmentSpec] [:formatSpec]
>
> In other words, alignmentSpec is introduced by a comma, and conversion
> spec is introduced by a colon. This use of comma and colon is taken
> directly from .Net. although our alignment and conversion specifiers
> themselves look nothing like the ones in .Net.
Should the .format() method (and underlying machinery) interpret the
formatSpec (and/or the alignmentSpec) at all? I believe .NET doesn't
proscribe any meaning to its format specifiers, but instead passes them
in to the object for parsing and interpretation. You would lose the
ability to implicitely convert to ints, floats and strings, but maybe
that should be explicit, anyway.
And if we do that, why not require all objects to support a __format__
method? Maybe if it's not present we could convert to a string, and use
the default string __format__ method. This way, there would be less
special purpose machinery, and .format() could just parse out the {}'s,
extract the object from the parameters, and call the underlying object's
__format__ method.
Eric.
_______________________________________________
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
