[PATCHES] Build pytalloc for two Python versions at once, port to py3
pviktori at redhat.com
Tue Mar 17 05:16:03 MDT 2015
On 03/16/2015 08:51 PM, Andrew Bartlett wrote:
> On Mon, 2015-03-16 at 12:14 +0100, Petr Viktorin wrote:
>> On 03/14/2015 10:17 AM, Andrew Bartlett wrote:
>>> On Fri, 2015-03-13 at 14:00 +0100, Petr Viktorin wrote:
>>>> I believe that it's impossible to do while still keeping things clear.
>>>> I did try, however, to keep the deviations from Python 3 minimal. Here
>>>> they are:
>>>> * PyStr (to use either PyUnicode or PyBytes depending on the version)
>>> Can't we code to the Python3 API, and have it map both to python2
>>> strings, either as raw bytes or pushing (presumed internal mapping) UTF8
>>> to UTF8? (Yes, we really should use the unix charset, but these parts
>>> of samba without unix charset == utf8 is just broken).
>> Unfortunately, no. A lot of the Python 3 API is also available in Python
>> 2, and using it would bring Python 3 semantics to the Python 2 version.
>> Specifically, to use the py3 API we'd have to use PyUnicode for all
>> human-readable strings.
>> That leaves two choices for py2 behavior:
>> - aliasing PyUnicode to PyString, which would not work where PyUnicode
>> is also needed in Python 2. Not to mention that alasing an existing type
>> to something else would be extremely confusing.
>> - using PyUnicode everywhere, which won't work either. Even if all of
>> Samba's py2 code didn't care if it was getting str or unicode, things
>> like tp_repr (repr() implementation) fail when you return unicode in py2.
> If it helps, the only place I can see PyUnicode being used is that we
> accept, but do not emit, PyUnicode in the pidl DCE/RPC generated code.
> I may not be grepping on the right things, but I also see no other
> references to unicode, except for some .encode('utf-16-le') calls
> creating password values.
That just means Samba didn't make the bytes/unicode split yet.
Everything is a string.
PyUnicode already has a meaning in Python 2. Given the choices here, I'm
much more comfortable introducing a new name, which clearly needs to be
looked up if things go wrong, than hiding new semantics under an old name.
> (This may help explain our ambivalence about the whole reason for
> python3 in the first place)
> When I get some head-space, I'm going to write about the difficulty the
> Samba Team faces with this kind of project. I spoke before about the
> async ldb example, but after ntdb came up, I realise we have been here
> before on other efforts. I'm quite concerned to ensure we don't waste
> your efforts, and that we are all agreed on the risks and benefits.
I'm looking forward to that.
The key difference I see here is that ldb/tdb can continue working
indefinitely. Python 2 will not – or at least after 2.7's 10-year
upstream support goes away, Samba would most likely need to take over
maintaining its own copy.
More information about the samba-technical