On Sun, 15 Aug 2010 14:57:44 +0100, Baz Walter <[email protected]> wrote: > On 14/08/10 22:49, Phil Thompson wrote: >> On Sat, 14 Aug 2010 22:41:07 +0100, Baz Walter<[email protected]> wrote: >>> On 14/08/10 16:29, Phil Thompson wrote: >>>> I may make it more restrictive (ie. more correct, but maybe at the cost >>>> of >>>> breaking code) by requiring bytes objects (for Python3) and str objects >>>> (for Python2), and no longer allowing str objects (for Python3) and >>>> unicode >>>> objects (for Python2). >>> >>> fwiw, this sounds fine to me - i have always done things that way as it >>> seems the most pythonic (EIBTI and all that). >>> >>> just to be clear, though: if you did this, it would still be possible to >> >>> pass a bytearray to the scintilla apis that /retrieve/ text, right? >> >> Can you give me a specific example? > > not sure how specific you meant, but most of my usage involves code like: > > result = bytearray(end - start) > self.SendScintilla(MESSAGE, start, end, result) > > where MESSAGE can be any of SCI_GETTEXTRANGE, SCI_GETSELTEXT, > SCI_GETSTYLEDTEXT, etc. > > the code would then go on to use the bytearray directly and/or decode to
> a unicode object. > > from a python point of view, i suppose it might be nicer if those apis > returned a tuple of (length, bytes) rather than modifying the argument. As of tonight's snapshot any char * argument to SendScintilla must be (for Python v3) a bytes object or one that implements the buffer protocol (which is why bytearray works). It can no longer be a str (just as in Python v2 it could never be a unicode object). str objects must be explicitly encoded to a bytes object. Phil _______________________________________________ QScintilla mailing list [email protected] http://www.riverbankcomputing.com/mailman/listinfo/qscintilla
