[Tutor] subclassing strings

[Tiger12506]

Ahh. Excellent questions.

> I'm playing around with subclassing the built-in string type, and
> realizing there's quite a bit I don't know about what's going on with
> the built-in types. When I create a string like so:
>
> x = 'myvalue'
>
> my understanding is that this is equivalent to:
>
> x = str('myvalue')

Um. Yeah. Sort of. Python creates the 'myvalue' as a string object as it
interprets it. So str('myvalue') is just saying create a string object from
a string object. But I think I know what you intended to ask, see below.

> and that this second form is more fundamental: the first is a
> shorthand for the second. What is 'str()' exactly? Is it a class name?

>>> str
<type 'str'>

[edit] Here's a good thought I just thought. These are equivalent
>>> a = "hello"
>>> str(a) == a.__str__()
True
>>> repr(a) == a.__repr__()
True
>>> str(a) == str.__str__(a)
True
>>> repr(a) == str.__repr__(a)

It's a built-in type. That is~ it has a constructor, destructor, methods,
etc. like any other object in python. When you say str('myvalue') you are
passing the python string object containing 'myvalue' into the constructor
the str type and creating a new string object.

> If so, is the string value I pass in assigned to an attribute, the way
> I might create a "self.value =" statement in the __init__ function of
> a class I made myself? If so, does that interior attribute have a
> name? I've gone poking in the python lib, but haven't found anything
> enlightening.

Here we come to secrets of Python. It's written in C. Since str is a
built-in type, the storing of the variable you ask about is a C style buffer
(*not* a linked list - strings are immutable). Whenever you call str(),
Python constructs a new python object and stores the string in a new C-style
buffer. The same occurs for adding string together with '+', and is why
"".join(list_of_strs)  is the preferred method (Because python can build the
buffer all in one go)

No it's not accessible from python. (At least I don't think so. And you
never should need to)

> I started out wanting to subclass str so I could add metadata to
> objects which would otherwise behave exactly like strings.

Okay.

> But then I
> started wondering where the actual value of the string was stored,
> since I wasn't doing it myself, and whether I'd need to be careful of
> __repr__ and __str__ so as not to interfere with the basic string
> functioning of the object.

Okay.

> As far as I can tell the object functions
> normally as a string without my doing anything – where does the string
> value 'go', and is there any way I might inadvertently step on it by
> overriding the wrong attribute or method?

Okay. You can overwrite string methods like __str__ and __repr__. If you
look it up, the definition of these special methods (in layman's terms) is
that whenever str() is called on an object (explicitly or *implicitly*) then
the objects __str__ method is called which will return a string object which
should give an appropriate representation. The built-in string object does
the equivalent of

def __str__(self):
  return self
def __repr__(self):
  return "'%s'" % self      #Notice this will give extra single quotes
around string

No, you will not interfere with the internal representation of the string,
but you can change completely how that representation is presented to the
user of the object.

For an implemented simple example just say the word.

HTH,
Tiger12506

PS. Anyone who's interested. A significant study of C has brought me to
these conclusions.
immutable -> implemented with static buffer
mutable -> implemented with linked list
Anyone know a little more detail?