Announcement

Collapse
No announcement yet.

Python 3.13 Beta 2 Released For Testing The Experimental JIT & Other New Features

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Originally posted by uid313 View Post
    Python is "fast enough" for me, but I think it has other problems:
    • The standard library isn't even typed or only small parts of it.
    • Stupid PSF License instead of MIT License. (unsuitable for embedding)
    • No sandbox mode. (unsuitable for embedding)
    • async is cumbersome (you need to setup an executor before you can do await)
    • Cannot deserialize JSON to class (I know there are third-party modules and some kind of dictionary trick but it should be easier)
    • No good built-in HTTP client (urllib sucks, I know there are third-party modules such as requests and httpx).
    • python isn't a typed language. typing gymnastics is a real thing
    • license debates ignored
    • use a container
    • python -masyncio will put you into async repl, no executor needed
    • built in json to object/http client. this is fair criticism. I don't see an easy way out, as there isn't really a obvious winner in the 3rd party candidates, and there's still quite a lot of churn that would make it unsuitable for inclusion.

    I do think that python performance is still a huge issue. it's never going to be good, but it really needs to get a lot better then it is. at runtime most python code is nowhere near as dynamic as the language provides, yet there is that performance overhead of dynamism all the time.

    Comment


    • #12
      Incredible how long it took for the python reference implementation to get a JIT.

      All in all, to me the success of python is a real surpise. don't get me wrong, it is not a bad language, but its also not a very good one.
      it is just another weakly typed language with classes (very much like JS) and up until recently it had quite a poorly implemented runtime (no JIT, reference counting (which means limited multithreading/scalability, etc).

      Why Python and not Lua? well, maybe it was just good python's good fortune...

      Comment


      • #13
        I have no idea how Python ever became so popular, as it's primary purpose seems to be continually breaking anything that uses it.

        There are so many examples, and articles covering breakage because of Python changes, that it's mind boggling. For me the latest one is Kodi, as Python changed and caused it to hang on exit so it hasn't been usable on Linux for months.

        And to add insult to injury, the Python devs simply don't care. And take many months, or never, remedy these backwards compatibility problems.

        Of course part of the blame must be attributed to any developers who continue to use it, as the backwards compatibility problems with Python have been legendary for quite some time. On the other hand many, like the Kodi devs, have so much code that relies on Python that it would take a fundamental rewrite of the entire codebase to eject it.

        So all I can do is warn anyone starting a new project to not use Python. And hopefully within a decade or so it will simply fade away.
        Last edited by muncrief; 07 June 2024, 03:01 PM.

        Comment


        • #14
          Originally posted by muncrief View Post
          I have no idea how Python ever became so popular, as it's primary purpose seems to be continually breaking anything that uses it.

          There are so many examples, and articles covering breakage because of Python changes, that its mind boggling. For me the latest one is Kodi, as Python changed and caused it to hang on exit so it hasn't been usable on Linux for months.

          And to add insult to injury, the Python devs simply don't care. And take many months, or never, remedy these backwards compatibility problems.

          Of course part of the blame must be attributed to any developers who continue to use it, as the backwards compatibility problems with Python have been legendary for quite some time. On the other hand many, like the Kodi devs, have so much code that relies on Python that it would take a fundamental rewrite of the entire codebase to eject it.

          So all I can do is warn anyone starting a new project to not use Python. And hopefully within a decade or so it will simply fade away.
          It looks like you see breaking with previous versions as a sadic approach from developers. On the contrary, it is mostly to remove the cruft and leftovers and avoid keeping backward compatibility forever carrying on misbehaving code. Python 2.x to Python 3.x was a major jump, but minor version upgrades were not so dramatic. Recently I had to bump a complex project that also carried some native C libraries from Python 3.7 to Python 3.11 and it wasn't so difficult, nor it took so much fixing time.

          Perhaps if so many parts of Kodi (plugins, I guess) were not in Python, it would not have had the success it has.

          Nowadays javascript is one of the most trendy language, but it has a horrible compatibility legacy to require the "use strict"; statement to deprecate most of the nonsense it carried for years and it still carries around (scope mayhem, variable declaration, messy prototipical inheritance, "classes" are in reality functions, several way to declare a function with minor differences, etc...)

          If you take a look to the elegance of the Python standard libraries instead, you see a very tidy set of functionalities (take the datetime module as an example) based upon a fairly simple language.
          Last edited by blackshard; 07 June 2024, 03:18 PM.

          Comment


          • #15
            You can feel mojo is around the corner…
            They finally do real things to tackle the speed, now that they see what others can achieve when they said was it not feasible.

            ”Python is fast enough for me” well maybe for you. But for those who are surrounded with crappy slow python tools that won’t be recoded anytime soon, they won’t moan having strong speed improvements...

            Comment


            • #16
              Originally posted by Quackdoc View Post
              I wonder if/when we will be able to fully drop in replace cpython with rustpython on our local systems
              RustPython seems like an interesting project. Nice that it uses the MIT License too, rather than some custom vanity license.

              Originally posted by Weasel View Post
              Those are minor. Biggest problem, by far, is lack of backwards compatibility, keeps removing shit, setting bad example for libraries too, so it's like dependency hell squared. That's how bad it is.
              I don't use Python professionally, I've only used it at home for some stuff, but I haven't had any such issues.

              Originally posted by skeevy420 View Post
              It'll be interesting to see if Godot's gdscript will be able to take on Python since it's beginner friendly scripting with built-in support for multimedia, physics, and more with the MIT license.
              Godot's GDScript seems really cool, I would like to see the Godot team decouple GDScript from the Godot engine and make it available as an embeddable library.

              Originally posted by habilain View Post

              Um, what? Battlefield 2, Sims 4, Mount & Blade and Civ 4 all embed Python with no legal issues. While I won't comment on the rest of the issues you mentioned, the PSF license, which is GPL and MIT compatible, doesn't cause any problems with embedding into other software, be it proprietary or open source.
              Oh, maybe it is possible, but it would be easier and more convenient with the common, established MIT License which is much simpler and smaller than their custom vanity license.

              Originally posted by blackshard View Post
              Indeed, you need an event loop to do async/await. That's pretty standard, except for javascript/node which is event-loop based itself.

              Never thought it was a good idea to deserialize data into a class, which carries executable methods.
              A class is a class, json does not carry objects, pickle do.

              urllib is quite complete and handy enough. It's difficult to handle the lot of HTTP/FTP and other application level protocols.
              No in JavaScript and C# you don't need to declare any event loop. In C# you can even top-level awaits (without having to place the await inside a async function).

              In other languages it is very common to deserialize JSON into a class. It is very friendly to use a class too rather than have to deal with lookups in a dictionary using key strings.

              urllib is a nightmare to use, it is very tricky to use unlike fetch in JavaScript or HttpClient in .NET, or third-party Python libraries such as requests and httpx. It also doesn't support async.

              Comment


              • #17
                Originally posted by fitzie View Post
                • python isn't a typed language. typing gymnastics is a real thing
                • license debates ignored
                • use a container
                • python -masyncio will put you into async repl, no executor needed
                • built in json to object/http client. this is fair criticism. I don't see an easy way out, as there isn't really a obvious winner in the 3rd party candidates, and there's still quite a lot of churn that would make it unsuitable for inclusion.

                I do think that python performance is still a huge issue. it's never going to be good, but it really needs to get a lot better then it is. at runtime most python code is nowhere near as dynamic as the language provides, yet there is that performance overhead of dynamism all the time.
                Python is a optional typed language (like TypeScript and PHP) but the developer experience of typing in Python is rather shitty, it is much better in TypeScript and PHP.

                A container is not always an option. Sure if you can setup your own environment but if you want to distribute an application to end-users using something like Flatpak or Snap or even a .deb or .rpm, then it is not.

                Thanks for the python -masyncio tip, I wasn't aware of that, however users don't always control the execution environment. This is much more pleasant in C# and JavaScript.

                The requests library is actually very nice (except that it doesn't have async support). The httpx library is also very nice and has async support. I would love to have httpx in the standard library.

                Originally posted by Linuxhippy View Post
                Incredible how long it took for the python reference implementation to get a JIT.

                All in all, to me the success of python is a real surpise. don't get me wrong, it is not a bad language, but its also not a very good one.
                it is just another weakly typed language with classes (very much like JS) and up until recently it had quite a poorly implemented runtime (no JIT, reference counting (which means limited multithreading/scalability, etc).

                Why Python and not Lua? well, maybe it was just good python's good fortune...
                Python is from 1991 so back then a lot of languages didn't exist so then it's not so big surprise that Python became a success because I would rather use Python than C, Perl or Tcl.

                Python also got a easy to understand syntax so it appeals to lots of people who aren't even programmers.

                Actually JavaScript uses prototypes and got "classes" quite late. The classes in JavaScript is actually just syntactic sugar for prototypes.

                I think Python and Lua are a bit different. Python is suitable for writing stand-alone programs while Lua is more suitable for embedding into other programs maybe, I don't know.

                Originally posted by muncrief View Post
                I have no idea how Python ever became so popular, as it's primary purpose seems to be continually breaking anything that uses it.

                There are so many examples, and articles covering breakage because of Python changes, that it's mind boggling. For me the latest one is Kodi, as Python changed and caused it to hang on exit so it hasn't been usable on Linux for months.

                And to add insult to injury, the Python devs simply don't care. And take many months, or never, remedy these backwards compatibility problems.

                Of course part of the blame must be attributed to any developers who continue to use it, as the backwards compatibility problems with Python have been legendary for quite some time. On the other hand many, like the Kodi devs, have so much code that relies on Python that it would take a fundamental rewrite of the entire codebase to eject it.

                So all I can do is warn anyone starting a new project to not use Python. And hopefully within a decade or so it will simply fade away.
                Well its quite easy to figure out why Python became popular back in the days when your options were C, Perl and Tcl.
                It has a quite simple syntax too which makes it appealing to schools for use in education.

                Originally posted by rmfx View Post
                You can feel mojo is around the corner…
                They finally do real things to tackle the speed, now that they see what others can achieve when they said was it not feasible.

                ”Python is fast enough for me” well maybe for you. But for those who are surrounded with crappy slow python tools that won’t be recoded anytime soon, they won’t moan having strong speed improvements...
                Yeah, Python is fast enough for me, and I guess for most people for most things. Of course some people really need high-performance but then you need to use the right tool for the job, so in that case there are other languages available.

                Comment


                • #18
                  Originally posted by Weasel View Post
                  Those are minor. Biggest problem, by far, is lack of backwards compatibility, keeps removing shit, setting bad example for libraries too, so it's like dependency hell squared. That's how bad it is.
                  Yes, thank god. Remove all that old crap. I hope this includes the abomination called argparse one day.
                  Just force all these lazy people doing only the bare minimum to update their crap.

                  Comment


                  • #19
                    Originally posted by Kemosabe View Post

                    Yes, thank god. Remove all that old crap. I hope this includes the abomination called argparse one day.
                    Just force all these lazy people doing only the bare minimum to update their crap.
                    Why, I like argparse…

                    Comment


                    • #20
                      Originally posted by muncrief View Post
                      I have no idea how Python ever became so popular, as it's primary purpose seems to be continually breaking anything that uses it.
                      Tell me you never wrote anything in Python without telling me you ever wrote anything in Python.
                      Python is fast to code and by design results in good indentation so easy to read. Due to it being an interpreted language you also don't need to recompile while testing.
                      I am currently writing a Blender extension and I can just test parts of the code by pasting it into the Blender Python console.

                      I also use it at my job if I need a quick and dirty short term solution to a problem that would be too much work by hand, but won't see enough of a repeat to justify it programming in one of the other languages that we use (e.g. cleaning up a CSV, import in pandas, apply my function on rows, export to csv, import into database right in time for lunch).

                      Originally posted by muncrief View Post
                      There are so many examples, and articles covering breakage because of Python changes, that it's mind boggling. For me the latest one is Kodi, as Python changed and caused it to hang on exit so it hasn't been usable on Linux for months.

                      And to add insult to injury, the Python devs simply don't care. And take many months, or never, remedy these backwards compatibility problems.
                      Literally every programming language deprecates functions and Python doesn't just come out of nowhere with them either.
                      You get warned first if you are using deprecated functions or types, e.g. distutils was proposed to be deprecated in 2020, marked as deprecated in Python 3.10 (Oct 2021) but was only removed in Python 3.12 ( October 2023), there was ample time and documentation available to phase it out of projects. If a project didn't than it was entirely the developer of that library/program's fault and apparently nobody seemed to care about the deprecation warning for 2 years.

                      Originally posted by muncrief View Post
                      Of course part of the blame must be attributed to any developers who continue to use it, as the backwards compatibility problems with Python have been legendary for quite some time. On the other hand many, like the Kodi devs, have so much code that relies on Python that it would take a fundamental rewrite of the entire codebase to eject it.

                      So all I can do is warn anyone starting a new project to not use Python. And hopefully within a decade or so it will simply fade away.
                      It won't and backwards compatibility problems being "legendary" with Python is quite the statement to make considering it is obvious you don't program in Python yourself.
                      The biggest compatibility problem came from Python 2.7 to Python 3.x, which took over 10 years (2010 to 2020) before finally Python 2.7 was EOL and people were forced to rewrite for Python 3.X. Kodi switched barely 2 months before the Python 2 EOL (most distros either shipped both or only Python3), Python 3.0 to 3.8 were released before Kodi made the switch, so if the compatibility problem was truly as "legendary" as you said, they had ample time to switch to a different scripting language as all the addons would be incompatible regardless.

                      And despite Python3 being around and kicking for over a decade, meaning there should have been ample time for the "backwards compatibility problem" to become "legendary" after the 2.7 breakage yet we still see new programs/applications use Python in some way or form, especially now with AI were it is easy to get access to powerful libraries like TensorFlow or Pytorch. It is also still the most popular language on Github in 2023 and 2024. So yeah, seems like it isn't that much of an issue for actual developers.

                      Comment

                      Working...
                      X