Draft PEP: string interpolation with backquotes

Fernando Pérez fperez528 at yahoo.com
Sun Dec 2 21:49:26 CET 2001


Steven Majewski wrote:

>
>  You've made a pretty convincing argument about why it's a handy
> feature, but I haven't heard an argument for why it requires
> a new syntax (or new sematics for an old syntax).

I know, because ultimately it's just convenience. I currently use the 
Itpl module, which implements it fully, and I get by fine. It's not 
that big of a deal to write
        print itpl('blah $...')

vs 
        print $'blah $...'

I guess the only argument I'd push forward would be that it would 
make life a bit easier for newcomers: newbies tend to stick to the 
language without knowing much about modules available. So they often 
spend months (or longer) doing things 'the hard way' when there's a 
module that can make things much easier.

But I know that isn't a super-convincing argument, and that a few 
comments in the tutorials concerning the existence of 
alternate/better ways of doing things can go a long ways.

So I guess that a combination of:
a) including Itpl in the standard distro
b) mentioning it in the documentation in appropriate places

would probably go a long way.

By the way, the docs comment is a general one. While I *love* the 
python documentation and think it's in general top notch, if there's 
one minor comment I'd make it is that in the more basic parts it 
would't hurt to mention (and hyperlink) a bit more of the 
functionality available in the standard library. Currently one tends 
to read the basic docs and miss a lot of functionality unless one 
deliberately runs through the stdlib docs.

Minor gripe though, and not meaning to disparage the great work of 
the doc team.


> 
>  I would say that Python is not very 'syntactically open' --
> certainly not in the way that Lisp or Forth is.
> 
And in the long run, I agree with that philosophy. A strong editorial 
stance keeps things clean and sane for the long haul. It's a delicate 
balance (between featuritis and freezing progress), but in general I 
agree it's best to err on the side of caution. One can always add a 
feature later, but removing a misfeature is nearly impossible.

Cheers,

f



More information about the Python-list mailing list