[Python-Dev] 'abc'.encode() and str(obj, encoding)

[Guido van Rossum]

> Subject: Re: [Python-Dev] 'abc'.encode() and str(obj, encoding)
> From: "Fredrik Lundh" <fredrik@pythonware.com>
> To: "M.-A. Lemburg" <mal@lemburg.com>,
>     "Python Developers @ python.org" <python-dev@python.org>
> Date: Thu, 6 Jul 2000 12:21:05 +0200
> Delivery-Date: Thu Jul  6 06:22:40 2000
> 
> mal wrote:
> > > >
> > > > > What do you think about this ? Should I add it to CVS
> > > > > as experiment ?
> > > >
> > > > +1 on the "encode" part
> > > >
> > > > -0 on the "str" part (intuitively, it's -1, but I don't have
> > > > any good arguments against it right now... maybe later)
> > > 
> > > The str() extension complements unicode() which also works
> > > as constructor for object given an encoding.
> > > 
> > > Ideally, unicode() should also look for __unicode__() on instances
> > > just like str() looks for __str__().
> > > 
> > > Note that we could also have a .decode() method instead of
> > > modifying str(), but this would break symmetry to Unicode,
> > > since you can't decode Unicode into anything...
> > 
> > Anybody else have an opinion on this idea ? I'd like to get
> > this done before the release of 2.0b1.

[/F]
> Having thought this over, I'm -1 on the str fix.
> 
> You're changing "str" from being a converter ("convert this to a
> string") to a string constructor ("create a new 8-bit string").  This
> is against the "strings are strings" spirit.

I almost voted with you, except that int() also has an extra argument:
int("100", 8) yields 64.  In one of my proposals for a type system
I've also used the str function and others as a constructor.

Since I haven't seen the patch (too much other stuff going on you
don't want to know about :-( ), I vote 0; that's neither +0 nor -0.

> Cannot you check the rest in, and leave "str" alone for now?

That would certainly be safe.

--Guido van Rossum (home page: http://dinsdale.python.org/~guido/)