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

[Barry A. Warsaw]

>>>>> "PP" == Paul Prescod <paul@prescod.net> 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 <ping@lfw.org> 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. :)