Eric V. Smith wrote: > Talin wrote: >> One final thing I wanted to mention, which Guido reminded me, is that >> we're getting short on time. This PEP has not yet been officially >> accepted, and the reason is because of the lack of an implementation. >> I don't want to miss the boat. (The boat in this case being Alpha 1.) > > I have hooked up the existing PEP 3101 sandbox implementation into the > py3k branch as unicode.format(). It implements the earlier PEP syntax > for specifiers.
Woo hoo! Thanks Eric. This is great news. At some point I'd like to build that branch myself, I might send you questions later. > I'm going to work on removing some cruft, adding tests, and then slowly > change it over to use the new proposed specifier syntax. I'm not sure that I'm happy with my own syntax proposal just yet. I want to sit down with Guido and talk it over before I commit to anything. I think part of the difficulty that I am having is as follows: In writing this PEP, it was never my intention to invent something brand new, but rather to find a way to cleanly merge together all of the various threads and requests and wishes that people had expressed on the subject. (Although I will admit that there are a few minor innovations of my own, but they aren't fundamental to the PEP.) That's why I originally chose a format specifier syntax which was as close to the original % formatting syntax as I could manage. The idea was that people could simply transfer over the knowledge from the old system to the new one. The old system is quite surprising in how many features it packs into just a few characters worth of specifiers. (For example, I don't know if anyone has noticed the option for putting a space in front of positive numbers, so that negative and positive numbers line up correctly when using fixed-width fields.) And some of the suggested additions, like centering using the '^' character, seemed to fit in with the old scheme quite well. However, the old syntax doesn't fit very well with the new requirements: the desire to have the 'repr' option take precedence over the type-specific formatter, and the desire to split the format specifier into two parts, one which is handled by the type-specific formatter, and one which is handled by the general formatter. So I find that I'm having to invent something brand new, and as I'm writing stuff down I'm continually asking myself the question "OK, so how is the typical Python programmer going to see this?" Normally, I don't have a problem with this, because usually when one is doing an architectural design, if you look hard enough, eventually you'll find some obviously superior configuration of design elements that is clearly the simplest and best way to do it. And so you can assume that everyone who uses your design will look at it and see that, yes indeed, this is the right design. But with these format strings, it seems (to me, anyway) that the design choices are a lot more arbitrary and driven by aesthetics. Almost any combination of specifiers will work, the question is how to arrange them in a way that is easy to memorize. And I find I'm having trouble envisioning what a typical Python programmer will or won't find intuitive; And moreover, for some reason all of the syntax proposals, including my own, seem kind of "line-noisy" to me aesthetically, for all but the simplest cases. This is made more challenging by the fact that the old syntax allowed so many options to be crammed into such a small space; I didn't want to have the new system be significantly less capable than the old, and yet I find it's rather difficult to shoehorn all of those capabilities into a new syntax without making something that is either complex, or too verbose (although I admit I have a fairly strict definition of verbosity.) Guido's been suggesting that I model the format specifiers after the .Net numeric formatting strings, but this system is significantly less capable than %-style format specifiers. Yes, you can do fancy things like "(###)###-####", but there's no provision for centering or for a custom fill character. This would be easier if I was sitting in a room with other Python programmers so that I could show them various suggestions and see what their emotional reactions are. I'm having a hard time doing this in isolation. That's kind of why I want to meet with Guido on this, as he's good at cutting through this kind of crap. -- Talin _______________________________________________ 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
