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/
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