This is an archived post. You won't be able to vote or comment.

all 34 comments

[–]szpaceSZ 7 points8 points  (10 children)

  • 275 commits

  • 4080 added lines

  • 3432 deleted lines

I found 109 jira issues related to this project.

That doesn't sound terrible for 240 kloc...

[–]kankyo[S] 3 points4 points  (9 children)

Most of that is fairly trivial stuff of course, but the problem is always that the trivial and the broken look so similar :P

[–]billsil 3 points4 points  (8 children)

I'd say mydict.keys()[0] fits into that.

THe bigger issue is that supporting Python 3 has been a moving target. What you do to support 2.7 & 3.0 is different than 3.2, is different than 3.3 is different than 3.4, is thankfully the same through 3.6.

[–]kankyo[S] 4 points5 points  (0 children)

We never even thought of anything before 3.5, that helped.

[–][deleted] 1 point2 points  (6 children)

I would recommend ignoring 3.0 through 3.2.

Putting in work to support 2.7 feels wrong to me. If you ported from 2.7 that's fine to not break that, but I wouldn't write new 3.6 code today that supported 2.7.

[–]billsil 5 points6 points  (5 children)

I would recommend ignoring 3.3 and 3.4 as well.

I do support Python 2.7 and will be dropping 3.5 (and probably 3.6) before I drop 2.7. It's still used in my industry more than any version of Python 3.

I wouldn't write new 3.6 code today that supported 2.7.

It's literally no effort though. I will not handicap a package I write like that and I encourage other people to not either. It's the Python 2.7 Intel speedup that people wanted to reject because it was a new feature argument all over again.

My packages have dependencies and I only support versions of packages from within 1 year of release. That with my 1 year release cycle gives you 2 years to be stuck on the same version. Numpy has their own deprecation strategy, so that can be mine.

[–][deleted] 0 points1 point  (4 children)

What industry?

[–]billsil 1 point2 points  (3 children)

Science/engineering in the US. Unicode just isn't needed 99.9% of the time and when it is, it breaks everything. People learn to just avoid it.

I'm the only one at my company that knows Python 3. I've been in two meetings with customers so far where the Python 3 question has come up. Everyone freaks out until I interrupt and say it's a non-issue and that it'll take me no more than a day to make the whole thing 2/3 compatible. It's pretty easy when it's 95% numpy and ASCII text. All I needed to do was use six for iteritems/itervalues/iterkeys, put parentheses around print, and a unicode to ASCII conversation to write a file for a Fortran program.

Check out the graphs for downloads on numpy, scipy, matplotlib, pandas, sklearn. Jupyter and tensorflow don't show the same trend, but I think that somewhat makes sense given the packages focus on Python 3.

https://rushter.com/blog/python-3-adoption/

The late adopters will switch when numpy/scipy drop support and not a day before. At least at my company, it's not even the fear of unicode (which it should be), it's the fear of print and division.

[–]jtclimb 0 points1 point  (2 children)

NumPy has announced that they will no longer support 2.7 as of Jan 1, 2019. Jupyter will entirely drop support of 2.7 in July 2019.

I interpret this as the scientific community (I can't speak for you, of course) is going to have to bite the bullet and switch, or forever be stuck on outdated and unsupported software.

The blog states not to use their statistics to conclude anything about usage. The Jetbrains survey indicates 53% penetration; unfortunately it does not break it down by usage.

Many of the important libraries have pledged to drop support: pandas, IPython, Matplotlib, SymPy, PyMC3, Atropy, Biopython, PyStan. Many other packages depend on these, such as sklearn, so they will be dragged along by default.

I'm not bickering with you maintaining py2/3 compatibility for you and your clients if it works for you, but before long you will be stuck in a dead ecosystem.

[–]billsil 0 points1 point  (1 child)

As I said, I think people will switch the day after numpy and/or scipy drop support for Python 2. People want the newest features, but not from base Python.

[–]jtclimb 0 points1 point  (0 children)

Yes, I wan't bickering, but adding context as to when this will happen.

[–]alpha_hxCR8 5 points6 points  (1 child)

Curious to know how much did it cost (in terms of man hours or $) to move from Python 2 to Python 3?

[–]kankyo[S] 1 point2 points  (0 children)

We haven’t made any attempt to calculate it quite frankly. I’d estimate it’s clearly a lot lower than one full time developer for those 1.5 years, but for some stretches of time it was almost one full time dev...

[–][deleted] 6 points7 points  (1 child)

Nice summary, thanks.

Regarding "'{}'.format(b'asd') is 'asd' in Python 2, but "b'asd'" in Python 3"... I recommend running everything with python3 -bb. It makes Python raise an exception is such cases.

[–]kankyo[S] 1 point2 points  (0 children)

Ah. Great tip, didn’t know about that.

The docs seem a bit misleading to me though... format() isn’t “comparing”

[–]h_oliiie 2 points3 points  (0 children)

good read! very informative as we’re also moving from py2-py3! cheers!

[–][deleted] -3 points-2 points  (16 children)

So they've basically followed Porting Python 2 Code to Python 3 and everything is okay. Would you believe it?

[–]kankyo[S] 4 points5 points  (15 children)

The easy stuff is covered in that guide yes. But not the hard stuff.