As someone who works in VFX I can sympathise with CCP on this.
However the real question is: why should port everything to 3? none of the software in VFX uses it, plus a lot of people aren't really up to speed with the changes.
What is the point? yes the language "purer" but that doesn't make my life easier......
It's a chicken and egg situation - until VFX houses (often with close to a million lines of Python code integrating stuff) need Python 3 (I don't see why they would based on the new features), they're not going to ask companies like The Foundry and Autodesk to add support for it.
And the commercial companies aren't going to waste dev (and huge amounts of test time) on a feature 95% of their customers don't want or need.
Houdini's got dual 2/3 support, but I find it very difficult to believe any big studio is using the 3 support (as it wouldn't integrate with the rest of the pipeline).
If you haven't already written your own horrible hacky string handling framework, python 3's unicode support is much nicer. And IMO, for projects of the size I work on, super() alone justifies the upgrade.
But I think to talk about porting is to ask the wrong question. The main reason for python 3 isn't to port existing projects, it's to make python a good choice for new projects.
You correctly point out that unicode is much much better, but How often are you dealing with it? I know that I certainly don't have to think about it in my pipeline.
In some projects, not at all; in others, most of the time. But it's string/unicode that takes up most of the time and effort in porting; projects that don't involve much string handling are pretty trivial to port to python3, IME.
High-end wasn't mentioned before. But I know, I know, blender is often just not an option. Although I don't find the interface as bad as everyone is saying. But then again, I'm a software developer and I don't find GIMP's interface that bad either.
and it's what free/open source software gets wrong almost all the time (and I say that as an advocate of it), due to the fact devs rarely listen to users. The features are often there but they're not that easy or flexible to use, so often they're practically useless in certain situations.
There was something last year when someone came up with some workflow / design improvements suggestions to blender, and the developers just didn't understand why it was necessary, saying "it's possible to do stuff in blender".
One would think that this is not the case for blender, because of the blender movie projects where users and developers work in the same room.
> There was something last year when someone came up with some workflow / design improvements suggestions to blender
Do you mean these awful ribbons? IIRC he also suggested different views for different tasks, even though blender has always had that feature! What was a valid point where the inconsistencies in the interface and some minor things.
I think that statement can often be taken in good and bad ways, depending on the devs.
Some software I love and use is developed by people who do not care what their users think because they are their own users. They build for themselves and produce excellent results.
Some developers listen to users too much, and end up allowing every piece of their software to be configurable. Even if a very small percentage of users actually needs that configurability. They then lose focus on simplicity and elegance that the majority of their users were attracted to in the first place.
Of course, it goes the other way as well and many pieces of software are better due to user feedback.
"listen to the users" does not actually mean "change the software the way the users say to" it means to listen to how they're failing to achieve the results they are trying for and use that knowledge to improve the software. Listening to users does not preclude sticking to UI conventions and such since your users are unlikely to be software or UI designers themselves.
The point of maintaining the source code to the latest version is to guarantee its survival to the long term: at some point you will have to pass the ownership to another, younger, dev that might not have been taught into this older technology; or port your script to a newer hardware, and eventually deal with an sub-optimal or incomplete VM.
Either you maintain to the latest version and distribute the cost in time or one day you will have to start from scratch, and probably lose more time and money to do so.
See every organization still running on XP ? They may be sentence to death in 3 month, that may be the hardest way learn it.
"See every organization still running on XP ? They may be sentence to death in 3 month, that may be the hardest way learn it."
Huh? XP will just be chugging along, for another decade probably in some places. There are still business being run on DOS software FFS. What is the easiest - pay for a complete replacement somewhere in the next decade or two, or upgrading everything every few years to stay with the times?
(written from Windows XP and not likely to move for at least another half year...)
I'm sure that a lot of XP machines in the corporate world aren't connected to the internet either. For example, there's no reason to give a bunch of low-level employees in the accounting department access to the internet, and if their company's internal software runs fine on IE8 (or as native code), there's no particular reason to move away from XP. PCs on a factory floor that control industrial machinery probably aren't connected to the internet either.
Well, with Microsoft (and many other software company) ready to pull the plug of updates on this OS, I hope you have faith in your antivirus to stop every unpublished exploit.
Anti-Virus systems are not required for anybody who practices even a tiny modicum of caution (Don't browse with plugins like java enabled, never open attachments, don't click on links) - and in stand alone with a half decent set of firewall rules your Windows XP system will be fine.
A patched system with a firewall on and without "trojan horses" brought in by the user is relatively safe.
XP will stop getting patches soon.
And this list (http://www.cvedetails.com/vulnerability-list/vendor_id-26/pr...) is only going to get longer and longer, because even though Microsoft will be EOLing XP, there will be tens of millions of Internet facing machines using it, probably even in 2020.
Having a firewall + not loading trojans gets you 99.9% of the way to security.
The problems are that normally people (A) don't want to deal with the hassle of a firewall, and (B) don't like to be cautious about opening attachments (C) People don't like to be restrained about what they click on, and finally (D) People tend to browse with all sorts of plugins loaded (not to mention Javascript being almost universally loaded).
For those people, yes, they will need to have a lot more handholding by their operating system vendor.
For somebody running a Windows XP system that doesn't have to do any of those (Cash Register, Kiosk, Office Machine) - they are fine, can be locked down, and can probably run Windows XP for the next 20 years without concern.
Most places I know of running WinXP are completely cut off from Internet, using personal media like pendrives is prohibited and the identity of a user is confirmed with physical "PKI card" or something.
They will use their XP's long after the universe dies, I think.
"Most"? Really? Most of the XP machines I know of are being used like any normal desktop machine: email, browsing, office, thumb drives, etc.
I know things are different with industrial machine control, they might be different at my doctor's office, and so forth. But I don't think those special situations add up to "most". Not yet.
And the dentist office is one of them, actually. Anyway, I may be wrong about this right now, but as you note, in a few years, when the support dies and nothing works on XP any longer it will still thrive in environments I describe.
remember to refactor costs man hours, which costs real cash. If it works there is no point changing it. especially if the benefit is some so nebulous as "sub optimal VM" if you were worried about speed in the first place it wouldn't have been written in python.
also you wouldn't port your script to new hardware, you'd port Python (well wait for someone else to....)
> And that why so many businesses are outperform by new ones...
So many? Is this including the massive number of new businesses that fail in the first few years? I think that is a very hard assertion to make without seeing the actual numbers of these "new businesses." Most are private and don't report their profits, so you have no idea if they are burning through cash or actually making money -- you just see the hype.
Inertia is a total killer. Your extant codebase is both leverage and inertia. If The New Thing requires changing course and isn't amenable to your extant leverage, most (all?) companies can not maneuver to deal with The New Thing. It simply costs a great deal for very small benefit.
I would suggest that is a fault of process not programming.
If there is a need to upgrade then obviously you need to do it. However if your pipeline doesn't touch unicode, and your upgrading to python 3.3 purely for unicode, then its a massive waist of man power.
programs are a tool, nothing more. If the tool works there is no need to change it. infact its can be very expensive, especially if noone knows how to use it.
For example, most people don't need a pneumatic drill for their DIY. Yes it might be much more flexible, and really really fast. But the cost of maintaining it, and training to get the best use out of it is prohibitive.
However if you own a garage, hand tools are far too slow, and there are is a rich pool of talent to use you fast powerful tools.
Servicing technical debt sometimes costs more than refactoring. Sometimes not. A good manager/programmer can decide which situation they are in and act accordingly.
> at some point you will have to pass the ownership to another, younger, dev that might not have been taught into this older technology; or port your script to a newer hardware, and eventually deal with an sub-optimal or incomplete VM.
We're talking about Python 2 vs 3 here, not upgrading your system from Cobol to Clojure.
But the python source code's available to build, and anyway, quite a bit of the python in VFX is run through embedded interpreters in Maya, Nuke, Houdini or Katana which means they can keep using an old version indefinitely.
However the real question is: why should port everything to 3? none of the software in VFX uses it, plus a lot of people aren't really up to speed with the changes.
What is the point? yes the language "purer" but that doesn't make my life easier......