[Python-3000] How best to handle failing tests in struni?

[Ron Adam]

Brett Cannon wrote:
> On 6/20/07, Guido van Rossum <guido at python.org> wrote:
>> On 6/20/07, "Martin v. Löwis" <martin at v.loewis.de> wrote:
>>>> So, my question is how best to handle this test (and thus other tests
>>>> like it).  Should it just continue to fail until someone fixes
>>>> _bsddb.c to accept Unicode keys (and thus start up a FAILING file
>>>> listing the various tests that are failing and doc which ones are
>>>> expected to fail until something specific changes)?  Or do we silence
>>>> the failure by making the constants pass through str8?  Or should str8
>>>> not even be used at all since (I assume) it won't survive the merge
>>>> back into p3yk?
>>> This goes back to the text-vs-binary debate. I _think_ bsddb inherently
>>> operates on binary data, i.e. neither keys nor values need to be text
>>> in some sense.
>>>
>>> So the most natural way would be to make it accept binary data only on
>>> input, and always produce binary data on output. Any *usage* that
>>> expect to be able to pass in strings is broken.
>> OTOH, pragmatically, people will generally use text strings for db keys.
>>
>> I'm not sure how to decide this; perhaps we need to take it public.
> 
> That's fine since I don't want to fix it.  =)  So kick this out to
> python-dev then?
> 
> And speaking of struni, when I realized that fixing _bsddb.c was not
> going to be simple, I moved on to the next test (test_asynchat) and
> came across a string with an 's' prefix.  Just to make sure I got
> everything straight, str8 produces a classic str instance (pure ASCII)
> and a string with an 's' prefix is a str8 string.  Other there any
> other differences to be aware of when working on the branch?

There's no 'u' prefix on unicode strings obviously.  ;-)

The 's' prefix was my idea as a temporary way to differentiate unicode and 
str8 while the conversion is taking place.  It will most likely be removed 
after all or most all the str8 values are replaced by unicode or bytes.

Ron


> And I assume the PyString API is going away, so when working on a
> module one should just tear out use of the API and convert it over to
> PyUnicode, correct?  And do the same for "s" format characters in
> Py_BuildValue and PyArg_ParseTuple?
 >
> I just want to get an idea of the basic process going on to do the
> conversion so that I don't have to figure out the hard way.