I found some very odd behaviour in Python's very basic types

[scattered]

On Mar 10, 12:47 am, Sunjay Varma <varma.sun... at gmail.com> wrote:
> For some reason, sub-classing and overwriting a built-in type does not
> change the behavior of the literal. Logically speaking, overwriting a
> name, such as str, should delete the basic str type, and replace it
> with the new class or object put in its place. For some reason though,
> even though the interpreter says that str == type("hello"),
> overwriting the str name changes nothing in the literal. Is this a
> bug? I'm not sure.
>
> I also have just started this very discussion (although in more words)
> on Python-Forum.org. Check it out there as well:http://python-forum.org/pythonforum/viewtopic.php?f=18&t=24542&p=113404
>
> I know a lot of very experienced Python programmers view these mailing
> lists. It would be fantastic if this could get fixed. Python would get
> momentously more powerful if this feature was implemented. People
> would be able to apply new methods and attributes to strings, lists,
> dictionaries, sets, and all the built-in types. Improving them when
> needed and allowing for extended functionality.
>
> If you prefer to email me directly, just use this email:
> haimunt(at)yahoo(dot)com
>
> Thanks for your help! I hope we can discuss this (possible) bug. :)
>
> -Sunjay03

I agree with the others that this is a desirable feature rather than a
bug. For one thing, most nontrivial scripts import at least one
module. Those modules will implicitly assume that, e.g., string
literals mean what the language specification says that they mean. If
you were able to change the built-in meaning of strings then how would
these modules function? If you say that they are in their own
namespace and wouldn't be effected by your renaming of str - then you
would still have what you call the odd behavior of the original
meaning of built-in types leaking through your attempt to redefine
them. On the other hand - if the change in basic types *did* apply to
the code in imported modules - that would almost certainly break a lot
of modules. At best you would have some of the murky semantics of
dynamic typing, where the actual meaning of code can't be determined
lexically but would depend on the calling sequence.

In any event - why would you want to change the meaning of built-in
types? I've always thought of OOP as a means to extend a language, not
rewrite it.