On 08/23/2015 08:35 PM, Eric V. Smith wrote:
Thanks for PEP 501. Maybe I'll add delayed interpolation to PEP 498!
On a more serious note, I'm thinking of adding i-strings to my f-string implementation. I have some ideas that the format_spec (the :.3f stuff) could be used by the code that eventually does the string interpolation. For example, sql(i-string) might want to interpret this expression using __sql__, instead of how str(i-string) would use __format__. Then the sql() machinery could look at the format_spec and pass it to the value's __sql__ method.
For example: sql(i'select {date:as_date} from {tablename}'
might call date.__sql__('as_date'), which would know how to cast to the write datatype (this happens to me all the time).
This is one reason I'm thinking of ditching !s, !r, and !a, at least for the first implementation of PEP 498: they're not needed, and are not generally applicable if we add the hooks I'm considering into i-strings.
In the .format() mini language is there a way to format an in place literal value? (ok... need an example for this one.) "{Name: {'John Doe':?<30} {'123-123-1234':?>13}\n".format() What would '?' be? Here this case the values are give, but not formatted yet. I was thinking this would allow interpolating the values, then translating, and finally formatting the translated string. It seems part of the problem is the insertion of the values and formatting may be tied to closely each other. Field formatting and value formatting are to separate things. By separating them into two well defined steps, we may be able to do... "{Name: {name:<30} {number:>13}\n".interpolate().translate().format() And possibly a literal syntax for that could just be expanded to the chained method calls. Probably 'i' and/or 'f' would do, but 't' for translate seems like it may be nice. And if someone wanted to they can still do each step separately by using the methods explicitly. Cheers, Ron