1. 8
  1.  

  2. 0

    I’m still just shocked that they find so much value in Django that it is worth spending large amounts of engineering resources hacking up CPython instead of migrating to another language all together.

    1. 7

      They are not only finding value, they are also sensible about risk management and making Python better.

      No hipsterism, only doing a good job, is best.

      1. 0

        Hmm… are the changes they are making to Python that beneficial to the masses?

        I don’t think it’s “hipsterism” to reevaluate whether or not you’re still getting all the benefits you once were from a language/framework once in a while—that’s sensible, to me. Maybe they are doing that, though. They just start every post like this with vanity “we are the biggest django app ever,” which makes it harder to believe.

        And, there are certainly sensible ways to derisk rewriting pieces of a system, and they likely are already using some of them to test their experimental changes to the foundational stuff they mess with (CPython).

        1. 1

          Maybe it’s not vanity but perspective into the risk they’d take in migrating. Going for whatever the others are using is bound to be harder to test than a CPython fork, or what do you think?

          What does it matter if the changes are beneficial to the masses or not? Is the value of a contribution measured in customer reach?

          1. 1

            Going for whatever the others are using is bound to be harder to test

            See, this is the problem. I’m not suggesting they follow anyone, and I am not sure why you’re assuming that just because a rewrite happens it’s because someone is chasing a new fad. There are many different paths for them to evaluate, and some even have a pretty interesting story.

            Suppose they adopted Jython (though, I have no idea what CPython version tracks anymore) for a while, they could start to convert poorer performing code with Java and utilize the interop.

            They could also adopt microservices and use Go, or Clojure, or Scala, or C++14 Services that speak Thrift.

            The point I am trying to make here is that they are basically operating a fork of CPython (the masses comment) and though some stuff, like this, might get merged back, forks inevitably require more maintenance, and resources to deal with. Patches need to be applied, tested, released, etc, etc, etc.

      2. 4

        I think the answer is that it is not large amounts of engineering resources. If you look at CPython pull request in the article, it is a trivial amount of code (less than 200 lines).

        1. 2

          Never underestimate how long it takes to write, test, rewrite, test, etc. and submit a 200 line PR. This may have taken months, and the thanks section mentions contributions and discussions from multiple people. I don’t think it took a year, as the post says it took a while to lose the efficiencies the previous GC post (January ‘17) created, but a couple of months doesn’t seem unreasonable for something like this.

          1. -1

            And you think rewriting their whole codebase in a different language is going to take less than a couple months? ;-)

            1. 0

              Did I say that?

        2. 2

          Same reason COBOL supports Unicode. You can probably hack up CPython with a couple of engineers while the rest of the engineering team Moves Fast,* while migrating to another language is a serious undertaking that deeply affects all of engineering. And even if you could magically build the new system and migrate everything overnight, you’re still left with all these senior Python programmers who have to learn a completely new language. In the long term it might be a better option, but in the short term it’s a terrible idea.

          *And for all we know, this could be a stopgap while another team preps for a language migration.