Python 2.x and 3.x use survey, 2014 edition
Hi all, Last year a survey was conducted on python 2 and 3 usage. Here is the 2014 edition, slightly updated (from 9 to 11 questions). It should not take you more than 1 minute to fill. I would be pleased if you took that time. Here's the url: http://goo.gl/forms/tDTcm8UzB3 I'll publish the results around the end of the year. Last year results: https://wiki.python.org/moin/2.x-vs-3.x-survey Thank you Bruno
On Dec 10, 2014, at 11:59 AM, Bruno Cauet <brunocauet@gmail.com> wrote:
Hi all, Last year a survey was conducted on python 2 and 3 usage. Here is the 2014 edition, slightly updated (from 9 to 11 questions). It should not take you more than 1 minute to fill. I would be pleased if you took that time.
Here's the url: http://goo.gl/forms/tDTcm8UzB3 <http://goo.gl/forms/tDTcm8UzB3> I'll publish the results around the end of the year.
Last year results: https://wiki.python.org/moin/2.x-vs-3.x-survey <https://wiki.python.org/moin/2.x-vs-3.x-survey>
Just going to say http://d.stufft.io/image/0z1841112o0C <http://d.stufft.io/image/0z1841112o0C> is a hard question to answer, since most code I write is both. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
On Wed, Dec 10, 2014 at 11:10 AM, Donald Stufft <donald@stufft.io> wrote:
On Dec 10, 2014, at 11:59 AM, Bruno Cauet <brunocauet@gmail.com> wrote:
Hi all, Last year a survey was conducted on python 2 and 3 usage. Here is the 2014 edition, slightly updated (from 9 to 11 questions). It should not take you more than 1 minute to fill. I would be pleased if you took that time.
Here's the url: http://goo.gl/forms/tDTcm8UzB3 I'll publish the results around the end of the year.
Last year results: https://wiki.python.org/moin/2.x-vs-3.x-survey
Just going to say http://d.stufft.io/image/0z1841112o0C is a hard question to answer, since most code I write is both.
The same holds for me.
On 10 Dec 2014 17:16, "Ian Cordasco" <graffatcolmingov@gmail.com> wrote:
On Wed, Dec 10, 2014 at 11:10 AM, Donald Stufft <donald@stufft.io> wrote:
On Dec 10, 2014, at 11:59 AM, Bruno Cauet <brunocauet@gmail.com> wrote:
Hi all, Last year a survey was conducted on python 2 and 3 usage. Here is the 2014 edition, slightly updated (from 9 to 11 questions). It should not take you more than 1 minute to fill. I would be pleased
if you
took that time.
Here's the url: http://goo.gl/forms/tDTcm8UzB3 I'll publish the results around the end of the year.
Last year results: https://wiki.python.org/moin/2.x-vs-3.x-survey
Just going to say http://d.stufft.io/image/0z1841112o0C is a hard question to answer, since most code I write is both.
The same holds for me.
That question appears to have just grown a "compatible with both" option. It might make sense to add a similar option to the following question about what you use for personal projects. -n
Remarks heard & form updated. Nathaniel, I'm not sure about that: even if the code is 2- and 3-compatible you'll pick one runtime. 2 others questions now mention writing polyglot code. By the way I published the survey on HN, /r/programming & /r/python: https://news.ycombinator.com/item?id=8730156 http://redd.it/2ovlwm http://redd.it/2ovls4 Feel free to publish it anywhere else, to get as many answers as possible. Bruno 2014-12-10 18:24 GMT+01:00 Nathaniel Smith <njs@pobox.com>:
On 10 Dec 2014 17:16, "Ian Cordasco" <graffatcolmingov@gmail.com> wrote:
On Wed, Dec 10, 2014 at 11:10 AM, Donald Stufft <donald@stufft.io>
wrote:
On Dec 10, 2014, at 11:59 AM, Bruno Cauet <brunocauet@gmail.com>
wrote:
Hi all, Last year a survey was conducted on python 2 and 3 usage. Here is the 2014 edition, slightly updated (from 9 to 11 questions). It should not take you more than 1 minute to fill. I would be pleased
if you
took that time.
Here's the url: http://goo.gl/forms/tDTcm8UzB3 I'll publish the results around the end of the year.
Last year results: https://wiki.python.org/moin/2.x-vs-3.x-survey
Just going to say http://d.stufft.io/image/0z1841112o0C is a hard question to answer, since most code I write is both.
The same holds for me.
That question appears to have just grown a "compatible with both" option.
It might make sense to add a similar option to the following question about what you use for personal projects.
-n
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/brunocauet%40gmail.com
On Wed, Dec 10, 2014 at 5:59 PM, Bruno Cauet <brunocauet@gmail.com> wrote:
Hi all, Last year a survey was conducted on python 2 and 3 usage. Here is the 2014 edition, slightly updated (from 9 to 11 questions). It should not take you more than 1 minute to fill. I would be pleased if you took that time.
Here's the url: http://goo.gl/forms/tDTcm8UzB3 I'll publish the results around the end of the year.
Last year results: https://wiki.python.org/moin/2.x-vs-3.x-survey
Thank you Bruno
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/g.rodola%40gmail.com
I still think the only *real* obstacle remains the lack of important packages such as twisted, gevent and pika which haven't been ported yet. With those ones ported switching to Python 3 *right now* is not only possible and relatively easy, but also convenient. -- Giampaolo - http://grodola.blogspot.com
I disagree. I know there's a huge focus on The Big Libraries (and wholesale migration is all but impossible without them), but the long tail of libraries is still incredibly important. It's like saying that migrating the top 10 Perl libraries to Perl 6 would allow people to completely ignore all of CPAN. It just doesn't make sense. -Mark On Thu, Dec 11, 2014 at 6:47 AM, Giampaolo Rodola' <g.rodola@gmail.com> wrote:
On Wed, Dec 10, 2014 at 5:59 PM, Bruno Cauet <brunocauet@gmail.com> wrote:
Hi all, Last year a survey was conducted on python 2 and 3 usage. Here is the 2014 edition, slightly updated (from 9 to 11 questions). It should not take you more than 1 minute to fill. I would be pleased if you took that time.
Here's the url: http://goo.gl/forms/tDTcm8UzB3 I'll publish the results around the end of the year.
Last year results: https://wiki.python.org/moin/2.x-vs-3.x-survey
Thank you Bruno
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/g.rodola%40gmail.com
I still think the only *real* obstacle remains the lack of important packages such as twisted, gevent and pika which haven't been ported yet. With those ones ported switching to Python 3 *right now* is not only possible and relatively easy, but also convenient.
-- Giampaolo - http://grodola.blogspot.com
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/wizzat%40gmail.com
On Thu, Dec 11, 2014 at 11:35 AM, Mark Roberts <wizzat@gmail.com> wrote:
I disagree. I know there's a huge focus on The Big Libraries (and wholesale migration is all but impossible without them), but the long tail of libraries is still incredibly important. It's like saying that migrating the top 10 Perl libraries to Perl 6 would allow people to completely ignore all of CPAN. It just doesn't make sense.
Things in the Python 2.x vs 3.x world aren't that bad. See: https://python3wos.appspot.com/ and https://wiki.python.org/moin/PortingPythonToPy3k http://stromberg.dnsalias.org/~strombrg/Intro-to-Python/ (writing code to run on 2.x and 3.x) I believe just about everything I've written over the last few years either ran on 2.x and 3.x unmodified, or ran on 3.x alone. If you go the former route, you don't need to wait for your libraries to be updated. I usually run pylint twice for my projects (after each change, prior to checkin), once with a 2.x interpreter, and once with a 3.x interpreter (using http://stromberg.dnsalias.org/svn/this-pylint/trunk/this-pylint) , but I gather pylint has the option of running on a 2.x interpreter and warning about anything that wouldn't work on 3.x.
On Thu Dec 11 2014 at 3:14:42 PM Dan Stromberg <drsalists@gmail.com> wrote:
I disagree. I know there's a huge focus on The Big Libraries (and wholesale migration is all but impossible without them), but the long tail of libraries is still incredibly important. It's like saying that migrating
On Thu, Dec 11, 2014 at 11:35 AM, Mark Roberts <wizzat@gmail.com> wrote: the
top 10 Perl libraries to Perl 6 would allow people to completely ignore all of CPAN. It just doesn't make sense.
Things in the Python 2.x vs 3.x world aren't that bad.
See: https://python3wos.appspot.com/ and https://wiki.python.org/moin/PortingPythonToPy3k http://stromberg.dnsalias.org/~strombrg/Intro-to-Python/ (writing code to run on 2.x and 3.x)
I believe just about everything I've written over the last few years either ran on 2.x and 3.x unmodified, or ran on 3.x alone. If you go the former route, you don't need to wait for your libraries to be updated.
I usually run pylint twice for my projects (after each change, prior to checkin), once with a 2.x interpreter, and once with a 3.x interpreter (using http://stromberg.dnsalias.org/svn/this-pylint/trunk/this-pylint) , but I gather pylint has the option of running on a 2.x interpreter and warning about anything that wouldn't work on 3.x.
Pylint 1.4 has a --py3k flag to run only checks related to Python 3 compatibility under Python 2.
So, I'm more than aware of how to write Python 2/3 compatible code. I've ported 10-20 libraries to Python 3 and write Python 2/3 compatible code at work. I'm also aware of how much writing 2/3 compatible code makes me hate Python as a language. It'll be a happy day when one of the two languages dies so that I never have to write code like that again. However, my point was that just because the core libraries by usage are *starting* to roll out Python 3 support doesn't mean that things are "easy" or "convenient" yet. There are too many libraries in the long tail which fulfill semi-common purposes and haven't been moved over yet. Yeah, sure, they haven't been updated in years... but neither has the language they're built on. I suppose what I'm saying is that the long tail of libraries is far more valuable than it seems the Python3 zealots are giving it credit for. Please don't claim it's "easy" to move over just because merely most of the top 20 libraries have been moved over. :-/ -Mark On Thu, Dec 11, 2014 at 12:14 PM, Dan Stromberg <drsalists@gmail.com> wrote:
I disagree. I know there's a huge focus on The Big Libraries (and wholesale migration is all but impossible without them), but the long tail of libraries is still incredibly important. It's like saying that migrating
On Thu, Dec 11, 2014 at 11:35 AM, Mark Roberts <wizzat@gmail.com> wrote: the
top 10 Perl libraries to Perl 6 would allow people to completely ignore all of CPAN. It just doesn't make sense.
Things in the Python 2.x vs 3.x world aren't that bad.
See: https://python3wos.appspot.com/ and https://wiki.python.org/moin/PortingPythonToPy3k http://stromberg.dnsalias.org/~strombrg/Intro-to-Python/ (writing code to run on 2.x and 3.x)
I believe just about everything I've written over the last few years either ran on 2.x and 3.x unmodified, or ran on 3.x alone. If you go the former route, you don't need to wait for your libraries to be updated.
I usually run pylint twice for my projects (after each change, prior to checkin), once with a 2.x interpreter, and once with a 3.x interpreter (using http://stromberg.dnsalias.org/svn/this-pylint/trunk/this-pylint) , but I gather pylint has the option of running on a 2.x interpreter and warning about anything that wouldn't work on 3.x.
Also keep in mind that not all Python libraries are on PyPI. For non-Python projects with Python bindings (think video players, OpenCV, systemd, Samba), distribution via PyPI doesn't make much sense. And since the Python bindings are usually second-class citizens, the porting doesn't have a high priority. If anyone is wondering why their favorite Linux distribution is stuck with Python 2 – well, I can only speak for Fedora, but nowadays most of what's left are CPython bindings. No pylint --py3k or 2to3 will help there... On Fri, Dec 12, 2014 at 7:24 PM, Mark Roberts <wizzat@gmail.com> wrote:
So, I'm more than aware of how to write Python 2/3 compatible code. I've ported 10-20 libraries to Python 3 and write Python 2/3 compatible code at work. I'm also aware of how much writing 2/3 compatible code makes me hate Python as a language. It'll be a happy day when one of the two languages dies so that I never have to write code like that again. However, my point was that just because the core libraries by usage are *starting* to roll out Python 3 support doesn't mean that things are "easy" or "convenient" yet. There are too many libraries in the long tail which fulfill semi-common purposes and haven't been moved over yet. Yeah, sure, they haven't been updated in years... but neither has the language they're built on.
I suppose what I'm saying is that the long tail of libraries is far more valuable than it seems the Python3 zealots are giving it credit for. Please don't claim it's "easy" to move over just because merely most of the top 20 libraries have been moved over. :-/
-Mark
On Thu, Dec 11, 2014 at 12:14 PM, Dan Stromberg <drsalists@gmail.com> wrote:
On Thu, Dec 11, 2014 at 11:35 AM, Mark Roberts <wizzat@gmail.com> wrote:
I disagree. I know there's a huge focus on The Big Libraries (and wholesale migration is all but impossible without them), but the long tail of libraries is still incredibly important. It's like saying that migrating the top 10 Perl libraries to Perl 6 would allow people to completely ignore all of CPAN. It just doesn't make sense.
Things in the Python 2.x vs 3.x world aren't that bad.
See: https://python3wos.appspot.com/ and https://wiki.python.org/moin/PortingPythonToPy3k http://stromberg.dnsalias.org/~strombrg/Intro-to-Python/ (writing code to run on 2.x and 3.x)
I believe just about everything I've written over the last few years either ran on 2.x and 3.x unmodified, or ran on 3.x alone. If you go the former route, you don't need to wait for your libraries to be updated.
I usually run pylint twice for my projects (after each change, prior to checkin), once with a 2.x interpreter, and once with a 3.x interpreter (using http://stromberg.dnsalias.org/svn/this-pylint/trunk/this-pylint) , but I gather pylint has the option of running on a 2.x interpreter and warning about anything that wouldn't work on 3.x.
On Dec 12, 2014, at 08:07 PM, Petr Viktorin wrote:
If anyone is wondering why their favorite Linux distribution is stuck with Python 2 – well, I can only speak for Fedora, but nowadays most of what's left are CPython bindings. No pylint --py3k or 2to3 will help there...
It's true that some of these are tough. I tried and failed a few times to port Xapian to Python 3. The issue was opened upstream 6 years ago and it's still unresolved: http://trac.xapian.org/ticket/346 OTOH, I ported dbus-python to Python 3 and that worked out much better; we've had solid Python 3 bindings for several years now, which allowed us to port many important Debian/Ubuntu tools to Python 3 and more importantly, do all our new work in Python 3. With other big toolkits like GObject introspection working on Python 3, there's a lot you can do. IME, if the underlying model is string/bytes clean, then the C extension port can sometimes be easier than pure-Python, thanks to cpp games. D-Bus's model is pretty clean, Xapian I found to be not so much (it doesn't help that Xapian is C++ ;). We're actually not terribly far from switching Debian and Ubuntu's default to Python 3. On Debian, the big blocker is the BTS code (which uses SOAP) and on Ubuntu it's the launchpadlib stack. I hope to find time after Jessie to work on the former, and before 16.04 LTS to work on the latter. Not that I disagree that there's a long tail of code that would still benefit a significant population if it got ported to Python 3. By far Python 3 is a better language, with a better stdlib, so the work is worth it. Cheers, -Barry
On 13 Dec 2014 05:19, "Petr Viktorin" <encukou@gmail.com> wrote:
Also keep in mind that not all Python libraries are on PyPI. For non-Python projects with Python bindings (think video players, OpenCV, systemd, Samba), distribution via PyPI doesn't make much sense. And since the Python bindings are usually second-class citizens, the porting doesn't have a high priority.
If anyone is wondering why their favorite Linux distribution is stuck with Python 2 – well, I can only speak for Fedora, but nowadays most of what's left are CPython bindings. No pylint --py3k or 2to3 will help there...
That's a good point. I actually think https://docs.python.org/3/howto/cporting.html#cporting-howto is actually in a worse state than the state the Python level porting guide was in until Brett's latest round of updates, as it covers the underlying technical details of the incompatibilities moreso than the available tools and recommended processes for *executing* a migration. For example, replacing a handcrafted Python extension with a normal C library plus cffi, Cython or SWIG generated Python bindings can deliver both an easier to maintain extension *and* Python 3 compatibility. Similarly, converting an extension from C to Cython outright (without a separate C library) can provide both benefits. It's mainly when converting to one of those isn't desirable and/or feasible that you really need to worry about C API level porting. For that, tools like Dave Malcolm's static CPython extension analyser for gcc could potentially be helpful (as pylint was to Brett's update to the Python level guide), and Lennart also provides some more detailed practical suggestions in http://python3porting.com/cextensions.html I'm sure there are other useful techniques that can be employed, but aren't necessarily well known outside the folks that have been busy implementing these migrations. Barry, Petr, any of the other folks working on distro level C extension ports, perhaps one of you would be willing to consider an update to the C extension porting guide to be more in line with Brett's latest version of the Python level porting guide? Regards, Nick.
On Dec 14, 2014, at 10:14 AM, Nick Coghlan wrote:
Barry, Petr, any of the other folks working on distro level C extension ports, perhaps one of you would be willing to consider an update to the C extension porting guide to be more in line with Brett's latest version of the Python level porting guide?
It's probably at least worth incorporating the quick guide on the wiki into the howto: https://wiki.python.org/moin/PortingToPy3k/BilingualQuickRef Cheers, -Barry
On Sun, Dec 14, 2014 at 1:14 AM, Nick Coghlan <ncoghlan@gmail.com> wrote: [...]
Barry, Petr, any of the other folks working on distro level C extension ports, perhaps one of you would be willing to consider an update to the C extension porting guide to be more in line with Brett's latest version of the Python level porting guide?
I can make it a 20%-time project starting in January, if no-one beats me to it.
On 12/12/2014 1:24 PM, Mark Roberts wrote:
However, my point was that just because the core libraries by usage are *starting* to roll out Python 3 support doesn't mean that things are "easy" or "convenient" yet. ... I suppose what I'm saying is that the long tail of libraries is far more valuable than it seems the Python3 zealots are giving it credit for. Please don't claim it's "easy" to move over just because merely most of the top 20 libraries have been moved over. :-/
I agree that we should refrain from characterizing the difficulty of other peoples' work. Conversions range from trivial to effectively impossible. What we can say is that a) each library conversion make conversion easier for the users of that library and b) the number of conversions continue to increase. I think some are trying to say that the number has reached a point where it is no longer fair to say that conversion is typically impossible. -- Terry Jan Reedy
On Fri, Dec 12, 2014 at 10:24:15AM -0800, Mark Roberts wrote:
So, I'm more than aware of how to write Python 2/3 compatible code. I've ported 10-20 libraries to Python 3 and write Python 2/3 compatible code at work. I'm also aware of how much writing 2/3 compatible code makes me hate Python as a language.
I'm surprised by the strength of feeling there. Most of the code I write supports 2.4+, with the exception of 3.0 where I say "it should work, but if it doesn't, I don't care". I'll be *very* happy when I can drop support for 2.4, but with very few exceptions I have not found many major problems supporting both 2.7 and 3.3+ in the one code-base, and nothing I couldn't work around (sometimes by just dropping support for a specific feature in certain versions). I'm not disputing that your experiences are valid, but I am curious what specific issues you have come across and wondering if there are things which 3.5 can include to ease that transition. E.g. 3.3 re-added support for u'' syntax. -- Steven
On Dec 12, 2014, at 11:55 PM, Steven D'Aprano <steve@pearwood.info> wrote:
On Fri, Dec 12, 2014 at 10:24:15AM -0800, Mark Roberts wrote:
So, I'm more than aware of how to write Python 2/3 compatible code. I've ported 10-20 libraries to Python 3 and write Python 2/3 compatible code at work. I'm also aware of how much writing 2/3 compatible code makes me hate Python as a language.
I'm surprised by the strength of feeling there.
Most of the code I write supports 2.4+, with the exception of 3.0 where I say "it should work, but if it doesn't, I don't care". I'll be *very* happy when I can drop support for 2.4, but with very few exceptions I have not found many major problems supporting both 2.7 and 3.3+ in the one code-base, and nothing I couldn't work around (sometimes by just dropping support for a specific feature in certain versions).
I'm not disputing that your experiences are valid, but I am curious what specific issues you have come across and wondering if there are things which 3.5 can include to ease that transition. E.g. 3.3 re-added support for u'' syntax.
For what it’s worth, I almost exclusively write 2/3 compatible code (and that’s with the “easy” subset of 2.6+ and either 3.2+ or 3.3+) and doing so does make the language far less fun for me than when I was writing 2.x only code. I’ve though a lot about why that is, because it’s certainly not *hard* to do so, and what I think it is for me at least is inherient in the fact you're using a lowest common denominator approach to programming. Because I can only use things which work the same in 2.6+ and 3.2+ it means I cannot take advantage of any new features unless they are available as a backport. Now this is always true of code that needs to straddle multiple versions in order to maintain compatability. However the way it "used" to work is that the newest version, with all the new features, would quickly become the dominant version within a year or two. The older versions might still command a respectable amount of use, but that tended to fall off quicker and it wouldn't be unreasonable to be more aggresive in some situations than others depending on what the new feature was I wanted to use. However when we look at today, the "new" versions are Python 3.4, 3.3, or even 3.2. However I can't really justify for most situations supporting _only_ those things because even today they are not the dominant version (or really close to it in any number I have access too). This means that if I want to take advantage of something newer I'm essentially dropping the largest part of the ecosystem. On top of all of this, I'm not sure I see a point in the near future where this tipping point might happen and the "normal" order of the newest version with the newest features rapidly becoming the dominant version gets restored. I'm sort of holding out hope that the Linux distribution switching to Python 3 as a default might push it over, but I'm also not holding my breath there. So that's basically it, lowest common demoniator programming where it's hard to look at the future and see anything but the same (or similar) language subset that I'm currently using. This is especially frustrating when you see other languages doing cool and interesting new things and it feels like we're stuck with what we had in 2008 or 2010. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
On Dec 13, 2014, at 12:29 AM, Donald Stufft <donald@stufft.io> wrote:
On Dec 12, 2014, at 11:55 PM, Steven D'Aprano <steve@pearwood.info> wrote:
On Fri, Dec 12, 2014 at 10:24:15AM -0800, Mark Roberts wrote:
So, I'm more than aware of how to write Python 2/3 compatible code. I've ported 10-20 libraries to Python 3 and write Python 2/3 compatible code at work. I'm also aware of how much writing 2/3 compatible code makes me hate Python as a language.
I'm surprised by the strength of feeling there.
Most of the code I write supports 2.4+, with the exception of 3.0 where I say "it should work, but if it doesn't, I don't care". I'll be *very* happy when I can drop support for 2.4, but with very few exceptions I have not found many major problems supporting both 2.7 and 3.3+ in the one code-base, and nothing I couldn't work around (sometimes by just dropping support for a specific feature in certain versions).
I'm not disputing that your experiences are valid, but I am curious what specific issues you have come across and wondering if there are things which 3.5 can include to ease that transition. E.g. 3.3 re-added support for u'' syntax.
For what it’s worth, I almost exclusively write 2/3 compatible code (and that’s with the “easy” subset of 2.6+ and either 3.2+ or 3.3+) and doing so does make the language far less fun for me than when I was writing 2.x only code. I’ve though a lot about why that is, because it’s certainly not *hard* to do so, and what I think it is for me at least is inherient in the fact you're using a lowest common denominator approach to programming.
Because I can only use things which work the same in 2.6+ and 3.2+ it means I cannot take advantage of any new features unless they are available as a backport. Now this is always true of code that needs to straddle multiple versions in order to maintain compatability. However the way it "used" to work is that the newest version, with all the new features, would quickly become the dominant version within a year or two. The older versions might still command a respectable amount of use, but that tended to fall off quicker and it wouldn't be unreasonable to be more aggresive in some situations than others depending on what the new feature was I wanted to use.
However when we look at today, the "new" versions are Python 3.4, 3.3, or even 3.2. However I can't really justify for most situations supporting _only_ those things because even today they are not the dominant version (or really close to it in any number I have access too). This means that if I want to take advantage of something newer I'm essentially dropping the largest part of the ecosystem.
On top of all of this, I'm not sure I see a point in the near future where this tipping point might happen and the "normal" order of the newest version with the newest features rapidly becoming the dominant version gets restored. I'm sort of holding out hope that the Linux distribution switching to Python 3 as a default might push it over, but I'm also not holding my breath there.
So that's basically it, lowest common demoniator programming where it's hard to look at the future and see anything but the same (or similar) language subset that I'm currently using. This is especially frustrating when you see other languages doing cool and interesting new things and it feels like we're stuck with what we had in 2008 or 2010.
Oh yea, in addition to this, actually backporting things is becoming increasingly harder the further Python 3 gets developed. When the language was mostly forwards compatible if a new feature/function was added you could often times backport it into your own code in a compat shim by simply copy/pasting the code. However with all the new features being done in Python 3, it's increasingly the case that this code will *not* run on Python 2.6 and 2.7 because it's essentially being written for a different, but similar, language and requires some amount of porting. This porting process might even need to include incompatible changes because of differences in the language (see for example, Trollius). --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
On Sat, Dec 13, 2014 at 4:29 PM, Donald Stufft <donald@stufft.io> wrote:
So that's basically it, lowest common demoniator programming where it's hard to look at the future and see anything but the same (or similar) language subset that I'm currently using. This is especially frustrating when you see other languages doing cool and interesting new things and it feels like we're stuck with what we had in 2008 or 2010.
That's what happens when you want to support a version of Python that was released in 2008 or 2010. Perhaps the impetus for people to move onto Python 3 has to come from people like you saying "I'm not going to support 2.7 any more as of version X.Y", and letting them run two interpreters. It's really not that hard to keep 2.7 around for what expects it, and 3.4/3.5/whatever for everything else. ChrisA
On Dec 13, 2014, at 12:40 AM, Chris Angelico <rosuav@gmail.com> wrote:
On Sat, Dec 13, 2014 at 4:29 PM, Donald Stufft <donald@stufft.io> wrote:
So that's basically it, lowest common demoniator programming where it's hard to look at the future and see anything but the same (or similar) language subset that I'm currently using. This is especially frustrating when you see other languages doing cool and interesting new things and it feels like we're stuck with what we had in 2008 or 2010.
That's what happens when you want to support a version of Python that was released in 2008 or 2010. Perhaps the impetus for people to move onto Python 3 has to come from people like you saying "I'm not going to support 2.7 any more as of version X.Y", and letting them run two interpreters. It's really not that hard to keep 2.7 around for what expects it, and 3.4/3.5/whatever for everything else.
I don’t think this option is really grounded in reality. First of all, it's essentially the route that Python itself took and the side effects of that is essentially what is making things less-fun for me to write Python. Doing the same to the users of the things I write would make me feel bad that I was forcing them to either do all the work to port their stuff (and any dependencies) just so they can use a newer version of my library. It also I think is incredibly likely to backfire on any author who does it unless the thing they are writing is absolutely essential to their users AND there are no alternatives AND it's essential that those people are using a new version of that library. If all of those things are not the case, you're going to end up with a majoritity of users either just stop using your tool all together, switching to an alternative, or just sticking with an old version. I don't think I'm unique in that I like writing software that other people want to and can use. I think it also assumes that people are writing one off scripts and things like that which only use the standard library. I tend to write libraries and work on complex distributed systems. I need to either port the entire stack or nothing. I can't run half of my process in 2.7 and half in 3.4. It's also something I've never had to do in Python before, I've always been able to "follow" with the things I write. I could take a look at, or estimate, the amount of users that dropping an older version of Python and I could say that it was time to drop support for that version because very few people are actively using it and the cost of maintaining support for that version is no longer worth it. This is the same process I go through for *any* backwards incompatible change I make to the things I write and when I drop the old compatability shims. Ironically all versions of Python 3 combined are low enough that if they were the *old* versions and not the *new* versions I'd probably drop support from them for now. Really the major reasons I support them at all is because I hold out hope that maybe at some point it will become the dominant Python and because I try to be a good member of the ecosystem and not hold back the adoption. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
On Sat, Dec 13, 2014 at 5:13 PM, Donald Stufft <donald@stufft.io> wrote:
First of all, it's essentially the route that Python itself took and the side effects of that is essentially what is making things less-fun for me to write Python. Doing the same to the users of the things I write would make me feel bad that I was forcing them to either do all the work to port their stuff (and any dependencies) just so they can use a newer version of my library.
Ultimately, those programs WILL have to be migrated, or they will have to remain on an unsupported system. You have the choice of either continuing to do what you find un-fun (cross-compatibility code) until 2020 and maybe beyond, or stopping support for 2.7 sooner than that. All you're doing is changing *when* the inevitable migration happens. ChrisA
On 13 December 2014 at 16:28, Chris Angelico <rosuav@gmail.com> wrote:
On Sat, Dec 13, 2014 at 5:13 PM, Donald Stufft <donald@stufft.io> wrote:
First of all, it's essentially the route that Python itself took and the side effects of that is essentially what is making things less-fun for me to write Python. Doing the same to the users of the things I write would make me feel bad that I was forcing them to either do all the work to port their stuff (and any dependencies) just so they can use a newer version of my library.
Ultimately, those programs WILL have to be migrated, or they will have to remain on an unsupported system. You have the choice of either continuing to do what you find un-fun (cross-compatibility code) until 2020 and maybe beyond, or stopping support for 2.7 sooner than that. All you're doing is changing *when* the inevitable migration happens.
One of the biggest blockers has been the lack of ready access to Python 3 on RHEL & CentOS (just as a lot of folks waited until RHEL 7 and CentOS 7 were out before they started dropping Python 2.6 support). It's perfectly sensible for folks in that ecosystem to wait for the appropriate tools to be provided at the platform layer to make it easier for them to switch, but that unfortunately has consequences for upstream library and framework developers who have to continue to support those users. The initial release of Software Collections (softwarecollections.org and the associated Red Hat downstream product) was the first step in providing easier access to Python 3 within the RHEL/CentOS ecosystem (as far back as RHEL 6 and CentOS 6), and that approach is still our long term preference for getting user applications out of the system Python (so upstream isn't stuck supporting legacy Python versions for years just because Red Hat is still supporting them for the base RHEL platform). Unfortunately, the usage model for software collections is sufficiently different from running directly in the system Python that a lot of folks currently still prefer to stick with the system version (and that's the case even for the much lower barrier of using the Python 2.7 SCL instead of the system 2.6 installation on RHEL 6). Containerisation is another technology that aims to make it easier to run end user applications and services under newer language runtimes without interfering with the system Python installation. As with software collections, though, the environments that are reluctant to upgrade to newer versions of Python also tend to be reluctant to upgrade to newer deployment technologies, so it will take time for the full impact of the shift to containerisation to make itself felt. Finally, in addition to the existing work on getting Fedora 22 (due mid next year) to only ship Python 3 on the LiveCD and other similarly minimalist installations, Slavek (the lead Python maintainer for Fedora & RHEL) is now also actively working on getting Python 3 into EPEL 7: https://fedoraproject.org/wiki/User:Bkabrda/EPEL7_Python3 Between the work that is being done to migrate the platform layer in the Fedora/RHEL/CentOS ecosystem, the work by Brett Cannon and others to improve the tooling around lower risk Python 3 migrations, the inclusion of pip in Python 2.7 to improve the availability of migration tools and backported modules, and the return of printf-style binary interpolation support in Python 3.5, several of the concrete challenges that make migration harder than it needs to be are being addressed. Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Dec 13, 2014, at 12:29 AM, Donald Stufft wrote:
For what it’s worth, I almost exclusively write 2/3 compatible code (and that’s with the “easy” subset of 2.6+ and either 3.2+ or 3.3+) and doing so does make the language far less fun for me than when I was writing 2.x only code.
For myself, the way I'd put it is: With the libraries I maintain, I generally write Python 2/3 compatible code, targeting Python 2.7 and 3.4, with 2.6, 3.3, and 3.2 support as bonuses, although I will not contort too much to support those older versions. Doing so does make the language far less fun for me than when I am writing 3.x only code. All applications I write in pure Python 3, targeting Python 3.4, unless my dependencies are not all available in Python 3, or I haven't yet had the cycles/resources to port to Python 3. Writing and maintaining applications in Python 2 is far less fun than doing so in Python 3. Cheers, -Barry
This is also my approach, and the one that I'm encouraging throughout Microsoft as we start putting out more Python packages for stuff. Top-posted from my Windows Phone ________________________________ From: Barry Warsaw<mailto:barry@python.org> Sent: 12/13/2014 7:19 To: python-dev@python.org<mailto:python-dev@python.org> Subject: Re: [Python-Dev] Python 2.x and 3.x use survey, 2014 edition On Dec 13, 2014, at 12:29 AM, Donald Stufft wrote:
For what it’s worth, I almost exclusively write 2/3 compatible code (and that’s with the “easy” subset of 2.6+ and either 3.2+ or 3.3+) and doing so does make the language far less fun for me than when I was writing 2.x only code.
For myself, the way I'd put it is: With the libraries I maintain, I generally write Python 2/3 compatible code, targeting Python 2.7 and 3.4, with 2.6, 3.3, and 3.2 support as bonuses, although I will not contort too much to support those older versions. Doing so does make the language far less fun for me than when I am writing 3.x only code. All applications I write in pure Python 3, targeting Python 3.4, unless my dependencies are not all available in Python 3, or I haven't yet had the cycles/resources to port to Python 3. Writing and maintaining applications in Python 2 is far less fun than doing so in Python 3. Cheers, -Barry _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/steve.dower%40microsoft.c...
On Dec 13, 2014, at 10:17 AM, Barry Warsaw <barry@python.org> wrote:
On Dec 13, 2014, at 12:29 AM, Donald Stufft wrote:
For what it’s worth, I almost exclusively write 2/3 compatible code (and that’s with the “easy” subset of 2.6+ and either 3.2+ or 3.3+) and doing so does make the language far less fun for me than when I was writing 2.x only code.
For myself, the way I'd put it is:
With the libraries I maintain, I generally write Python 2/3 compatible code, targeting Python 2.7 and 3.4, with 2.6, 3.3, and 3.2 support as bonuses, although I will not contort too much to support those older versions. Doing so does make the language far less fun for me than when I am writing 3.x only code. All applications I write in pure Python 3, targeting Python 3.4, unless my dependencies are not all available in Python 3, or I haven't yet had the cycles/resources to port to Python 3. Writing and maintaining applications in Python 2 is far less fun than doing so in Python 3.
Yea that’s not unlike me in that. I don’t write many applications where I have a choice of runtime. Most of what I write tends to be libraries or applications for work where we’re using 2.7 or pip itself where if we dropped 2.7 or 2.6 support people would be after us with pitchforks. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
On Sat, 13 Dec 2014 10:17:59 -0500, Barry Warsaw <barry@python.org> wrote:
On Dec 13, 2014, at 12:29 AM, Donald Stufft wrote:
For what it’s worth, I almost exclusively write 2/3 compatible code (and that’s with the “easy” subset of 2.6+ and either 3.2+ or 3.3+) and doing so does make the language far less fun for me than when I was writing 2.x only code.
For myself, the way I'd put it is:
With the libraries I maintain, I generally write Python 2/3 compatible code, targeting Python 2.7 and 3.4, with 2.6, 3.3, and 3.2 support as bonuses, although I will not contort too much to support those older versions. Doing so does make the language far less fun for me than when I am writing 3.x only code. All applications I write in pure Python 3, targeting Python 3.4, unless my dependencies are not all available in Python 3, or I haven't yet had the cycles/resources to port to Python 3. Writing and maintaining applications in Python 2 is far less fun than doing so in Python 3.
I think this is an important distinction. The considerations are very different for library maintainers than they are for application maintainers. Most of my work is in (customer) applications, and except for one customer who insists on using an old version of RedHat, I've been on "latest" python3 for those for quite a while now. I suspect we hear less here from people in that situation than would be proportional to their absolute numbers. --David
OK, this seems weird to me: For what it’s worth, I almost exclusively write 2/3 compatible code (and
that’s with the “easy” subset of 2.6+ and either 3.2+ or 3.3+)
ouch.
However the way it "used" to work is that the newest version, with all the new features, would quickly become the dominant version within a year or two.
This seems completely contradictory to me: Yes, the 3.* transition can be difficult, thus the need to support 1.*. But if you are still supporting 2.6, then clearly "the newest version, with all the new features, would quickly become the dominant version within a year or two" But there are those use cases that seem to require sticking with old version for ages, even if there have not been substantial incomparable changes. So we could be on version 2.12 now, and you'd still need to support 2.6, and still be working in a legacy, least common denominator language. How does this have anything to do with the 3.* transition? But plenty of us are kind of stuck on 2.7 at this point -- we can upgrade, but can't accommodate a major shift (for me it's currently wxPython that's the blocker -- that may be the only one. Others are either supported or small enough that we could handle the port ourselves.) But anyway, if you don't hate 2.6 back in the day, why hate it now? (yet, I know Donald didn't use the "hate" word). I guess my pint is that you either would much prefer to be working with the latest and greatest cool features or not -- but if you do the problem at this point isn't anything about py3, it's about the fact that many of us are required to support old versions, period. -Chris However I can't really justify for most situations supporting _only_ those
things because even today they are not the dominant version (or really close to it in any number I have access too). This means that if I want to take advantage of something newer I'm essentially dropping the largest part of the ecosystem.
Are you primarily writing packages for others to use? if so, then yes. But I wonder how many people are in that camp? Don't most of us spend most of our time writing our own purpose-built code? That might be a nice thing to see in a survey, actually. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
On Dec 15, 2014, at 2:30 PM, Chris Barker <chris.barker@noaa.gov> wrote:
OK, this seems weird to me:
For what it’s worth, I almost exclusively write 2/3 compatible code (and that’s with the “easy” subset of 2.6+ and either 3.2+ or 3.3+)
ouch.
However the way it "used" to work is that the newest version, with all the new features, would quickly become the dominant version within a year or two.
This seems completely contradictory to me: Yes, the 3.* transition can be difficult, thus the need to support 1.*. But if you are still supporting 2.6, then clearly "the newest version, with all the new features, would quickly become the dominant version within a year or two"
But there are those use cases that seem to require sticking with old version for ages, even if there have not been substantial incomparable changes.
So we could be on version 2.12 now, and you'd still need to support 2.6, and still be working in a legacy, least common denominator language. How does this have anything to do with the 3.* transition?
Most of my libraries probably wouldn’t be 2.6+ if there was something after 2.7. Other than pip itself I mostly only support 2.6 because it’s easy to do compared to 2.7 and there’s nothing in 2.7 that really makes me care to drop it in most situations. Realistically that’s what every decision to drop a version for a library ends up being, look at guesstimate numbers for the old version, and decide if that segment of the user base is worth either the pain of supporting back that far or missing out on the newer features. For 2.7 over 2.6 that answer for me is primarily no it’s not (though 2.7.9 might make me start dropping support for older versions once it’s widely deployed).
But plenty of us are kind of stuck on 2.7 at this point -- we can upgrade, but can't accommodate a major shift (for me it's currently wxPython that's the blocker -- that may be the only one. Others are either supported or small enough that we could handle the port ourselves.)
But anyway, if you don't hate 2.6 back in the day, why hate it now?
The answer is generally that developers are human beings and like new things, so while 2.6 might have been great back in the day, it’s not back in the day anymore and they are tired of it.
(yet, I know Donald didn't use the "hate" word).
I guess my pint is that you either would much prefer to be working with the latest and greatest cool features or not -- but if you do the problem at this point isn't anything about py3, it's about the fact that many of us are required to support old versions, period.
Right, It’s not _exactly_ about Python 3, but that Python 3.0 made it so that an old version is by far the dominant version which puts people who have outside users in a situation where they have to decide between new-and-shiny but hurting the bulk of their users and old-and-busted and being friendly to the bulk of their users.
-Chris
However I can't really justify for most situations supporting _only_ those things because even today they are not the dominant version (or really close to it in any number I have access too). This means that if I want to take advantage of something newer I'm essentially dropping the largest part of the ecosystem.
Are you primarily writing packages for others to use? if so, then yes. But I wonder how many people are in that camp? Don't most of us spend most of our time writing our own purpose-built code?
Yes I am.
That might be a nice thing to see in a survey, actually.
-Chris
--
Christopher Barker, Ph.D. Oceanographer
Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker@noaa.gov <mailto:Chris.Barker@noaa.gov>
--- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
On Mon, Dec 15, 2014 at 11:30 AM, Chris Barker <chris.barker@noaa.gov> wrote:
Are you primarily writing packages for others to use? if so, then yes. But I wonder how many people are in that camp? Don't most of us spend most of our time writing our own purpose-built code?
That might be a nice thing to see in a survey, actually.
So, I'm the guy that used the "hate" word in relation to writing 2/3 compliant code. And really, as a library maintainer/writer I do hate writing 2/3 compatible code. Having 4 future imports in every file and being forced to use a compatibility shim to do something as simple as iterating across a dictionary is somewhere between sad and infuriating - and that's just the beginning of the madness. From there we get into identifier related problems with their own compatibility shims - like str(), unicode(), bytes(), int(), and long(). Writing 2/3 compatible Python feels more like torture than fun. Even the python-future.org FAQ mentions how un-fun writing 2/3 compatible Python is. The whole situation is made worse because I *KNOW* that Python 3 is a better language than Python 2, but that it doesn't *MATTER* because Python 2 is what people are - and will be - using for the foreseeable future. It's impractical to drop library support for Python 2 when all of your users use Python 2, and bringing the topic up yields a response that amounts to: "WELL, Python 3 is the future! It has been out for SEVEN YEARS! You know Python 2 won't be updated ever again! Almost every library has been updated to Python 3 and you're just behind the times! And, you'll have to switch EVENTUALLY anyway! If you'd just stop writing Python 2 libraries and focus on pure Python 3 then you wouldn't have to write legacy code! PEOPLE LIKE YOU are why the split is going to be there until at least 2020!". And then my head explodes from the hostility of the "core Python community". Perhaps no individual response is quite so blunt, but the community (taken as a whole) feels outright toxic on this topic to me. Consider some statistics from Pypi: - 13359 Python 2.7 packages - 7140 Python 3.x packages - 2732 Python 3.4 packages - 4024 Python 2.7/3.x compatible packages - 2281 2.7/3.4 compatible modules - 9335 Python 2.7 without ANY Python 3 support - 11078 Python 2.7 without Python 3.4 support - 451 modules 3.4 only packages - 3116 Python 3.x only packages - 1004 Python 3.x modules without (tagged) Python 3.4 support Looking at the numbers, I just cannot fathom how we as a community can react this way. The top 50 projects (!!) still prevent a lot of people from switching to Python 3, but the long tail of library likely an even bigger blocker. I also don't understand how we can claim people should start ALL new projects in Python 3 - and be indignant when they don't!. We haven't successfully converted the top 50 projects after SEVEN YEARS, and the long tail without 3.x support is still getting longer. Claims that we have something approaching library parity seem... hilarious, at best? I suppose what I'm saying is that there's lots of claims that the conversion to Python 3 is inevitable, but I'm not convinced about that. I'd posit that another outcome is the slow death of Python as a language. I would suggest adding some "community health" metrics around the Python 2/3 split, as well as a question about whether someone considers themselves primarily a library author, application developer, or both. I'd also ask how many people have started a new application in another language instead of Python 3 because of the split. -Mark
Mark Roberts <wizzat@gmail.com> writes:
So, I'm the guy that used the "hate" word in relation to writing 2/3 compliant code. And really, as a library maintainer/writer I do hate writing 2/3 compatible code.
You're unlikely to get disagreement on that. I certainly concur. The catch is, at the moment it's better that any of the alternatives for writing medium-to-long-term maintainable Python code.
The whole situation is made worse because I *KNOW* that Python 3 is a better language than Python 2, but that it doesn't *MATTER* because Python 2 is what people are - and will be - using for the foreseeable future.
Only if “people” means “any amount of people at all who are or might be using Python”. While developers might like something that allows them to serve such a broad user base indefinitely, it's simply not realistic – and *no* feasible support strategy for Python could allow that. So, as developers writing Python code, we must set our expectations for support base according to reality rather than wishing it were otherwise.
It's impractical to drop library support for Python 2 when all of your users use Python 2
Right. The practical thing to do is to decide explicitly, per project, what portion of those users you can afford to leave behind in Python-2-only land, and how much cost you're willing to bear to keep than number low.
I suppose what I'm saying is that there's lots of claims that the conversion to Python 3 is inevitable, but I'm not convinced about that.
I've never seen such a claim from the PSF. Can you cite any, and are they representative of the PSF's position on the issue? Rather, the claim is that *if* one's code base doesn't migrate to Python 3, it will be decreasingly supported by the PSF and the Python community at large. Happily, what's also true is there is a huge amount of support – in language features, tools, and community will – to help developers do that migration. Much more than most other migrations I've observed. So what's inevitable is: either a code base will benefit from all that support and be migrated to Python 3 and hence be maintainable as the Python ecosystem evolves; or it will be increasingly an outsider of that ecosystem. -- \ “I have one rule to live by: Don't make it worse.” —Hazel | `\ Woodcock | _o__) | Ben Finney
Ben Finney <ben+python <at> benfinney.id.au> writes:
Rather, the claim is that *if* one's code base doesn't migrate to Python 3, it will be decreasingly supported by the PSF and the Python community at large.
The PSF doesn't support any versions of Python. We have effectively no involvement in the development of Python the language, or CPython. We certainly don't care what version of Python you use. Members of the python-dev list, or the CPython core development teams have opinions probably, but that doesn't make them the opinion of the PSF. Alex
Alex Gaynor <alex.gaynor@gmail.com> writes:
Ben Finney <ben+python <at> benfinney.id.au> writes:
Rather, the claim is that *if* one's code base doesn't migrate to Python 3, it will be decreasingly supported by the PSF and the Python community at large.
The PSF doesn't support any versions of Python. We have effectively no involvement in the development of Python the language, or CPython. We certainly don't care what version of Python you use.
Okay, I was under the impression that the entity blessing Python releases as “official” is the PSF. What is that entity, then? Whatever entity is the one which makes “this is an official release of Python the language”, and “support for Python version A.B will end on YYYY-MM-DD”, that's the entity I meant. -- \ “I went to the museum where they had all the heads and arms | `\ from the statues that are in all the other museums.” —Steven | _o__) Wright | Ben Finney
On 16 December 2014 at 16:03, Ben Finney <ben+python@benfinney.id.au> wrote:
Alex Gaynor <alex.gaynor@gmail.com> writes:
Ben Finney <ben+python <at> benfinney.id.au> writes:
Rather, the claim is that *if* one's code base doesn't migrate to Python 3, it will be decreasingly supported by the PSF and the Python community at large.
The PSF doesn't support any versions of Python. We have effectively no involvement in the development of Python the language, or CPython. We certainly don't care what version of Python you use.
Okay, I was under the impression that the entity blessing Python releases as “official” is the PSF. What is that entity, then?
The PSF controls the trademark, but its the comparatively informal collective known as python-dev (ultimately helmed by Guido) that makes the technical decisions. To the degree with which the latter body is formally defined by anything, it's defined by PEP 1.
Whatever entity is the one which makes “this is an official release of Python the language”, and “support for Python version A.B will end on YYYY-MM-DD”, that's the entity I meant.
That would be the release managers for the respective CPython releases (in collaboration with the rest of python-dev). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On 16 December 2014 at 13:08, Mark Roberts <wizzat@gmail.com> wrote:
The whole situation is made worse because I *KNOW* that Python 3 is a better language than Python 2, but that it doesn't *MATTER* because Python 2 is what people are - and will be - using for the foreseeable future. It's impractical to drop library support for Python 2 when all of your users use Python 2, and bringing the topic up yields a response that amounts to: "WELL, Python 3 is the future! It has been out for SEVEN YEARS! You know Python 2 won't be updated ever again! Almost every library has been updated to Python 3 and you're just behind the times! And, you'll have to switch EVENTUALLY anyway! If you'd just stop writing Python 2 libraries and focus on pure Python 3 then you wouldn't have to write legacy code! PEOPLE LIKE YOU are why the split is going to be there until at least 2020!". And then my head explodes from the hostility of the "core Python community". Perhaps no individual response is quite so blunt, but the community (taken as a whole) feels outright toxic on this topic to me.
The core Python development community are the ones ensuring that folks feel comfortable continuing to run Python 2 (by promising upstream support out to 2020 and adjusting our maintenance release policies to account for the practical realities of long term support), as well as working with redistributors and tool developers to reduce the practical barriers to migration from Python 2 to Python 3 (such as bundling pip with Python 2.7.9, or Brett's recent work on updating the porting guide). It's the folks just *outside* the language core development community that legitimately feel the most hard done by, as they didn't choose this path - we did. Folks working on libraries and frameworks likely won't see any direct benefit from the migration for years - given the timelines of previous version transitions within the Python 2 series, we likely won't see projects widely dropping Python 2 support until after there are versions of RHEL & CentOS available where the default system Python is Python 3. In the meantime, they're stuck with working in a hybrid language that only benefits from the subset of improvements in each new Python 3 release that increase the size of the source compatible Python 2/3 subset. Living with carrier grade operating system update cycles when you're used to upgrading your baseline target Python version every couple of years is genuinely frustrating as a developer. Unfortunately, the anger that library and framework authors should really be directing at us, and at the commercial Linux distros offering long term support for older versions of Python, occasionally spills over into frustration at the *end users* that benefit from those long term support offerings. Explanations of the overarching industry patterns influencing the migration (like http://developerblog.redhat.com/2014/09/09/transition-to-multilingual-progra...) are cold comfort when you're one of the ones actually doing the work of supporting two parallel variants of the language. Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Mon, 15 Dec 2014 19:08:17 -0800 Mark Roberts <wizzat@gmail.com> wrote:
So, I'm the guy that used the "hate" word in relation to writing 2/3 compliant code. And really, as a library maintainer/writer I do hate writing 2/3 compatible code. Having 4 future imports in every file and being forced to use a compatibility shim to do something as simple as iterating across a dictionary is somewhere between sad and infuriating - and that's just the beginning of the madness.
Iterating accross a dictionary doesn't need compatibility shims. It's dead simple in all Python versions: $ python2 Python 2.7.8 (default, Oct 20 2014, 15:05:19) [GCC 4.9.1] on linux2 Type "help", "copyright", "credits" or "license" for more information.
d = {'a': 1} for k in d: print(k) ... a
$ python3 Python 3.4.2 (default, Oct 8 2014, 13:08:17) [GCC 4.9.1] on linux Type "help", "copyright", "credits" or "license" for more information.
d = {'a': 1} for k in d: print(k) ... a
Besides, using iteritems() and friends is generally a premature optimization, unless you know you'll have very large containers. Creating a list is cheap.
From there we get into identifier related problems with their own compatibility shims - like str(), unicode(), bytes(), int(), and long(). Writing 2/3 compatible Python feels more like torture than fun.
It depends what kind of purpose your code is written for, or how you write it. Unless you have a lot of network-facing code, writing 2/3 compatible code should actually be quite pedestrian. Regards Antoine.
On Tue, Dec 16, 2014 at 2:45 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:
Iterating accross a dictionary doesn't need compatibility shims. It's dead simple in all Python versions:
$ python2 Python 2.7.8 (default, Oct 20 2014, 15:05:19) [GCC 4.9.1] on linux2 Type "help", "copyright", "credits" or "license" for more information.
d = {'a': 1} for k in d: print(k) ... a
$ python3 Python 3.4.2 (default, Oct 8 2014, 13:08:17) [GCC 4.9.1] on linux Type "help", "copyright", "credits" or "license" for more information.
d = {'a': 1} for k in d: print(k) ... a
Besides, using iteritems() and friends is generally a premature optimization, unless you know you'll have very large containers. Creating a list is cheap.
It seems to me that every time I hear this, the author is basically admitting that Python is a toy language not meant for "serious computing" (where serious is defined in extremely modest terms). The advice is also very contradictory to literally every talk on performant Python that I've seen at PyCon or PyData or ... well, anywhere. And really, doesn't it strike you as incredibly presumptuous to call the *DEFAULT BEHAVIOR* of Python 3 a "premature optimization"? Isn't the whole reason that the default behavior switch was made is because creating lists willy nilly all over the place really *ISN'T* cheap? This isn't the first time someone has tried to run this line past me, but it's the first time I've been fed up enough with the topic to call it complete BS on the spot. Please help me stop the community at large from saying this, because it really isn't true at all. -Mark
Mark, your tone is no longer constructive and is hurting your case in arguing for anything. Please take it down a notch. On Tue Dec 16 2014 at 1:48:59 PM Mark Roberts <wizzat@gmail.com> wrote:
On Tue, Dec 16, 2014 at 2:45 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:
Iterating accross a dictionary doesn't need compatibility shims. It's dead simple in all Python versions:
$ python2 Python 2.7.8 (default, Oct 20 2014, 15:05:19) [GCC 4.9.1] on linux2 Type "help", "copyright", "credits" or "license" for more information.
d = {'a': 1} for k in d: print(k) ... a
$ python3 Python 3.4.2 (default, Oct 8 2014, 13:08:17) [GCC 4.9.1] on linux Type "help", "copyright", "credits" or "license" for more information.
d = {'a': 1} for k in d: print(k) ... a
Besides, using iteritems() and friends is generally a premature optimization, unless you know you'll have very large containers. Creating a list is cheap.
It seems to me that every time I hear this, the author is basically admitting that Python is a toy language not meant for "serious computing" (where serious is defined in extremely modest terms). The advice is also very contradictory to literally every talk on performant Python that I've seen at PyCon or PyData or ... well, anywhere. And really, doesn't it strike you as incredibly presumptuous to call the *DEFAULT BEHAVIOR* of Python 3 a "premature optimization"? Isn't the whole reason that the default behavior switch was made is because creating lists willy nilly all over the place really *ISN'T* cheap? This isn't the first time someone has tried to run this line past me, but it's the first time I've been fed up enough with the topic to call it complete BS on the spot. Please help me stop the community at large from saying this, because it really isn't true at all.
-Mark _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/ brett%40python.org
Perhaps you are correct, and I will attempt to remain more constructive on the topic (despite it being an *incredibly* frustrating experience). However, my point remains: this is a patently false thing that is being parroted throughout the Python community, and it's outright insulting to be told my complaints about writing 2/3 compatible code are invalid on the basis of "premature optimization". -Mark On Tue, Dec 16, 2014 at 10:57 AM, Brett Cannon <brett@python.org> wrote:
Mark, your tone is no longer constructive and is hurting your case in arguing for anything. Please take it down a notch.
On Tue Dec 16 2014 at 1:48:59 PM Mark Roberts <wizzat@gmail.com> wrote:
On Tue, Dec 16, 2014 at 2:45 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:
Iterating accross a dictionary doesn't need compatibility shims. It's dead simple in all Python versions:
$ python2 Python 2.7.8 (default, Oct 20 2014, 15:05:19) [GCC 4.9.1] on linux2 Type "help", "copyright", "credits" or "license" for more information.
d = {'a': 1} for k in d: print(k) ... a
$ python3 Python 3.4.2 (default, Oct 8 2014, 13:08:17) [GCC 4.9.1] on linux Type "help", "copyright", "credits" or "license" for more information.
d = {'a': 1} for k in d: print(k) ... a
Besides, using iteritems() and friends is generally a premature optimization, unless you know you'll have very large containers. Creating a list is cheap.
It seems to me that every time I hear this, the author is basically admitting that Python is a toy language not meant for "serious computing" (where serious is defined in extremely modest terms). The advice is also very contradictory to literally every talk on performant Python that I've seen at PyCon or PyData or ... well, anywhere. And really, doesn't it strike you as incredibly presumptuous to call the *DEFAULT BEHAVIOR* of Python 3 a "premature optimization"? Isn't the whole reason that the default behavior switch was made is because creating lists willy nilly all over the place really *ISN'T* cheap? This isn't the first time someone has tried to run this line past me, but it's the first time I've been fed up enough with the topic to call it complete BS on the spot. Please help me stop the community at large from saying this, because it really isn't true at all.
-Mark _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/ brett%40python.org
On Tue Dec 16 2014 at 2:05:28 PM Mark Roberts <wizzat@gmail.com> wrote:
Perhaps you are correct, and I will attempt to remain more constructive on the topic (despite it being an *incredibly* frustrating experience). However, my point remains: this is a patently false thing that is being parroted throughout the Python community, and it's outright insulting to be told my complaints about writing 2/3 compatible code are invalid on the basis of "premature optimization".
See, you're still using a very negative tone even after saying you would try to scale it back. What Antoine said is not patently false and all he said was that relying on iter*() methods on dicts is typically a premature optimization for Python 2 code which is totally reasonable for him to say and was done so in a calm tone. He didn't say "you are prematurely optimizing and you need to stop telling the community that because you're wasting everyone's time in caring about performance!" which how I would expect you to state it if you were make the same claim based on how you have been reacting. For most use cases, you simply don't need a memory-efficient iterator. If you have a large dict where memory issues from constructing a list comes into play, then yes you should use iterkeys(), but otherwise the overhead of temporarily constructing a list to hold all the keys is cheap since it's just a list of pointers at the C level. As for the changing of the default in Python 3, that's because we decided to make iterators the default everywhere. And that was mostly for consistency, not performance reasons. It was also for flexibility as you can go from an iterator to a list by just wrapping the iterator in list(), but you can't go the other way around. At no time did anyone go "we really need to change the default iterator for dicts to a memory-saving iterator because people are wasting memory and having issues with memory pressure all the time"; it was always about consistency and using the best idiom that had developed over the years. So Antoine's point is entirely reasonable and valid and right. -Brett
-Mark
On Tue, Dec 16, 2014 at 10:57 AM, Brett Cannon <brett@python.org> wrote:
Mark, your tone is no longer constructive and is hurting your case in arguing for anything. Please take it down a notch.
On Tue Dec 16 2014 at 1:48:59 PM Mark Roberts <wizzat@gmail.com> wrote:
On Tue, Dec 16, 2014 at 2:45 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:
Iterating accross a dictionary doesn't need compatibility shims. It's dead simple in all Python versions:
$ python2 Python 2.7.8 (default, Oct 20 2014, 15:05:19) [GCC 4.9.1] on linux2 Type "help", "copyright", "credits" or "license" for more information.
> d = {'a': 1} > for k in d: print(k) ... a
$ python3 Python 3.4.2 (default, Oct 8 2014, 13:08:17) [GCC 4.9.1] on linux Type "help", "copyright", "credits" or "license" for more information.
> d = {'a': 1} > for k in d: print(k) ... a
Besides, using iteritems() and friends is generally a premature optimization, unless you know you'll have very large containers. Creating a list is cheap.
It seems to me that every time I hear this, the author is basically admitting that Python is a toy language not meant for "serious computing" (where serious is defined in extremely modest terms). The advice is also very contradictory to literally every talk on performant Python that I've seen at PyCon or PyData or ... well, anywhere. And really, doesn't it strike you as incredibly presumptuous to call the *DEFAULT BEHAVIOR* of Python 3 a "premature optimization"? Isn't the whole reason that the default behavior switch was made is because creating lists willy nilly all over the place really *ISN'T* cheap? This isn't the first time someone has tried to run this line past me, but it's the first time I've been fed up enough with the topic to call it complete BS on the spot. Please help me stop the community at large from saying this, because it really isn't true at all.
-Mark _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/ brett%40python.org
On Tue, 16 Dec 2014 19:25:35 +0000 Brett Cannon <brett@python.org> wrote:
As for the changing of the default in Python 3, that's because we decided to make iterators the default everywhere. And that was mostly for consistency, not performance reasons. It was also for flexibility as you can go from an iterator to a list by just wrapping the iterator in list(), but you can't go the other way around.
And two other reasons: - the API becomes simpler to use as there's no need to choose between .items() and .iteritems(), etc. - the 3.x methods don't return iterators but views, which have set-like features in addition to basic iterating Regards Antoine.
On 12/16/2014 11:25 AM, Brett Cannon wrote:
What Antoine said is not patently false [...]
What Antoine said was:
Unless you have a lot of network-facing code, writing 2/3 compatible code should actually be quite pedestrian.
Or, to paraphrase slightly, "if you aren't writing network code, and your 2/3 code is painful, you must be doing something wrong!" That may not be what he intended, but that is certainly how it felt. -- ~Ethan~
Mark Roberts <wizzat@gmail.com>:
it's outright insulting to be told my complaints about writing 2/3 compatible code are invalid on the basis of "premature optimization".
IMO, you should consider forking your library code for Python2 and Python3. The multidialect code will look unidiomatic for each dialect. When the critical mass favors Python3 (possibly within a couple of years), the transition will be as total and quick as from VHS to DVDs. At that point, a multidialect library would seem quaint, while a separate Python2 fork can simply be left behind (bug fixes only). Marko
On Tue, Dec 16, 2014 at 1:58 PM, Marko Rauhamaa <marko@pacujo.net> wrote:
IMO, you should consider forking your library code for Python2 and Python3.
I don't get the idea that Brett Cannon agrees with you: http://nothingbutsnark.svbtle.com/commentary-on-getting-your-code-to-run-on-... While he doesn't explicitly say so, I got the distinct impression reading his recent blog post that he supports one source, not forked sources. In the absence to evidence to the contrary, I think of Brett as the most expert developer in the porting space. Skip
On Dec 16, 2014, at 02:15 PM, Skip Montanaro wrote:
While he doesn't explicitly say so, I got the distinct impression reading his recent blog post that he supports one source, not forked sources.
I've ported a fair bit of code, both pure-Python and C extensions, both libraries and applications. For successful library ports to Python 3 that need to remain Python 2 compatible, I would almost always recommend a single source, common dialect, no-2to3 approach. There may be exceptions, but this strategy has proven effective over and over. I generally find I don't need `six` but it does provide some nice conveniences that can be helpful. With something like tox running your test suite, it doesn't even have to be painful to maintain. Cheers, -Barry
On 12/16/2014 03:09 AM, Barry Warsaw wrote:
On Dec 16, 2014, at 02:15 PM, Skip Montanaro wrote:
While he doesn't explicitly say so, I got the distinct impression reading his recent blog post that he supports one source, not forked sources.
I've ported a fair bit of code, both pure-Python and C extensions, both libraries and applications. For successful library ports to Python 3 that need to remain Python 2 compatible, I would almost always recommend a single source, common dialect, no-2to3 approach. There may be exceptions, but this strategy has proven effective over and over. I generally find I don't need `six` but it does provide some nice conveniences that can be helpful. With something like tox running your test suite, it doesn't even have to be painful to maintain.
I'll agree; with tox and some automated CI system like travis or jenkins or whatever, once you've done the port, it's only a minor nuisance to maintain a straddled 2/3 codebase. Programming in only the subset still isn't much fun, but maintenance is slightly easier than I expected it to be. "Drive by" contributions become slightly harder to accept because they often break 3 compatibility, and contributors are often unable or unwilling to install all the required versions that are tested by tox. - C
On 17 December 2014 at 10:45, Chris McDonough <chrism@plope.com> wrote:
On 12/16/2014 03:09 AM, Barry Warsaw wrote:
On Dec 16, 2014, at 02:15 PM, Skip Montanaro wrote:
While he doesn't explicitly say so, I got the distinct impression reading his recent blog post that he supports one source, not forked sources.
I've ported a fair bit of code, both pure-Python and C extensions, both libraries and applications. For successful library ports to Python 3 that need to remain Python 2 compatible, I would almost always recommend a single source, common dialect, no-2to3 approach. There may be exceptions, but this strategy has proven effective over and over. I generally find I don't need `six` but it does provide some nice conveniences that can be helpful. With something like tox running your test suite, it doesn't even have to be painful to maintain.
I'll agree; with tox and some automated CI system like travis or jenkins or whatever, once you've done the port, it's only a minor nuisance to maintain a straddled 2/3 codebase. Programming in only the subset still isn't much fun, but maintenance is slightly easier than I expected it to be. "Drive by" contributions become slightly harder to accept because they often break 3 compatibility, and contributors are often unable or unwilling to install all the required versions that are tested by tox.
It's worth noting that the last problem can potentially be mitigated to some degree by taking advantage of the new "pylint --py3k" feature making it easier to check that code is 2/3 source compatible without needing a local copy of Python 3 to test against, and without needing to adhere to pylint's other checks. As far as Marko's suggestion of maintaining two code bases go, that's what we do for the standard library, and we've *never* advised anyone else to do the same. Even before experience showed the source compatible approach was more practical, the original advice to third party developers was to use 2to3 to automatically derive the Python 3 version from the Python 2 version and address any compatibility issues by modifying the Python 2 sources. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Tue, Dec 16, 2014 at 2:15 PM, Skip Montanaro <skip.montanaro@gmail.com> wrote:
On Tue, Dec 16, 2014 at 1:58 PM, Marko Rauhamaa <marko@pacujo.net> wrote:
IMO, you should consider forking your library code for Python2 and Python3.
I don't get the idea that Brett Cannon agrees with you:
http://nothingbutsnark.svbtle.com/commentary-on-getting-your-code-to-run-on-...
While he doesn't explicitly say so, I got the distinct impression reading his recent blog post that he supports one source, not forked sources.
In the absence to evidence to the contrary, I think of Brett as the most expert developer in the porting space.
I'm a few inches shorter than Brett, but having done several sizable ports, dual-source has never even on the table. I would prefer the "run 2to3 at installation time" option before maintaining two versions (which I do not prefer at all in reality).
Brian Curtin <brian@python.org>:
I'm a few inches shorter than Brett, but having done several sizable ports, dual-source has never even on the table. I would prefer the "run 2to3 at installation time" option before maintaining two versions (which I do not prefer at all in reality).
How about "run 3to2 at installation time?" Marko
On 12/16/2014 12:31 PM, Brian Curtin wrote:
On Tue, Dec 16, 2014 at 2:15 PM, Skip Montanaro wrote:
On Tue, Dec 16, 2014 at 1:58 PM, Marko Rauhamaa wrote:
IMO, you should consider forking your library code for Python2 and Python3.
I don't get the idea that Brett Cannon agrees with you:
http://nothingbutsnark.svbtle.com/commentary-on-getting-your-code-to-run-on-...
While he doesn't explicitly say so, I got the distinct impression reading his recent blog post that he supports one source, not forked sources.
In the absence to evidence to the contrary, I think of Brett as the most expert developer in the porting space.
I'm a few inches shorter than Brett, but having done several sizable ports, dual-source has never even on the table. I would prefer the "run 2to3 at installation time" option before maintaining two versions (which I do not prefer at all in reality).
I have a handful of projects. The tiny ones are one-source, the biggest one (dbf) is not. If I had an entire application I would probably split the difference, and just have dual source on a single module to hold the classes/functions that absolutely-had-to-have-this-or-that-feature (exec (the statement) vs exec (the function) comes to mind). -- ~Ethan~
This thread hasn't been productive for a really long time now. On Tue, Dec 16, 2014 at 1:52 PM, Ethan Furman <ethan@stoneleaf.us> wrote:
On 12/16/2014 12:31 PM, Brian Curtin wrote:
On Tue, Dec 16, 2014 at 2:15 PM, Skip Montanaro wrote:
On Tue, Dec 16, 2014 at 1:58 PM, Marko Rauhamaa wrote:
IMO, you should consider forking your library code for Python2 and Python3.
I don't get the idea that Brett Cannon agrees with you:
http://nothingbutsnark.svbtle.com/commentary-on-getting-your-code-to-run-on-...
While he doesn't explicitly say so, I got the distinct impression
reading
his recent blog post that he supports one source, not forked sources.
In the absence to evidence to the contrary, I think of Brett as the most expert developer in the porting space.
I'm a few inches shorter than Brett, but having done several sizable ports, dual-source has never even on the table. I would prefer the "run 2to3 at installation time" option before maintaining two versions (which I do not prefer at all in reality).
I have a handful of projects. The tiny ones are one-source, the biggest one (dbf) is not.
If I had an entire application I would probably split the difference, and just have dual source on a single module to hold the classes/functions that absolutely-had-to-have-this-or-that-feature (exec (the statement) vs exec (the function) comes to mind).
-- ~Ethan~
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%40python.org
-- --Guido van Rossum (python.org/~guido)
On Wed, Dec 17, 2014 at 12:56 AM, Guido van Rossum <guido@python.org> wrote:
This thread hasn't been productive for a really long time now.
I agree. The constructive way would be to concentrate on looking for causes. I don't know if there is a discipline of "programming language usability" in computer science, but now is a good moment to apply it.
On Tue, 16 Dec 2014 10:48:07 -0800, Mark Roberts <wizzat@gmail.com> wrote:
On Tue, Dec 16, 2014 at 2:45 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:
Iterating accross a dictionary doesn't need compatibility shims. It's dead simple in all Python versions:
$ python2 Python 2.7.8 (default, Oct 20 2014, 15:05:19) [GCC 4.9.1] on linux2 Type "help", "copyright", "credits" or "license" for more information.
d = {'a': 1} for k in d: print(k) ... a
$ python3 Python 3.4.2 (default, Oct 8 2014, 13:08:17) [GCC 4.9.1] on linux Type "help", "copyright", "credits" or "license" for more information.
d = {'a': 1} for k in d: print(k) ... a
Besides, using iteritems() and friends is generally a premature optimization, unless you know you'll have very large containers. Creating a list is cheap.
It seems to me that every time I hear this, the author is basically admitting that Python is a toy language not meant for "serious computing" (where serious is defined in extremely modest terms). The advice is also very contradictory to literally every talk on performant Python that I've seen at PyCon or PyData or ... well, anywhere. And really, doesn't it strike you as incredibly presumptuous to call the *DEFAULT BEHAVIOR* of Python 3 a "premature optimization"?
No. A premature optimization is one that is made before doing any performance analysis, so language features are irrelevant to that labeling. This doesn't mean you shouldn't use "better" idioms when they are clear. But if you are complicating your code because of performance concerns *without measuring it* you are doing premature optimization, by definition[*].
Isn't the whole reason that the default behavior switch was made is because creating lists willy nilly all over the place really *ISN'T* cheap? This isn't the first time someone has
No. In Python3 we made the iterator protocol more central to the language. Any performance benefit is actually a side effect of that change. One that was considered, yes, but in the context of the *language* as a whole and not any individual program's performance profile. And "this doesn't make things worse for real world programs as far as we can measure" is a more important criterion for this kind of language change than "lets do this because we've measured and it makes things better". --David [*] And yes, *we all do this*. Sometimes doing it doesn't cost much. Sometimes it does.
On 12/16/2014 08:18 PM, R. David Murray wrote:
Besides, using iteritems() and friends is generally a premature optimization, unless you know you'll have very large containers. Creating a list is cheap. [...] No. A premature optimization is one that is made before doing any
On Tue, 16 Dec 2014 10:48:07 -0800, Mark Roberts <wizzat@gmail.com> wrote: performance analysis, so language features are irrelevant to that labeling. This doesn't mean you shouldn't use "better" idioms when they are clear.
This is a relevant point. I would make it even stronger: using iteritems() is not a premature optimization, it is a statement of intent. More importantly, using items() in iteration is a statement of expectation that the dict will change during iteration. If this is not in fact the case, then items() is the wrong idiom for reasons of readability, not (just) efficiency.
2014-12-11 15:47 GMT+01:00 Giampaolo Rodola' <g.rodola@gmail.com>:
I still think the only *real* obstacle remains the lack of important packages such as twisted, gevent and pika which haven't been ported yet.
twisted core works on python 3, right now. Contribute to Twisted if you want to port more code... Or start something new, asyncio (with trollius, it works on Python 2 too). The develpoment branch of gevent supports Python 3, especially if you dont use monkey patching. Ask the developers to release a version, at least with "experimental" Python 3 support. I don't know pika. I read "Pika Python AMQP Client Library". You may take a look at https://github.com/dzen/aioamqp if you would like to play with asyncio.
With those ones ported switching to Python 3 *right now* is not only possible and relatively easy, but also convenient.
Victor
On 2014-12-11, 14:47 GMT, Giampaolo Rodola' wrote:
I still think the only *real* obstacle remains the lack of important packages such as twisted, gevent and pika which haven't been ported yet.
And unwise decisions of some vendors (like, unfortunately my belvoed employer with RHEL-7) not to ship python3. Oh well. Matěj
participants (30)
-
Alex Gaynor -
anatoly techtonik -
Antoine Pitrou -
Barry Warsaw -
Ben Finney -
Brett Cannon -
Brian Curtin -
Bruno Cauet -
Chris Angelico -
Chris Barker -
Chris McDonough -
Dan Stromberg -
Donald Stufft -
Ethan Furman -
Giampaolo Rodola' -
Guido van Rossum -
Hrvoje Niksic -
Ian Cordasco -
Mark Roberts -
Marko Rauhamaa -
Matěj Cepl -
Nathaniel Smith -
Nick Coghlan -
Petr Viktorin -
R. David Murray -
Skip Montanaro -
Steve Dower -
Steven D'Aprano -
Terry Reedy -
Victor Stinner