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