object methods aren't getting called when the object is a string

[samwyse]

The interpolation spec says,

This tag's content names the data to replace the tag.  A single period (`.`)
indicates that the item currently sitting atop the context stack should be
used; otherwise, name resolution is as follows:

1) Split the name on periods; the first part is the name to resolve, any
remaining parts should be retained.

2) Walk the context stack from top to bottom, finding the first context
that is a) a hash containing the name as a key OR b) an object responding
to a method with the given name.

3) If the context is a hash, the data is the value associated with the
name.

4) If the context is an object, the data is the value returned by the
method with the given name.

5) If any name parts were retained in step 1, each should be resolved
against a context stack containing only the result from the former
resolution.  If any part fails resolution, the result should be considered
falsey, and should interpolate as the empty string.

Data should be coerced into a string (and escaped, if appropriate) before
interpolation.

I interpret this to mean that '{{person.upper}}' in the context {'person': 'Mom"'} should find the key 'person' in the context, use 'Mom' as the data and place it on the context stack, and then search that object (a string) for a method named 'upper', invoke that method, and place the returned value ('MOM') on the top of the context stack.

Note that '{{#person}}{{.}}{{/person}}' returns 'Mom', indicating that 'Mom' is indeed on the top of the context stack. However, both '{{person.upper}}' and '{{#person}}{{upper}}{{/person}}' return an empty string, indicating that method resolution and invocation is not being performed.

[cjerdonek]

Pystache doesn't treat instances of built-in types (e.g. strings, integers, etc) as "objects." You can see this in the code comment here. This behavior was added as part of issue #81. There are also test cases for it. Basically, the issue is that calling methods on built-in types can result in accidentally "shadowing" an intended context value, if a name accidentally matches a method name on a built-in type (of which there are many).

[cjerdonek]

I'm closing this for the reasons listed in my previous comment and because there wasn't any further discussion after waiting a couple weeks.