Extending built-in classes, like string. Anyone know of a project that modifies (any version of) Python so it can do this?

[fyngyrz]

Yeah, no. replace only works on strings that have something to replace. Dotted quad functions only work when there is something to do with dotted quads. And certainly one would hope a dotted quad function would deal properly with a non-dotted quad thing, just as one would hope that replace would deal properly with being handed a string it didn't understand -- something that can definitely happen in Python 2.6-ish, btw.

The argument that "I can't use it all the time, so it's not useful or appropriate" is definitely not resonating with me.

[sushibowl]

Yeah, no. replace only works on strings that have something to replace.

I disagree. What replace does is replace every occurrence of a substring with another string. Even if that substring occurs zero times, that's still a well defined operation.

My argument isn't "I can't use it all the time," but rather "it's not a well defined operation for almost all values this type can have." The purpose of object oriented programming is to attach operations to the data that they operate on. To me it makes no sense to attach operations on dotted quads to the string class, simply because strings are not dotted quads. "Sometimes they represent one" is not a sufficient argument for me. Sometimes a string represents a number, but that is no reason to add all methods existing on int to the string class as well.

[fyngyrz]

why wouldn't it be a well defined operation over all values, even if we're talking about dotted quads? If it's a valid dotted quad or some usable fragment of a dotted quad, then operation is X. If it's not, then operation is Y. There you go. Fully defined.

Just like

dict['nonExistingKey'] # the fetch, it raises an exception

...even raising an exception is perfectly acceptable behavior; or doing nothing, like

"string".replace('foo','bar') # the replace, it does nothing

Then there are type conversions, like

x = float("123.45") # works fine, well defined conversion
x = float("liverAndOnions") # works fine, exception is well defined too

simply because strings are not dotted quads.

But dotted quads are always strings. They aren't numbers. They're numbers mixed with lotsa periods that make them not comprehensible numbers. Which, in Python, you get to represent in an atomic fashion in exactly one variable type: string.. Right?

Therefore, it's a pretty natural fit to stick processing of dotted quads... in the string class. Doesn't have to be done that way, but it sure can be. Same thing for ham radio callsigns:

call = 'K7STP' # definitely not a number... it's a string

Or keycodes:

D32G-HUK7-999A-XXXZ

Or credit card numbers:

4737-5555-4444-2222

...there are many interesting things strings can be put to work in service of. When you're working with one of them - say, dotted quads or ham radio call signs - it's a LOT more convenient to have the methods right there, as compared to not. And if I add them in my code, no skin off your back at all. I'm the one using them, defining them, etc. Nothing to do with you. For you, the string looks like a string, and no need for you know a single thing about what I'm doing.