Re: [patch] [python] Fix Python 3 build and testsuite issues

[Phil Muldoon <pmuldoon@redhat.com>]

On 20/08/13 21:32, Phil Muldoon wrote:
> On 20/08/13 20:59, Tom Tromey wrote:
>>>>>>> "Phil" == Phil Muldoon <pmuldoon@redhat.com> writes:
>>
>> Phil> @@ -236,7 +236,7 @@ class FrameVars(object):
>> Phil>          # SYM may be a string instead of a symbol in the case of
>> Phil>          # synthetic local arguments or locals.  If that is the case,
>> Phil>          # always fetch.
>> Phil> -        if isinstance(sym, basestring):
>> Phil> +        if isinstance(sym, str):
>> Phil>              return True
>>
>> Does this work in all versions?
>> I thought perhaps hasattr would be more robust here.
> 
> Tested on both 2.7.3 and 3.3.0 on Fedora 18.  basestring seems to
> originate from Python 2.3 and was retired in 3.0.

I was partially wrong here.

Strings in Python 3 are now always encoded and are encapsulated by the
"str" class.

In Python 2 you had str() and unicode(), where unicode was encoded and
str just represented bytes (IE just an unencoded string).

So in Python 2:

>>> a = "foo"
>>> b = u"bar"
>>> type(a)
<type 'str'>
>>> type(b)
<type 'unicode'>
>>> print isinstance(a,str)
True
>>> print isinstance(b,str)
False

Whereas in Python 3:

>>> a = "foo"
>>> b = u"bar"
>>> type(a)
<class 'str'>
>>> type(b)
<class 'str'>
>>> print (isinstance(a,str))
True
>>> print (isinstance(b,str))
True

So the patch hunk:


-        if isinstance(sym, basestring):
+        if isinstance(sym, str):

Will work in all case for Python 3.  Will work in the str() case of
Python 2.x (unencoded), but will not work for encoded unicode strings
in Python 2.x.

Reading around the suggestion seems to be to do this:

try:
   # basestring catches both types of Python 2.x strings
   if isinstance(sym, basestring)
        return True
except NameError:
   # If we are here, basestring does not exist, so Python 3.x
   if isinstance(sym, str)
        return True
# Continue to process objects that are not a string.

This kind of sucks.  We could come back to a hasattr test for a
string, but I am just not sure what is feasible and will remain stable
through Python 2.x and 3.x release cycles.  We could reverse the
condition and hasattr for a symbol like object, but see my previous
note on the expectations of the API.

Regardless, I think at some point in GDB's future we will have to
declare "Python 3.x only from GDB X.X on" as maintaining the two
versions of Python is going to become arduous.

Cheers,

Phil