[I18n-sig] Strawman Proposal: Smart String Test

[Paul Prescod]

On Fri, 9 Feb 2001, M.-A. Lemburg wrote:

> > types.isstring returns true if the object could be directly interpreted
> > as a string. This is defined as: "implements the string interface and is
> > compatible with the re regular expression engine."
>
> re compatibility is given by read buffer compatibility; it is
> not restricted to strings. In fact re works on buffers and mmap'ed
> files too.

There are two conditions listed above. mmap'd files (for example) do not
support the string interface. There is no join(), search() etc.

> > At the moment no user
> > types fit this criteria so there is no mechanism for extending the
> > behavior of the types.isstring function yet. It's initial behavior is:
> >
> > def isstring(obj):
> >     return type(obj) in (StringType, UnicodeType)
>
> Looks like a hack which would only serve a temporary need...

So? Sometimes a temporary hack is the right thing to do. If you want to
revive the types sig to figure out a hierarchical interface concept then
go ahead. I trying to solve a very simple, localized and pervasive
problem:

type(foo)==type("")

You proposed that we should handle it by having a tuple or list called
StringTypes in the types module. I tried to make a solution that is more
forward-thinking because we can bring in your interface hierarchy magic
later. Code will just keep working when we figure out how to "subclass
strings" because the determination will be made by the isstring
abstraction.

Is there a practical problem with this solution?

 Paul Prescod