>> the string class, which has some annoying tight couplings to "string" and  'string')

> What does that mean?

> It sounds like you are complaining that the syntax for creating strings  creates strings. Or possibly the other way around: that strings are created by string syntax. What did you expect?

Here's my understanding:

You can't extend the string class to add new functionality. You can only subclass it. Because of this, "character-strings" cannot be suffixed with new functionality.

For instance, you can write x='FOO'.lower() and x ends up being "foo"; That's a function of the actual str class.

Buf if you subclass str as MyStr and create a MyStr object of "192.168.1.100", you cannot write...

    "192.168.1.100".TestDottedQuad()

...because "192.168.1.100" can only be an instance of str, not of MyStr. You have to run TestDottedQuad() either indirectly on a variable of type MyStr, or as a parameter to a function in a MyStr class object.

The root problem is that you cannot extend a class. This is one of the limits that result. Which, yes, I find very annoying.

So, some years ago, I wrote a simple precompiler that enables syntax that extends built-in classes -- without monkey patching Python. So you can create a virtual class extension, write x='192.168.1.100'.TestDottedQuad() or x="192.168.1.100".TestDottedQuad() in your input source to be precompiled, and it will work as it should in the resulting output source.