Greg Ewing wrote: > Ron Adam wrote: >> Greg Ewing wrote: > > >>> How does this work with formats where the number of >>> digits before the decimal can vary, but before+after >>> is constant? >> I think this is what you're looking for. >> >> f>15,.3 #15 field width, 3 decimal places, right aligned. > > No, I'm talking about formats such as "g" where the > number of significant digits is fixed, but the position > of the decimal point can change depending on the magnitude > of the number. That wouldn't fit into your before.after > format.
It would probably just a number with no decimal point in it. Something like 'g10' seems simple enough. You will always have the 'g' in this case. >>> Also, my feeling about the whole of this is that >>> it's too complicated. >> it's because we are doing a lot in a very little space. > > Yes, and I think you're trying to do a bit too much. > The format strings are starting to look like line > noise. Do you have a specific example or is it just an overall feeling? One of the motivations for finding something else is because the % formatting terms are confusing to some. A few here have said they need to look them up repeatedly and have difficulty remembering the exact forms and order. And part of it is the suggestion of splitting it up into parts that are interpreted by the objects __format__ method, and a part that are interpreted by the format function. For example the the field alignment part can be handled by the format function, and the value format part can be handled by the __format__ method. It helps to have the alignment part be well defined and completely separate from the content formatter part in this case. And it saves everyone from having to parse and implement alignments in there format methods. I think that is really the biggest reason to do this. I'm not sure you can split up field aligning and numeric formatting that way when using the % style formatting. They are combined too tightly. So each type would need to do both in it's __format__ method. And chances are there will be many types that do one or the other but not both just because it's too much work, or just due to plain laziness. So before we discard this, I'd like to see a full working version with complete __format__ methods for int, float, and str types and any supporting functions they may use. And my apologies if its starting to seem like line noise. I'm not that good at explaining things in simple ways. I tend to add too much detail when I don't need to, or not enough when I do. A complaint I get often enough. But I think this one is fixable by anyone who is a bit better at writing and explaining things in simple ways than I am. :-) Cheers, Ron _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
