A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/1999-November/001274.html below:

[Python-Dev] Internationalization Toolkit

[Python-Dev] Internationalization Toolkit [Python-Dev] Internationalization ToolkitTim Peters tim_one@email.msn.com
Tue, 16 Nov 1999 00:44:42 -0500
[Tim, wonders why Perl and Tcl went w/ UTF-8 internally]

[Greg Stein]
> Probably for the exact reason that you stated in your messages: many
> 8-bit (7-bit?) functions continue to work quite well when given a
> UTF-8-encoded string. i.e. they didn't have to rewrite the entire
> Perl/TCL interpreter to deal with a new string type.
>
> I'd guess it is a helluva lot easier for us to add a Python Type than
> for Perl or TCL to whack around with new string types (since they use
> strings so heavily).

Sounds convincing to me!  Bumped into an old thread on c.l.p.m. that
suggested Perl was also worried about UCS-2's 64K code point limit.  But I'm
already on record as predicting we'll regret any decision <wink>.





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