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.
Cannot you check the rest in, and leave "str" alone for now?
</F>
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