Found the Python 2 developer folks!
Joking aside, Python 3 is the only Python. The only people who should use Python 2 are those supporting legacy codebases, and even they should start migrating.
Joking aside, Python 3 is the only Python. The only people who should use Python 2 are those supporting legacy codebases, and even they should start migrating.
For new, smaller projects, that don't have too many external dependencies - Python 3 is fine. Again, even in these cases, the benefits are largely superficial.
Out of interest whats the biggest time sink while doing this? I've had a lot of luck using 2to3 and with decent test coverage and a UAT environment that people can access, its not exactly months and months of work changing "xrange" to "range", and "print" to "print()"
You were indeed very lucky if all projects you've worked on had decent test coverage.
In order to ease porting, I've created a modified Python 3.6 interpreter that generates warnings in a lot of the cases that real Python 3 would generate an exception. See https://github.com/nascheme/ppython .
The goal is to have a 2to3 script that generates something that will run, with warnings, under me modified Python. Once you fix all the warnings, your code should run correctly in Python 3.
Surely that's a bug in the system that you've just uncovered and fixed? Py2 used to use the memory address of the object when comparing by default, which is just... crazy, especially for a language with so few WTFs:
>>> object() > object()
True
>>> object() > object()
False
>>> object() > object()
True
>>> object() > object()
False
That looks amazing! We're going to end up porting a fairly large + critical Django app to py3 and I definitely think this could ease some of the pain. I'm going to give it a go when I get the chance.
Its true that that's crazy, but, OTOH, everything-can-be-sorted is a useful feature (which Erlang has, for instance). Py3 could conceptually have retained it with a different implementation (this would probably still have been a breaking change from Py2, but not a feature loss.)
The cost is justified if you want to use a supported language.
Obviously when I say "I will support it", I don't mean myself, single-handedly. I mean my company. Or someone else's company. The point is, commercially speaking, nobody cares about official PSF support. The world will go on unaffected, with or without it.
Saying new versions will not be Python 2 compatible is not a request for Companies to upgrades. It's just a statement that they will be stuck on old version of libraries, unless they buy* support for a vendor.
We (the IPython team) have no objection if Continuum or Enthought provide a Paying version of IPython 6.x that is Python 2 compatible, but that's their problem. It does not prevent either the core developer of the Python-3 only project to consult on potential Python 2 internal fork.
I honestly think that this would be a much sane model that would make both sides of the Py2vsPy3 battle happy.
The end of life of python 2, and the end of python 2 support in popular libraries isn't "a damn good reason"?
Note - I'm the co-chair for PyDataLondon (and the local conference series). I regularly poll my monthly meetup audience to see how many folk upgrade each month. Normally 1-10 per month stick their hand up, nobody sticks their hand up if I ask "how many downgraded from Python 3 this month?".
All my python 2 only code explicitly invokes python 2 on the shebang line.
"Hey folks. I've got to do lots of work that will result in no new visible functionality and I'd like to be paid for it"
I did consider slipping a Python 3 upgrade in there at the same time but there are limits to my powers of persuasion.
So - Python 3 will have to wait.
Something like 2 days maintenance every 9 months to stay current, or 4 days every 2-3 years to go from LTS to LTS. If a customer doesn't understand why they need to be paying maintenance every x months or years, isn't that your fault for not making that clear in the beginning? Sorry if it seems like I'm picking on you, but I've seen this kind of comment quite a lot, and I've never asked the question before.
In other words, they understand continuous maintenance, but not continual maintenance. Anything else is either too awkward to write on a budget. If you suggest that it needs periodic review, they'll think you just need to "do it right the first time, so this isn't an issue going forward", whether or not that makes any sense.
However for many reasons it's often tricky:
1. This is something you have to address in the initial stages of a client relationship and with price-sensitive clients unused to software development if you're not careful it can sound like you're just rent-seeking.
2. 'Big but infrequent' changes are difficult to cost. Django LTS upgrades are every 5 years. Breaking changes like Python 2 to 3 are even rarer. What figure would I have proposed during the sales process that would have correctly covered me for these? I'm almost certain I would have significantly underestimated.
3. It's not always clear if you're entering into a long-term relationship with the client. They might expect the website to be completely replaced in a year or so, they might be intending to bring development in-house or various other things that make 'saving for a rainy day' a tricky proposition.
I've also found that clients will often be acquired, go through management changes, etc that make having these things built in become unstable. One of my clients was acquired by Merck, then Merck sent a letter saying they were terminating all contracts. 18 months later, I get a frantic e-mail from some low-level people asking why I was no longer updating things for them.
The median life of many companies makes building in release->release upgrade support difficult in practice.
1. Yes. I always put the on-going fee in the initial project estimate, so there's no surprises.
2. Yes, it requires some guess-work. I've also found that it saves time to take one feature migration (like removing django's url patterns() function) and making that change to all projects at the same time (rather than making all the upgrades to one project at once). I also have found it helpful to reduce the number of 3rd party dependencies. (Fewer things to upgrade, and fewer things that may potentially stop getting supported.)
(Also "Django LTS upgrades are every 5 years" - I was going to correct that to 2 years, but I suppose you can completely skip an LTS line if you time it just right (like, jump from 1.8 directly to 2.0). But you still need to upgrade every _4_ years. Right?)
3. Yes, it's something to figure out initially.