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

[Sunjay Varma]

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

 

[Terry Reedy]

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.

No, that is fundamentally wrong. Rebinding a name in a particular
namespace only deletes the association in that namespace.

Built-in classes are just that. You cannot get rid of them. They are
used in the operation of the interpreter.

For some reason though,
even though the interpreter says that str == type("hello"),
overwriting the str name changes nothing in the literal.

Right. By design. String and number literals are always string and
number literals.

Is this a bug?

No.

 

[rusi]

For some reason, sub-classing and overwriting a built-in type does not
change the behavior of the literal.

Have you looked through this?
http://www.python.org/download/releases/2.2/descrintro/#subclassing

[Dunno exactly how current it is -- This was at 2.2, most people are
likely to be at 2.6 now or later. Maybe others can say...]

 

[scattered]

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.

 

[John Roth]

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.

-Sunjay03

This is neither a bug nor a feature, it's simply the way that
Python works. Literals are handled during compilation; the built-in
types are run-time objects.

Python is not a language where a script can change compile-time
behavior. Doing that would make it a very different language, and
would put it into a very different niche in the language ecology.

John Roth