491–500 of 733 posts
The "industry standard" platform is only just getting around to switching to Python 3: https://vfxplatform.com
Going forward, I'll be maintaining Python 2.7 for the indefinite future. This will be under project name "Bladders". (Python is named after Monty Python's Flying Circus. There is another fantastic British comedy called Black Adder, and the main character is sometimes called "Bladders" as a contraction of Black Adder.) Unlike Tauthon, I won't change the language at all, only maintenance. I'm also going to make a curat…
But... why? Python 3 has been "good enough" since 3.4. By 3.6, it was markedly better than 2. With the upcoming 3.8, it seems to be better in every way (including performance!). I loved Python 2 for a long time. It was a beautiful language. But after seriously using 3, I would never go back. As in, I would turn down job offers involving Python 2 in any other context than "we're hiring you to help us upgrade".
Better how? Or better at what?
It's likely that our opinions will be different but I've got an open mind and I'm genuinely curious about your experiences and opinion.
(I hated PEP 572 at first but then some comment here on HN made me rethink and change my mind.)
Earlier quoted context omitted.
> python 2 to 3 (at least by 3.3 or so) was one of the easiest transitions I've ever done. Good for you. Some of us had code bases of considerable size and complexity though. The fact is that for working software on the python platform, this upgrade represented work that had to be done that for a legacy app that was still chugging... little benefit. If you already coded around the python 2 limitations for Unicode eg,…
You have a dependency rot problem. Are you missing unit tests? Because having a ton of unit tests can reduce dependency rot, breakage and overall make engineering upgrades just a lot easier to deal with. They don't catch everything of course, but they can catch a lot. If you haven't put in the priority to update your Py2 to Py3 apps by now, I really think your shop has the wrong priorities. It's not just about Py2/3.…
CG/Visual Effects industry is still firmly using Python 2. Only in 2020 are they taking the first step to transition to Py3 [1]. Users and studios are held back because the Python runtime is used inside major applications; Nuke, Houdini, Maya as well as libraries and APIs. None of them have released a version that runs Python 3 yet.
The reasons for delaying it (mentioned in a footnote on that page) makes sense to me. Previous years were focusing on coordinating updates to GCC, Boost, C++14, Qt, and waiting on Python bindings for Qt.
Also, I've worked at a couple studios many people have probably heard of and none of them have unit tests covering much of their code. The focus is on tools that facilitate in-house artists where responsiveness to needs are valued over architecture and completeness. Requirements change for each project and previous requirements are often sacrificed (until a new project needs them in a few years).
I'm itching to move to Python3, but even for standalone tools I've felt it better to choose a completely different language (or Python2) instead trying to mix Python2 and 3 because having them co-exist creates more headaches in managing the environments, dependencies, and coding styles.
Earlier quoted context omitted.
I am not sure what you want to say with your comment? That you move to another language as soon as there are breaking changes because you are invested as a user and therefore dissapointed? While this is a valid reason, it's just the way languages work. Some prioritize getting the language right and other backwards-compatibility. If your argument is categorical (languages that make breaking changes are bad) then indee…
This is a bit and oversimplified, but it also seems a bit weird, to me, to respond to a situation of "man it's going to be really annoying to rewrite all this code" with "You know what sounds like a better option? Rewriting all this code!"
One thing that confuses me about Python is just how many projects don't specify if the app is supposed to use 2 or 3, and the correct answer isn't 'either'. Check out something from Github, only to find I actually do need Python 2.7 or something. Is it that Python developers assume everyone will just intuit the version, or is there a default?
Both errors were familiar from earlier cases of trying to run with the wrong Python version, but I have no idea how the code managed to do that for both, and frankly it wasn't worth the effort to look into.
Earlier quoted context omitted.
Python 3.1 came out 10 years ago. 3.2 was released in 2011. What does that mean about the complaints since, let’s just say 2015 to be fair?
I heard several people saying that 3.6 was the first Py3 worth transitioning to. Largely for async (I think async/await came to live then). There is this take on performance: https://hackernoon.com/which-is-the-fastest-version-of-pytho...
3.5 fixed % formatting for bytes, further making 2/3 transitions easier (or harder, depending on your use/abuse of strings vs bytes).
3.6 added the first 'exciting' new feature: f"formatted string {literals}" if you don't have an asynchronous type project that can make good use of async/await.
Earlier quoted context omitted.
You've never encountered badmouthing from a pro builder about other tool brands? How many did you talk to? Builders make the Ford v Chevy debates look minimal in comparison.
I think he means more 'craftsman' vs. 'builder' in mentioning professionals. I don't think there's a time I can remember when Norm Abram (probably now one of the greatest or at least most prominent carpenters of a generation) ever mentioned the particular tool brands he was using. And looking back on earlier seasons of This Old House, he was hand-nailing thousands of nails a day (nowadays he and everyone else often u…
Earlier quoted context omitted.
> python 2 to 3 (at least by 3.3 or so) was one of the easiest transitions I've ever done. Good for you. Some of us had code bases of considerable size and complexity though. The fact is that for working software on the python platform, this upgrade represented work that had to be done that for a legacy app that was still chugging... little benefit. If you already coded around the python 2 limitations for Unicode eg,…
You have a dependency rot problem. Are you missing unit tests? Because having a ton of unit tests can reduce dependency rot, breakage and overall make engineering upgrades just a lot easier to deal with. They don't catch everything of course, but they can catch a lot. If you haven't put in the priority to update your Py2 to Py3 apps by now, I really think your shop has the wrong priorities. It's not just about Py2/3.…
I am not sure how you could possibly know this. You have no idea what else they were working on instead.
Earlier quoted context omitted.
This x 1000. “The free libraries we chose to depend upon haven’t migrated.” Do you have programmers? “Of course.” Put them to work. “We have other priorities.” Well then. Your choice, your outcome.
This is dumb. You're blaming people who probably don't get to call the shots. The managers who do have the ability to make different decisions are, themselves, often under the gun to meet other commitments. Sure, they will have to cope. One of the ways people cope is by accepting security risks and continuing to run with old versions. Another is to decide that Python isn't for them, and move resources toward better p…
I think he's blaming organizations, not engineers.
I also think organizational dysfunction is a problem that isn't a technical problem that the Python project has the capability or duty to solve.