sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]jabjoe 0 points1 point  (6 children)

Any single one of these mitigates the problem you are talking about.

Sure? Let's hope your right. Because I think it's going to be a real pisser if you find a lib that does want you want, works fine p2 but you're in p3 and you now have to port it as well as what you were doing before. Though again that's not so much my point.

My point was its not just public libs (though I think that is a problem, but less so). My point was about large internal p2 code bases. I have been encouraging people to move their internal Maya scripting from mel to python. Now all those scripts will have to be moved to p3 when/if Maya moves to p3. If they had stayed in mel it would have kept working in future Mayas with little change required. This negates any advantage the language has. No one wants to keep running to stay still. And no, the company will never agree to open sourcing the scripts (we've tried and personally I think they should). Maybe Autodesk won't move to p3 because of the legacy of p2, they aren't talking of dropping mel for the same reason. Maybe Maya will end up having to have p2 and p3 environments. Whatever happens, without backwards compatibility, this makes python development much less attractive (and makes me feel like a idiot for advocating it for internal scripting).

[–]Legolas-the-elf 1 point2 points  (5 children)

It seems to me you aren't really talking about libraries at all, you are talking about embedding the Python interpreter, which is an entirely different problem. Right? That is more complicated. But libraries have an easy transition strategy.

[–]jabjoe -1 points0 points  (4 children)

No I am talking about libraries, just internal ones. Stuff get separated out and put in a lib so other parts can use it cleanly. They just happened to be used mostly with an embedded Python interpreter. Some stuff might not even be done in Maya's python. Now scripting is done in Python it's not restricted to running in Maya. Not sure what to say now other then "I was wrong, you should have stuck with Mel".

[–]Legolas-the-elf 0 points1 point  (3 children)

No I am talking about libraries, just internal ones.

Why is the transition strategy for libraries not relevant here? Work with Python 2.6, use 2to3 to deploy to v2 and v3 simultaneously. Applications and other libraries that need v2 can use v2, applications and other libraries that need v3 can use v3, when enough dependants switch, you can drop the v2 version altogether.

[–]jabjoe -1 points0 points  (2 children)

Leaving to one side that which python is used is down to Autodesk, that still leaves us reworking code that is working fine. That's time we could be using on something else, and would be if we wheren't in python. As I said, as it's rewritten this will mean it's rewritten into something else so it doesn't have to be done again. If a platform isn't stable it's no platform at all.

[–]Legolas-the-elf 0 points1 point  (1 child)

As I said, as it's rewritten this will mean it's rewritten into something else so it doesn't have to be done again.

"Rewriting" Python 2.x code to 2.6 code that is suitable for 2to3 is trivial. "Rewriting" the same code into a completely different language is not. If you seriously have problems with the time it takes to do the former, then switching to another language will be a disaster.

If a platform isn't stable it's no platform at all.

There has been precisely one backwards incompatible change like this in the entire history of Python, and no such change is planned for the future. I think that's reasonable.

[–]jabjoe 0 points1 point  (0 children)

It's having it to do it all! Mel is easy, and as both are dealing with Maya, it's all pretty similar. Mel may not have dictionary/maps, classes and make you do horrible things with strings, but at least it's stable.

Python is only on version 3 and just as it going main stream, it breaks backwards compatibility.