4 ms·

Which statistics? I'm honestly curious. I presume you've read http://blog.startifact.com/posts/python-2-gravity.html http://blog.startifact.com/posts/python-2-

Which statistics? I'm honestly curious. I presume you've read http://blog.startifact.com/posts/python-2-gravity.html http://blog.startifact.com/posts/python-2-gravity.html? All the new python3/python2 libraries I've noticed adhoc recently have been doing the horrible 'polyglot' one-code-base-support-python2-and-python3 thing, or been in python2.

jofer 13y ago
What's horrible about the "polyglot" approach? Beyond not getting to take full advantage of python3, it's really a relatively painless solution (though when you hit the pain points (bytes vs strings vs unicode) you'll notice).
- shadowmint 13y ago
  There's nothing particularly wrong with it (honestly polyglot should have been python 3.1, with new features at they rolled to 3.2, 3.3, etc. in my opinion); but if the reason for using python 3 is that it has shiny new features (like async io), it's a bit of bummer because you can't use them if your library is py2 compatible. ...which kind of makes it 'python 3 but actually python 2 running on the python 3 runtime', and the code is harder to maintain than either python 2 or python 3 (twice as much testing to do too). Not really much of a carrot for library developers to support python 3.
  - jofer 13y ago
    Very true. It's still better than the option of maintaining two separate codebases, i.m.o., though.
  - zzzeek 13y ago
    what kind of library could transparently use async IO, or not, based on platform? using explicit async for anything dramatically changes the behavior and public API of the code. there is of course a huge carrot for library developers to support python 3 which is, so that python 3 users can use your library, rather than having all of your work replaced by something else and generally holding back the community.
zzzeek 13y ago
> All the new python3/python2 libraries I've noticed adhoc recently have been doing the horrible 'polyglot' one-code-base-support-python2-and-python3 thing, or been in python2. uh, what's better? two codebases? heh, hardly. Trust me.
drewcrawford 13y ago
Well I suppose it's all in how you interpret them. For example, if you look at https://wiki.python.org/moin/2.x-vs-3.x-survey?action=AttachFile&do=view&target=2013-2014+Python+2.x-3.x+survey.pdf https://wiki.python.org/moin/2.x-vs-3.x-survey?action=Attach... which shows 22% Python 3 vs Python 2 adoption, perhaps that sounds bad. But if you imagine that those 22% are the green-field projects and 78% are the people maintaining Eve Online, then that is a great outcome for Python 3. So I guess the question hinges on whether you believe Python 3 usage is highly correlated with green-field development, which is a belief I hold. > I presume you've read There are a lot of things I dislike about this article. One is that it acknowledges that library support can pull you to Python 2, while totally ignoring that library support can also pull you to Python 3. For example, as a result of spending a lot of time in Python 3 I have a lot of Python 3 code (e.g. what was a month ago green-field library development). These libraries are neat, and I want to use them, and it is a requirement for using them that I use them from Python 3, and they cause me to use Python 3 in the same way that Twisted's Python 2-only support causes some other developer to go to 2-only. The pendulum can swing both ways, and it's up to us as library authors to decide which way we want to swing it. In my view, the real villains here are library authors who have decided to make Python 2.x a first class citizen and add new features do the 2.x versions of their library instead of designating 2.x as bugfix-only like the Python Software Foundation did long ago. The second thing I dislike about the article is that it ignores the obvious solution: port package X to Python 3. Now for very large libraries this may not be feasible, but certainly the subset you're going to use in your project could be ported, and of course the entire library can be ported for smaller cases. We all need to be doing more to give back to the open source community, most of us take and then give nothing, this is not a good combination. The fact that "submit a patch" is never discussed as a possibility in these "boohoo Twisted doesn't support Python 3" discussions is beyond ridiculous and exposes what I think is a very serious problem in the community. Are we hackers or are we whiners? So I think we should hack, and if we want package XXX for Python 3 we should all pitch in and work on that.

jofer 13y ago

What's horrible about the "polyglot" approach? Beyond not getting to take full advantage of python3, it's really a relatively painless solution (though when you hit the pain points (bytes vs strings vs unicode) you'll notice).

shadowmint 13y ago
There's nothing particularly wrong with it (honestly polyglot should have been python 3.1, with new features at they rolled to 3.2, 3.3, etc. in my opinion); but if the reason for using python 3 is that it has shiny new features (like async io), it's a bit of bummer because you can't use them if your library is py2 compatible. ...which kind of makes it 'python 3 but actually python 2 running on the python 3 runtime', and the code is harder to maintain than either python 2 or python 3 (twice as much testing to do too). Not really much of a carrot for library developers to support python 3.
- jofer 13y ago
  Very true. It's still better than the option of maintaining two separate codebases, i.m.o., though.
- zzzeek 13y ago
  what kind of library could transparently use async IO, or not, based on platform? using explicit async for anything dramatically changes the behavior and public API of the code. there is of course a huge carrot for library developers to support python 3 which is, so that python 3 users can use your library, rather than having all of your work replaced by something else and generally holding back the community.

zzzeek 13y ago

> All the new python3/python2 libraries I've noticed adhoc recently have been doing the horrible 'polyglot' one-code-base-support-python2-and-python3 thing, or been in python2. uh, what's better? two codebases? heh, hardly. Trust me.

drewcrawford 13y ago

Well I suppose it's all in how you interpret them. For example, if you look at https://wiki.python.org/moin/2.x-vs-3.x-survey?action=AttachFile&do=view&target=2013-2014+Python+2.x-3.x+survey.pdf https://wiki.python.org/moin/2.x-vs-3.x-survey?action=Attach... which shows 22% Python 3 vs Python 2 adoption, perhaps that sounds bad. But if you imagine that those 22% are the green-field projects and 78% are the people maintaining Eve Online, then that is a great outcome for Python 3. So I guess the question hinges on whether you believe Python 3 usage is highly correlated with green-field development, which is a belief I hold. > I presume you've read There are a lot of things I dislike about this article. One is that it acknowledges that library support can pull you to Python 2, while totally ignoring that library support can also pull you to Python 3. For example, as a result of spending a lot of time in Python 3 I have a lot of Python 3 code (e.g. what was a month ago green-field library development). These libraries are neat, and I want to use them, and it is a requirement for using them that I use them from Python 3, and they cause me to use Python 3 in the same way that Twisted's Python 2-only support causes some other developer to go to 2-only. The pendulum can swing both ways, and it's up to us as library authors to decide which way we want to swing it. In my view, the real villains here are library authors who have decided to make Python 2.x a first class citizen and add new features do the 2.x versions of their library instead of designating 2.x as bugfix-only like the Python Software Foundation did long ago. The second thing I dislike about the article is that it ignores the obvious solution: port package X to Python 3. Now for very large libraries this may not be feasible, but certainly the subset you're going to use in your project could be ported, and of course the entire library can be ported for smaller cases. We all need to be doing more to give back to the open source community, most of us take and then give nothing, this is not a good combination. The fact that "submit a patch" is never discussed as a possibility in these "boohoo Twisted doesn't support Python 3" discussions is beyond ridiculous and exposes what I think is a very serious problem in the community. Are we hackers or are we whiners? So I think we should hack, and if we want package XXX for Python 3 we should all pitch in and work on that.