Open Stack

On 4/24/15 4:18 PM, Sean Toner wrote:
> On Friday, April 24, 2015 11:20:03 AM Joshua Harlow wrote:
>> Sean Toner wrote:
>>> If written to use python 3, I hope it will use all the new features
>>> of python 3.4 moving forward.
>>>
>>> For example, argument annotations, coroutines, asyncio, etc.  At my
>>> last workplace, we tried to make our project python2 and 3
>>> compatible (ie, you could run it under 2.7 or 3.3+) but this was
>>> the worst of all worlds.
>> Likely the reality of things is different from the desires :)
>>
>> I know we'd all love to just do the above (or some of us would like
>> to), but we also need to think about what shiny new features really
>> make the quality of nova any better (IMHO some of the above really
>> don't change much for the better...)
>>
>> Out of curiosity why was your experience 'the worst of all worlds'?
> Like I answered to Victor, it means that you don't get the nice new
> features only available in python3 (argument annotations, coroutines,
> namespace packaging, etc) while at the same time dealing with the
> inconsistencies between python2 and 3 code.

These are all very new features who's acceptance and maturity is yet to 
happen.  Even if these things were available in Python 2 right now, we 
should be very hesitant to sprint down new roads; these aren't assured 
to be winning features.   Also, I work in the realm of Py2k/3k 
cross-compatible code exclusively for several years now and I think 
you're overstating its difficulty, as did the core Python developers 
originally when they made us all believe we'd need a code rewriting tool 
in order to use Python 3, which then led us way down the wrong road 
which we all had to backtrack from.

>
> For example, having to manage some imports, dealing with some functions
> now returning bytes instead of str, and all kinds of other fun :)
>
> Here's one example of having to change an import:
>
> try:
>      from urllib.request import urlopen
>      from urllib.parse import urlparse as urlparse
> except ImportError:
>      from urllib2 import urlopen
>      from urlparse import urlparse
compatibility layers like six handle issues like these pretty simply, 
plus I thought we had some requests-like compatibility layer in place in 
any case.


>
> I also had some code that created a subprocess.Popen object to execute
> some command.
i would have used the multiprocessing library instead.


>   Some commands output got returned as a regular str, and
> some others got returned as bytes.  So I wound up in my class creating a
> defensive decorator function that called
>
> if  isinstance(output, bytes):
>    return output.decode()
>
> And that's just 2 that popped into my head :)

How would not being Py2k compatible help with dealing with functions 
that randomly return either bytes or strings?



> And it was frustrating
> having to do extra work, and yet not be able to partake of all the
> python3 goodies.
>
> But, if this is a stepping stone to a pure python3 environment even if
> that takes until python2 to EOL, I'm ok with that :)
>
>>> Regards,
>>> Sean
>>>
>>> On Friday, April 24, 2015 04:34:48 AM Victor Stinner wrote:
>>>> Hi,
>>>>
>>>> Porting OpenStack applications during the Liberty Cycle was
>>>> discussed
>>>> last days in the thread "[oslo] eventlet 0.17.3 is now fully Python
>>>> 3
>>>> compatible".
>>>>
>>>> I wrote a spec to port Nova to Python 3:
>>>>      https://review.openstack.org/#/c/176868/
>>>>
>>>> I mentioned the 2 other Python 3 specs for Neutron and Heat.
>>>>
>>>> You can reply to this email, or comment the review, if you want to
>>>> discuss Python 3 in Nova, or if you have any question related to
>>>> Python 3.
>>>>
>>>> See also the Python 3 wiki page:
>>>>      https://wiki.openstack.org/wiki/Python3
>>>>
>>>> Thanks,
>>>> Victor
>>>>
>>>> ___________________________________________________________________
>>>> ___ ____ OpenStack Development Mailing List (not for usage
>>>> questions) Unsubscribe:
>>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> ____________________________________________________________________
>>> ______ OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> ______________________________________________________________________
>> ____ OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev