PEP 215 (was Re: [Python-Dev] PEP 216 (string interpolation) alternative EvalDict)

...

...

...

...

"PP" == Paul Prescod writes:

PP> He said that the output of the transformation would be no more PP> and no less than directly typed code with | a) whatever code the programmer explicitly typed | in the $-string; | b) str() or unicode(); and | "$" has the power to eval, but only to eval a literal. As | described here (a string prefix rather than an operator | c) the + operator applied to strings. PP> "a)" embodies a whole host of things listed in the PEP: PP> "A Python identifier optionally followed by any number of PP> trailers, where a trailer consists of: - a dot and an PP> identifier, - an expression enclosed in square brackets, or - PP> an argument list enclosed in parentheses (This is exactly the PP> pattern expressed in the Python grammar by "NAME trailer*", PP> using the definitions in Grammar/Grammar.)" Not to pick on Paul, but I'm having a hard time imagining how a newbie Python user being taught this new feature in his second hour will actually understand any of these rules. And how will you later answer their questions about why Python has both $'' literals and '' % dict interpolation when it seems like you can do basically the same task using either of them?

...

...

...

...

"KY" == Ka-Ping Yee writes:

KY> In short: PEP 215 suggests a syntactic transformation that KY> turns KY> $'the $quick brown $fox()' KY> into the fully equivalent KY> 'the %s brown %s' % (quick, fox()) KY> The '$' prefix only applies to literals, and cannot be used as KY> an operator in front of other expressions or variables. This KY> issue is pointed out specifically in the PEP: [...then...] KY> Good point. Perhaps it is better to simply describe a KY> transformation using '%s' and '%' instead of 'str' and '+' KY> to avoid this potential confusion altogether. That would help <wink>. KY> (By the way, i myself am not yet fully convinced that a string KY> interpolation feature is something that Python desperately KY> needs. I am definitely not convinced that Python desperately needs PEP 215. I wonder if the same folks clamoring for it will be the same folks who raise their hands next month when asked again if they think Python is change too fast (naw, that won't happen :). How many of you use Itpl regularly? If Python were so deficient in this regard, I would expect to see a lot of hands. It's certainly easy enough to define in today's Python, a simple function call that adds only two characters to the proposal, so I don't buy that this /only/ has utility if were to apply to literals. I'm willing to accept that as applied only to literals it doesn't raise more security concerns, but it also isn't nearly as useful then IMO. And BTW, as I've told Ka-Ping before, I /am/ sympathetic to many of the ideas in this PEP and in Itpl. In fact, I have something very similar in Mailman that I use all the time[1]. Instead of $'...' I spell it _('...') which actually stands out better to me, and is only two extra characters. It's not as feature rich as PEP 215, but then about the /only/ thing I'd add would be attribute access. As it is, _('You owe me %(num)d dollars for that %(adj)s parrot') gets me there 9 times out of 10, while for the 10th bird = cage.bird state = bird.wake_up() days = int(time.time() - bird.lastmodtime) / 86400 _('That %(bird)s has been %(state)s for %(days)s') is really not much more onerous, and certainly less jarring to my eye than all those $ signs. -1 -Barry [1] I use _() ostensibly to mark translatable strings, but it has a side benefit in that it interpolates into the string named variables from the locals and globals of the calling context. It does this by using sys._getframe(1) in Python 2.1 and try/except hackery in older versions of Python. I find it quite handy, and admittedly magical, but then I'm not suggesting it become a standard Python feature. :)