I have the python 2.6+ & 3.2+ compatible code done.  Search the mailing 
list for python3 (no space) for more details. 

On Thursday, March 7, 2013 1:05:59 PM UTC-8, Charles Law wrote:
>
> I did some work on this a few months back.  If you search the mailing list 
> for python3 (no space) you can find the thread.
>
> The work I did is pretty rough - it was mostly a proof on concept.  I have 
> a repo that generates python3 files with the suffix pb2_py3.  My code 
> passes all the unittests and I was able to read/write data to Riak, and 
> verified the data wrote correctly using the official python 2 protobufs.
>
> If/when I get the time, I'd like to get the same code working for Python 2 
> and 3.  The main hurdle is the use of metaclasses since 2to3 doesn't 
> convert those correctly.  I have seen there are some tricks to get this 
> working using the metaclass's constructor (takes in name, bases & a dict), 
> but I haven't experimented with this yet and don't want the code generators 
> to generate a dict to pass in.  After that I think using from __future__ 
> import unicode_literals will cover most of the leftover tricky bits, but 
> it's hard to say without diving in.
>
> On Wednesday, February 6, 2013 6:17:58 AM UTC-8, Wojciech Danilo wrote:
>>
>> Hi! I\m also very interested in prtobuf support inPy3. Are there any 
>> newsin this topic?
>>
>>
>> W dniu środa, 11 lipca 2012 14:59:37 UTC+2 użytkownik Roberto Alsina 
>> napisał:
>>>
>>> On Tuesday, July 10, 2012 8:13:54 PM UTC-3, Gregory P. Smith wrote:
>>>>
>>>> [resending, initial send didn't make it to the list]
>>>>
>>>> On Tuesday, July 10, 2012 8:06:34 AM UTC-7, Roberto Alsina wrote:
>>>>>
>>>>> Hello, as part of porting one a product to Python 3, we are willing to 
>>>>> port protobuf which is one of our dependencies.
>>>>>
>>>>> Would a python 2.6 / 3.3 codebase be acceptable for merging upstream? 
>>>>> Or would it have to support 2.4?
>>>>>
>>>>> I ask because the effor to achieve both is quite different.
>>>>>
>>>>  
>>>> I'd aim for 2.6 / 3.2 rather than 3.3 because 3.2 is the python 3 
>>>> version available as a package in recent stable linux distros.  We're 
>>>> primarily using 2.6 (soon 2.7) at Google.  People with a need for support 
>>>> of Python versions earlier than 2.6 should be able to use an older release 
>>>> of the protobuf compiler.
>>>>
>>>>
>>> I will talk with the devs. If it's significantly less effort to aim for 
>>> 3.3, we may go with that, if it's not, then 3.2
>>>  
>>>
>>>> Obviously I haven't spent any time on porting it to Python 3 yet.  Hit 
>>>> me up for code reviews or discussion as you see fit.  We'll be needing 
>>>> this 
>>>> as well but some other work for our 3.x transition has been a higher 
>>>> priority for me so far so getting to this has been further down my list.
>>>>
>>>> My rough thoughts on python 3.x support for protobuf:
>>>>
>>>> I'd be awesome if the protobuf Python libraries & tests used by the 
>>>> generated code could be safe in both 2.6 and 3.2 without the need for 
>>>> conversion using 2to3.  But... that can get messy depending on the code. 
>>>>  If that gets messy, at least make sure that it convert cleanly with 2to3.
>>>>
>>>> The protoc generated code has more options: work in both, work when 
>>>> passed through 2to3, or generate 2.x and 3.x specific versions of the code 
>>>> based on a protoc command line flag.
>>>>
>>>
>>> I am aiming for generating version specific code via option.
>>>  
>>>
>>>>
>>>> I prefer anything that avoids a 2to3 step when possible.  A build 
>>>> system already needs to know which version of python it is targeting so it 
>>>> seems reasonable to pass a protoc command line flag but I'm not wedded to 
>>>> that idea.
>>>>
>>>> After reading what I wrote above and comparing it to my post to this 
>>>> list last year quoted below, the main thing that has changed is that I 
>>>> don't care about 2.4 anymore. :)
>>>>
>>>>
>>> Which is good :-)
>>>  
>>>
>>>> -gps
>>>>
>>>> PS in order to accept patches upstream we'll need a contributor license 
>>>> agreement signed.  Quoting previous messages asking for that:
>>>> """
>>>> http://code.google.com/legal/individual-cla-v1.0.html -- If you own 
>>>> copyright on your patch.  (This can be signed via a simple web form at the 
>>>> bottom of the page.)
>>>> http://code.google.com/legal/corporate-cla-v1.0.html -- If your 
>>>> employer does.
>>>>
>>>>>
>>>>>>
>>> That should not be a problem. 
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/protobuf?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.


Reply via email to