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