Why I'm Making Python 2.8
21–30 of 392 posts
Re: Why I'm Making Python 2.8
#22Earlier quoted context omitted.
Python 2 supports unicode and asyncio.
i know it does - but it would be nice to have the everything-is-unicode mechanism of python 3. Asian developers hit unicode problems before US based developers because of the natural differences in underlying OS language.
Re: Why I'm Making Python 2.8
#23I make software that people can write plugins for in Python. After months, years of struggle we finally dropped support for Python 2 because our small team could not bear the overhead of maintaining two bindings. We work a lot with researchers in signal processing domain and we have hard time as it is to get people to use Python 3. Please, do not put obsolete software on life support.
Downvoting because Python 2 is anything but obsolete. People still love using it.
Re: Why I'm Making Python 2.8
#24I can't fault a single thing in his justification. This should have been the approach to modernising python all along.
The core driver for the Python 3 break was the fix in text model, this is what allowed literally everything else as it completely broke existing code.
And I, for one, think it's one of the most important improvements of Python 3, the text model of Python 2 is a giant mess and makes it very hard to correctly deal with non-ascii text for any non-trivial software, especially in large teams where not everybody will carefully evaluate the text-ness of their code..
Re: Why I'm Making Python 2.8
#25this is incredible - give me unicode support in python 2. asyncio ? probably .. i'll still be happy with gevent. This is a clear path for a python upgrade.
Nope. Can't be done without getting Python 3 either way, because Python 3's text model is not compatible with Python 2's. That is why the core team allowed the other breaking changes, because software was going to be broken in the first place.
Re: Why I'm Making Python 2.8
#26Earlier quoted context omitted.
That would mean someone develops a library that uses features of Python 3, but needs some horrible hacking to port those features to Python 2. Thanks, but no - please make a cut and decide or split it in two separate packages.
isnt that what six already does ? https://pypi.python.org/pypi/six
Re: Why I'm Making Python 2.8
#27Python programmers and companies with python code should spend the time and effort to move to python 3 instead of spending that time and effort to backport stuff to python 2 because python 2 is deprecated and the future is python 3. Python 3 I think people and businesses with python 2 code would be better off moving their code bases to python 3 instead of doing things like this.
I hate Python 3's removal of the (lambda (key, value): blah) tuple unpacking syntax, and the forcing of parentheses for print statements. They might seem minor but they aren't for me. So I'm not at all eager to move to version 3 and don't really see any benefit. Not sure if those who aren't migrating feel the same way, but I wouldn't be surprised if some of them do.
(Edit to address comment below: There are more issues I have with Python 3. It allows more bugs to slip through, for instance. I actually particularly like a comment I just wrote, so I'll link to it here: https://news.ycombinator.com/item?id=13145299 Do note that this was added after the reply below.)
Re: Why I'm Making Python 2.8
#28Earlier quoted context omitted.
Or possibly it makes it easier to have code that works on both. Although that requires this to catch on enough that 2.7 compatibility isn't required.
That would mean someone develops a library that uses features of Python 3, but needs some horrible hacking to port those features to Python 2. Thanks, but no - please make a cut and decide or split it in two separate packages.
The "horrible hacking" already exists bundled into libraries and tools like Six and Future.
> split it in two seperate packages.
That was tried, and failed every time. Because now you end up with two diverging and hard to reconcile code bases. A single-source cross-version library, while not trivial (and not allowing the user of more advanced P3 features) works way better.
Re: Why I'm Making Python 2.8
#29I make software that people can write plugins for in Python. After months, years of struggle we finally dropped support for Python 2 because our small team could not bear the overhead of maintaining two bindings. We work a lot with researchers in signal processing domain and we have hard time as it is to get people to use Python 3. Please, do not put obsolete software on life support.
> Please, do not put obsolete software on life support. Downvoting because Python 2 is anything but obsolete. People still love using it.
The fact that people love and use something doesn't mean it cannot be obsolete.
At work, I care about more than 35 years old software. It is obsolete (it's written in mainframe SAS with 3270 green screens and some assembly), but people still love using it, mainly because there is no good alternative and it does the job very well.
Re: Why I'm Making Python 2.8
#30Python programmers and companies with python code should spend the time and effort to move to python 3 instead of spending that time and effort to backport stuff to python 2 because python 2 is deprecated and the future is python 3. Python 3 I think people and businesses with python 2 code would be better off moving their code bases to python 3 instead of doing things like this.
> Python programmers and companies with python code should spend the time and effort to move to python 3 instead of spending that time and effort to backport stuff to python 2 because python 2 is deprecated and the future is python 3. I hate Python 3's removal of the (lambda (key, value): blah) tuple unpacking syntax, and the forcing of parentheses for print statements. They might seem minor but they aren't for me. S…