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-requ...@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-requ...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
