"M.-A. Lemburg" wrote: > > Fredrik Lundh wrote: > > > > mal wrote: > > > > > The idea is not new: strings and Unicode should have more > > > or less the same methods to enhance their compatibility. > > > > > > The attached patch adds encoding capabilities to normal > > > strings and extends the builtin str() to accept an optional > > > encoding (and error) argument. It also tries to reuse the > > > already available Unicode codecs for the purposes of strings > > > (conversions are done via the default encoding in both > > > directions). > > > > ... > > > > > 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. -- 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