Guido van Rossum wrote:
>
> [/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.
I've always thought of str() being a constructor, just like
int(), float(), complex() and all the others. The reasoning for
adding optionla arguments to str() was to make it match the
unicode() signature.
> 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.
I've checked in the .encode() method and the C APIs that go
with it.
There's currently no way to access the codec decode methods
though (that was part of the str() patch).
Anyway, it's cool having the ability to use the codecs for
strings too, e.g. you can now do conversions from the
current default encoding to say UTF-16 by simply
writing:
setenv LANG de_DE # Latin-1 encoding
python -c "print 'Wünsch dir was...'.encode('utf16')"
--
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