|
|
|
|
|
|
by downer
6745 days ago
|
|
|
There's a converter for 2.x to 3.x. Or you can transition code by hand -- there are some differences in some places. Breaking backward compatibility just means not everything is guaranteed to work the same -- it does NOT mean that now everything is different. It's still Python. Being "out of date" doesn't make any sense -- today's libraries aren't suddenly going to become less functional later. The stuff that works today will still work 5 years from now. You change versions IF the new version gives you something you need. You don't change just because it's new. And, always, the paper tiger is better than the real one. Not doing something today because it'll be outdated in a few years would mean never doing anything in the computer industry. |
|
|
In theory this will work 100%... but I'm predicting this will probably introduce really nasty bugs and I'm sure they'll be limits...
"Or you can transition code by hand"
More bugs...
"Being "out of date" doesn't make any sense -- today's libraries aren't suddenly going to become less functional later."
I'm not talking about stuff you have now. I'm refering to new hotness features that you'll be missing out on; being trapped.
"You change versions IF the new version gives you something you need. You don't change just because it's new."
Typically with good languages like Python, you may not need new features - but they sure as hell make life easier and coding faster.
"Not doing something today because it'll be outdated in a few years would mean never doing anything in the computer industry."
That's not what I meant. It's more about why trap yourself in a building that's set for demolition in a few months? Theoritically migration sounds easy with the converter but to me that's a wait and see.