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/2000-December/011143.html below:

[Python-Dev] Death to string functions!

[Python-Dev] Death to string functions! [Python-Dev] Death to string functions!Barry A. Warsaw barry@digicool.com
Tue, 19 Dec 2000 12:20:07 -0500
>>>>> "JvR" == Just van Rossum <just@letterror.com> writes:

    JvR> Recommending replacing all of these (not to mention all the
    JvR> code "out there") with named constants seems plain silly.

Until there's a tool to do the migration, I don't (personally)
recommend wholesale migration.  For new code I write though, I usually
do it the way I described (which is intuitive to me, but then so is
moving your fingers at a blinding speed up and down 5 long strips of
metal to cause low bowel-tickling rumbly noises).

    JvR> So, making join() a builtin makes a whole lot of sense. Not
    JvR> doing this because people sometimes use a local reference to
    JvR> os.path.join seems awfully backward.

I agree.  Have we agreed on the semantics and signature of builtin
join() though?  Is it just string.join() stuck in builtins?

-Barry



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