Ping wrote in response to a SourceForge mail about MAL's unistr() checking: ------- Forwarded Message Date: Wed, 17 Jan 2001 23:51:48 -0800 From: Ka-Ping Yee <ping@lfw.org> To: noreply@sourceforge.net cc: mal@lemburg.com, guido@python.org, patches@python.org Subject: Re: [Patches] [Patch #101664] Add new unistr() builtin + PyObject_Unic ode() C API On Wed, 17 Jan 2001 noreply@sourceforge.net wrote: > Comment: > This patch adds a utility function unistr() which works just like > the standard builtin str() -- only that the return value will > always be a Unicode object. Sorry for barging in, but i have an issue/question: Why are unistr() and unicode() two separate functions? str() performs one task: convert to string. It can convert anything, including strings or Unicode strings, numbers, instances, etc. The other type-named functions e.g. int(), long(), float(), list(), tuple() are similar in intent. Why have unicode() just for converting strings to Unicode strings, and unistr() for converting everything else to a Unicode string? What does unistr(x) do differently from unicode(x) if x is a string? - -- ?!ng ------- End of Forwarded Message (And no, Tim, this did *not* end up in the patches list because I made Barry remove the reply-to. SourceForge mails never had reply-to to begin with.) --Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4