How to tell the difference between string and list

[Jan Kokoska]

Hello,

I need to recognize 'var' and ['var'], usually I would use:

if a.__class__() == '':
#string
elif a.__class__() == []:
#list

But unfortunately in Zope PythonScripts, where I need to use this, one
is not supposed to use underscore-prefixed methods as I just found out.

I figure this is a question general enough to post here (and not on the
Zope list), any clues?

TIA

Jan Kokoska

 

[Wolfram Kraus]

Heyho!

Jan Kokoska wrote:
[...]

But unfortunately in Zope PythonScripts, where I need to use this, one
is not supposed to use underscore-prefixed methods as I just found out.

In Zope you can use same_type():
same_type(a, '')
same_type(a, [])
(See Zope Book -> Advanced Zope Scripting -> Built-in Functions)

I figure this is a question general enough to post here (and not on the
Zope list), any clues?

TIA

Jan Kokoska

HTH,
Wolfram

 

[Michael Hudson]

Hello,

I need to recognize 'var' and ['var'], usually I would use:

if a.__class__() == '':
#string
elif a.__class__() == []:
#list

That's a very strange way of doing it in any situation!

Cheers,
mwh

 

[John J. Lee]

I need to recognize 'var' and ['var'], usually I would use:

[...]

All the other solutions posted are bad because they fail for
user-defined string-like classes (unless those classes use the new 2.2
features by deriving from str or unicode). As long as your strings
aren't huge:

def isstringlike(x):
try: x+""
except TypeError: return False
else: return True


I think I stole this off Alex Martelli.


John

 

[Bengt Richter]

I need to recognize 'var' and ['var'], usually I would use:

[...]

All the other solutions posted are bad because they fail for
user-defined string-like classes (unless those classes use the new 2.2
features by deriving from str or unicode). As long as your strings
aren't huge:

def isstringlike(x):
try: x+""
except TypeError: return False
else: return True


I think I stole this off Alex Martelli.

There are some caveats in using that re side effects and unanticipated semantics,
e.g., a contrived example of both:
... def __add__(s, o):
... if isinstance(o, str): print '<<side effect!!>>'; return list.__add__(s,[o])
... return list.__add__(s,o)
...

>>> sl = Slist(['abc','def'])
>>> sl ['abc', 'def']
>>> sl + 'ghi'

>>> def isstringlike(x):

... try: x+""
... except TypeError: return False
... else: return True
...

>>> sl ['abc', 'def']
>>> isstringlike(sl)

<<side effect!!>>
True

Is it? IMO, no. Accepting addition of strings does not a string make. You can't
assume anything about the result or the object except that string addition is defined.

The side effect here is contrived, but adding a string to a list could be handy
if you have a list-like object that deals with strings and might not want the
behavior of an ordinary list, which is:

>>> s2 = ['abc','def']
>>> s2 + 'ghi'

Traceback (most recent call last):
['abc', 'def', 'g', 'h', 'i']

Regards,
Bengt Richter

 

[John J. Lee]

s2 = ['abc','def'] [...]>
s2 += 'ghi'
s2

['abc', 'def', 'g', 'h', 'i']

That's not what the code I posted tests for.

And the fact that having a+b not raise TypeError breaks that function
seems to me to be a good reason not to do that.


John

 

[Bengt Richter]

(e-mail address removed) (Bengt Richter) writes:
[...]

s2 = ['abc','def'] [...]>
s2 += 'ghi'
s2

['abc', 'def', 'g', 'h', 'i']

That's not what the code I posted tests for.

You mean __iadd__? I know, I was just showing ordinary list behavior, and
showed that as well to imply that that's also something you might want to override
in a consistent way if you were overriding __add__ as in my example.

And the fact that having a+b not raise TypeError breaks that function
seems to me to be a good reason not to do that.

Convince me ;-) _Any_ object with an __add__ method that
does not exclude a string as a thing to add would pass your/Alex's
isstringlike test. IMO that's too big a set of unanticipatable possibilites.
Do you really want to dictate "never accept a str instance as other in __add__(self, other)" ;-)

What do you want to be able to assume about an object obj for which isstringlike(obj)
returns True, besides that it accepts strings for addition? Do you want to make those
additional assumptions requirements for all objects that do pass the isstringlike test?
Don't forget, an object's __add__ could be defined to accept _anything_ for addition,
and a string would just be a generic thing, whose stringness was really irrelevant
to the adding object. Are you making other assumptions based on isstringlike?
If so, I think those assumptions should be an explicit part of the test,
or you are setting yourself up for using the test and assuming the wrong
things about some object. You can say you'll use exceptions will sort those things out,
but then why pre-screen for stringlikeness? You may have a use case,
but I suspect it will be context-dependent.

The test is fine in a context where you can reasonably anticipate the
mix of objects to be tested, but as a universal test, I would say
s/isstringlike/willaddstrings/ or perhaps
s/isstringlike/willaddatleastonestringbutyoumayhaveusedupthequota/ ;-)

Regards,
Bengt Richter

 

[John J. Lee]

(e-mail address removed) (Bengt Richter) writes:
[...]

s2 = ['abc','def'] [...]>
s2 += 'ghi'
s2
['abc', 'def', 'g', 'h', 'i']

That's not what the code I posted tests for.

You mean __iadd__? I know, I was just showing ordinary list
behavior, and showed that as well to imply that that's also
something you might want to override in a consistent way if you were
overriding __add__ as in my example.

What? list.__add__(self, "") raises TypeError, which means lists do
work OK with isstringlike().

[...]

Don't forget, an object's __add__ could be defined to accept
_anything_ for addition, and a string would just be a generic thing,
whose stringness was really irrelevant to the adding object. Are you
making other assumptions based on isstringlike?

That's true: especially given the sequence-ness of strings, which was
the whole motivation for this function in the first place! In fact,
isstringlike(UserList()) is true. Bah.

If so, I think those assumptions should be an explicit part of the
test, or you are setting yourself up for using the test and assuming
the wrong things about some object. You can say you'll use
exceptions will sort those things out,

[...]

Well, sometimes that's just the problem: exceptions *won't* get
raised, because strings are sequences.

I guess it's all depends on the particular case. :-(


John