I have tried out the buffer type in Twisted - now we have new problems to fix! but this has allowed progress - as well as in test_types. That's a fairly minimal test, but we do need to cover this case:

         if str(a + buffer('def')) != 'asdfdef':
             self.fail('concatenation of buffers yields wrong content')

So this is looking great. More below:

On Sun, Sep 29, 2013 at 5:15 PM, fwierzbicki@gmail.com <fwierzbicki@gmail.com> wrote:
On Sat, Sep 28, 2013 at 4:18 PM, Jeff Allen <ja.py@farowl.co.uk> wrote:
> The alert will have noticed that Jython now supports the buffer type.
> buffer() is reasonably complete (not sure about comparisons) but the
> thing that lets it down is that other objects do not know how to accept
> the buffer interface as an argument. That needs correcting, and I'm
> starting with str (PyString).
>
> I have worked through the API of str, and almost everywhere a str/bytes
> argument is allowed, it will accept a buffer in CPython 2.7.5. It
> doesn't accept a memoryview in the same places, until Python 3k. In
> Jython buffer() and memoryview() both implement the same buffer
> interface, so to accept one is to accept the other (unless I actively
> prevent it for consistency with CPython, which I think foolish).

No need for such foolish consistency, for sure.
 
>
> I would like to check that these things are not bad ideas before I write
> too much:
>
> 1. I will change the signature of about a dozen of the exposed methods
> to take a PyObject argument where they currently take Java String. (They
> are package-visible, so I should find any call sites easily.)
Is it possible to overload the functions so that we still take
java.lang.String? I think it would be too bad if we had to lose the
ability to call the methods that take java.lang.String. For example,
if we are calling from Java we might have a java.lang.String and it
would be inconvenient to be forced to wrap it in a PyObject first.
Thoughts?

Agreed with this line of thought.
 

> 2. l will re-use the implementation of affected methods, but have a
> helper function that derives the String from whatever the PyObject
> argument is. This helper function is also responsible for raising a
> TypeError. The CPython 2.7.5 message is "expected a character buffer
> object". I propose to use the 3.3-ish "expected str, bytearray or buffer
> compatible object".

Makes sense. We try to keep error strings as closes as possible to CPython as possible, but I don't see this necessary here.
 
Might it be possible to just keep the methods public?

Not certain what Frank is asking for here.
 

> 3. The CPython 3.3 bytes type accepts memoryview in a few more places
> than 2.7.5 accepts buffer. I plan to accept either in all the places 3.3
> accepts memoryview.
That sounds good to me.

Agreed on that.

- Jim