[Python-Dev] Alternative Implementation for PEP292:SimpleString Substitutions

Barry Warsaw barry at python.org
Sun Sep 5 17:25:28 CEST 2004


On Sat, 2004-09-04 at 16:03, Raymond Hettinger wrote:
> > Other than .encode() are there any other methods of unicode objects
> that
> > return 8bit strings?
> 
> That misses the point.  Templates do not have to be unicode objects.

But it's damn convenient for them to be though.  Please read the
Internationalization section of the PEP.  In addition to being able to
use them directly as gettext catalog keys, I think there will be /a lot/
of scenarios where you won't want to care whether you have a Template or
a unicode -- you will just want to treat everything as a unicode string
without having to do tedious type checking.

> There seems to be a strong "just live with it" argument but no
> advantages are offered other than it matching your personal approach to
> text handling.  

> Why force it when you don't have to.  At least three of
> your users (me, Aahz, and Fred) do not want unicode output when we have
> str inputs. 

<deep_breath>

PEP 292 was a direct outgrowth of my experience in trying to
internationalize an application and make it (much) easier for my
translators to contribute.  Many of them are not Python gurus and the
existing % syntax is clearly a common tripping point.

I'm convinced that the current design of PEP 292 is right for the use
cases I originally designed it for.  To be generous, if the three of you
disagree, then it's because you have other requirements.  That's fine;
maybe they're just incompatible with mine.  Maybe I did a poor job of
explaining how my uses cases lead to the design of PEP 292.

If all that's true, then PEP 292 can't be made general enough and should
be rejected, and the code should be ripped out of the standard library.
Let applications use whatever is appropriate for their own uses cases.  
Because PEP 292 is a library addition, Python itself won't suffer in the
least.  The implementations you proposed won't be of any use to me. 
Fortunately, the archives will be replete with all the alternatives for
future software archaeologists.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/python-dev/attachments/20040905/94f595a1/attachment.pgp


More information about the Python-Dev mailing list