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

[M.-A. Lemburg]

Fredrik Lundh wrote:
> 
> 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.
> 
> 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.

Um, that was my motivation behind extending str() -- to make
the two (str() and unicode()) aliases for the same function
in some future Python version.
 
Note that str() is in fact a constructor: you pass it an
object and it creates a string from it for you. unicode()
does the same thing (except that there's currently no
__unicode__() check for instances).

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

I'll do that -- you won't be able to decode anything though,
because there's no Python interface to PyString_Decode().

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/