[Python-Dev] Rename str/unicode to text [Was: Re: str object going in Py3K]

Adam Olsen rhamph at gmail.com
Thu Feb 16 12:51:06 CET 2006

On 2/15/06, Guido van Rossum <guido at python.org> wrote:
> On 2/15/06, M.-A. Lemburg <mal at egenix.com> wrote:
> > Barry Warsaw wrote:
> > > On Wed, 2006-02-15 at 18:29 +0100, M.-A. Lemburg wrote:
> > >
> > >> Maybe a weird idea, but why not use static methods on the
> > >> bytes and str type objects for this ?!
> > >>
> > >> E.g. bytes.openfile(...) and unicode.openfile(...) (in 3.0
> > >> renamed to str.openfile())
> > >
> > > That's also not a bad idea, but I'd leave off one or the other of the
> > > redudant "open" and "file" parts.  E.g. bytes.open() and unicode.open()
> > > seem fine to me (we all know what 'open' means, right? :).
> >
> > Thinking about it, I like your idea better (file.bytes()
> > and file.text()).
> This is better than making it a static/class method on file (which has
> the problem that it might return something that's not a file at all --
> file is a particular stream implementation, there may be others) but I
> don't like the tight coupling it creates between a data type and an
> I/O library. I still think that having global (i.e. built-in) factory
> functions for creating various stream types makes the most sense.

While we're at it, any chance of renaming str/unicode to text in 3.0? 
It's a MUCH better name, as evidenced by the opentext/openbytes names.
 str is just some odd C-ism.

Obviously it's a form of gratuitous breakage, but I think the long
term benefits are enough that we need to be *sure* that the breakage
would be too much before we discount it.  This seems the right time to
discuss that.

(And no, I'm not suggesting any special semantics for text.  It's just
the name I want.)

str literal -> text literal
unicode literal -> text literal
text file -> text file (duh!)
tutorial section called "Strings" -> tutorial section called "Text"
Documentation Strings -> Documentation Text
String Pattern Matching -> Text Pattern Matching
String Services -> Text Services.  Actually this is a problem.  struct
should be used on bytes, not unicode/text.
textwrap -> textwrap
stringprep -> textprep?  Doesn't seem like a descriptive name
linecache "Random access to text lines"
gettext (not getstring!)

Adam Olsen, aka Rhamphoryncus

More information about the Python-Dev mailing list