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 protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
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