Announcement

Collapse
No announcement yet.

Alternative Python Implementation "Pyston" Plans For Greater Performance, 64-bit ARM

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

  • Alternative Python Implementation "Pyston" Plans For Greater Performance, 64-bit ARM

    Phoronix: Alternative Python Implementation "Pyston" Plans For Greater Performance, 64-bit ARM

    Pyston as the alternative Python implementation open-sourced originally by Dropbox is forming ambitious plans for a bright future...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    I like Python but after some months away, it is easy to forget how to differentiate from instance fields and static class fields.

    The new assign-and-compare operator := is really weird, I've never seen it in any other language, it seems like a very rare corner case that have little practical use and would rarely see any use. I think Python is meant to be simple and one of its strengths is how its close to mathematical notation, close to pseudo code, and appeals to people who are not developers.
    I think this just raises the bar to entry and make it a more difficult language to comprehend.

    The match statement is something I really love in Rust, but to be honest, I don't see much use for it in Python. I don't think I would ever use it because I don't think it is very useful in a dynamic loosely-typed language. I think it is another feature that will just raise the bar to entry and make it more difficult for non-developers.

    I think there are more important issues to tackle, such as no support for top-level async. You should be able to just write an await on line 1 without any indention and have it work without any ceremony and boilerplate code.

    Comment


    • #3
      Originally posted by uid313 View Post
      I like Python but after some months away, it is easy to forget how to differentiate from instance fields and static class fields.

      The new assign-and-compare operator := is really weird, I've never seen it in any other language, it seems like a very rare corner case that have little practical use and would rarely see any use. I think Python is meant to be simple and one of its strengths is how its close to mathematical notation, close to pseudo code, and appeals to people who are not developers.
      I think this just raises the bar to entry and make it a more difficult language to comprehend.

      The match statement is something I really love in Rust, but to be honest, I don't see much use for it in Python. I don't think I would ever use it because I don't think it is very useful in a dynamic loosely-typed language. I think it is another feature that will just raise the bar to entry and make it more difficult for non-developers.

      I think there are more important issues to tackle, such as no support for top-level async. You should be able to just write an await on line 1 without any indention and have it work without any ceremony and boilerplate code.
      Actually I find I use the "walrus" operator (:=) all the time. For sure it's just a convenience and makes things feel a bit more functional-programming, because it gets Python nearer to that "everything is an expression" of some functional languages like Elixir and Erlang.


      Erlang/OTP 24 [erts-12.0.3] [source] [64-bit] [smp:4:4] [ds:4:4:10] [async-threads:1]
      Interactive Elixir (1.13.0-dev) - press Ctrl+C to exit (type h() ENTER for help)

      iex(1)> x = 1
      1
      iex(2)> (x = 1) == 1
      true


      Python 3.8.10 (default, Jun 2 2021, 10:49:15)

      >>> (x := 1) == 1
      True
      >>> (x = 1) == 1
      File "<stdin>", line 1
      (x = 1) == 1
      ^
      SyntaxError: invalid syntax




      Last edited by vegabook; 27 October 2021, 06:28 AM.

      Comment


      • #4
        Originally posted by vegabook View Post

        Actually I find I use the "walrus" operator (:=) all the time. For sure it's just a convenience and makes things feel a bit more functional-programming, because it gets Python nearer to that "everything is an expression" of some functional languages like Elixir and Erlang.


        Erlang/OTP 24 [erts-12.0.3] [source] [64-bit] [smp:4:4] [ds:4:4:10] [async-threads:1]
        Interactive Elixir (1.13.0-dev) - press Ctrl+C to exit (type h() ENTER for help)

        iex(1)> x = 1
        1
        iex(2)> (x = 1) == 1
        true


        Python 3.8.10 (default, Jun 2 2021, 10:49:15)

        >>> (x := 1) == 1
        True
        >>> (x = 1) == 1
        File "<stdin>", line 1
        (x = 1) == 1
        ^
        SyntaxError: invalid syntax



        I don't think Python is aimed at the functional programming neckbeard nerds of academia. I think it was meant more like a easy-to-learn language for non-developers and non-programmers, people like mathematicians, biologists, chemists, physicists, engineers (non-software), tinkerers, etc.

        I think it is not good if the language gets rarely used constructs that mostly appeal to neckbeards and professional software developers at the expensive of being easy to grasp for non-developers.

        As a professional software developer I like expressive languages like Rust, C#, Kotlin, etc but I think Python should be simple and appealing to non-developers.

        Comment


        • #5
          Originally posted by uid313 View Post
          I like Python but after some months away, it is easy to forget how to differentiate from instance fields and static class fields.

          The new assign-and-compare operator := is really weird, I've never seen it in any other language, it seems like a very rare corner case that have little practical use and would rarely see any use. I think Python is meant to be simple and one of its strengths is how its close to mathematical notation, close to pseudo code, and appeals to people who are not developers.
          I think this just raises the bar to entry and make it a more difficult language to comprehend.
          Interestingly, I do see it regularly in Structured Text, the text based language for PLCs (Programmable Logic Controllers), in this case it is used for assignment.

          Comment


          • #6
            Originally posted by zeealpal View Post

            Interestingly, I do see it regularly in Structured Text, the text based language for PLCs (Programmable Logic Controllers), in this case it is used for assignment.
            I never heard about that language. A quick lookup shows that it has a := operator, however I believe in that language it works just an assignment operator, unlike Python where it works as a compare-and-assign.

            Comment


            • #7
              Originally posted by uid313 View Post

              I don't think Python is aimed at the functional programming neckbeard nerds of academia. I think it was meant more like a easy-to-learn language for non-developers and non-programmers, people like mathematicians, biologists, chemists, physicists, engineers (non-software), tinkerers, etc.

              I think it is not good if the language gets rarely used constructs that mostly appeal to neckbeards and professional software developers at the expensive of being easy to grasp for non-developers.

              As a professional software developer I like expressive languages like Rust, C#, Kotlin, etc but I think Python should be simple and appealing to non-developers.
              Yes I have some sympathy for the view that the "walrus" operator is kind of a nice-to-have, but is confusing for new people. It's not necessary and adds confusion. That said, your characterization of the Erlang/Elixir examples as "functional programming neckbeard nerds of academia" is misguided. These are very practical languages that have huge concrete successes and are much used. This isn't Ocaml and/or Haskell. As a long time Python programmer I concur with the oft-repeated cliche that I'm a better programmer now because of the strictness imparted to me by having to learn Erlang. It just absolutely forces you to think structure first rather than diving in to writing your first line of spaghetti. No matter how many years of coding you have behind you, and I have decades, learning Elixir will be an eye opener and is not just for neckbeards that's for sure.

              But yes, I concur that Python is probably not the place for this. FWIW I was a very big 2.7 fan precisely for the reasons I think you're getting at: 3 was trying to be too "serious" and 2.7 was a fantastically pseudocode like place. I've since learned to love 3.x but I _still_ think for a new programmer 2.7 was (not is) better. The only reason I wouldn't recommend 2.7 now is because it's no longer being maintained and 3 has some nice new stuff notably async, and f-strings are pretty cool too, as is proper division. Unicode-everywhere is still a horrendous mess though as soon as you need to interface out.
              Last edited by vegabook; 27 October 2021, 08:33 AM.

              Comment


              • #8
                The new assign-and-compare operator := is really weird, I've never seen it in any other language, it seems like a very rare corner case that have little practical use and would rarely see any use.
                It's basically a much more awkward version of rust's if-let syntax

                Comment


                • #9
                  Originally posted by vegabook View Post

                  Yes I have some sympathy for the view that the "walrus" operator is kind of a nice-to-have, but is confusing for new people. It's not necessary and adds confusion. That said, your characterization of the Erlang/Elixir examples as "functional programming neckbeard nerds of academia" is misguided. These are very practical languages that have huge concrete successes and are much used. This isn't Ocaml and/or Haskell. As a long time Python programmer I concur with the oft-repeated cliche that I'm a better programmer now because of the strictness imparted to me by having to learn Erlang. It just absolutely forces you to think structure first rather than diving in to writing your first line of spaghetti. No matter how many years of coding you have behind you, and I have decades, learning Elixir will be an eye opener and is not just for neckbeards that's for sure.
                  Would you recommend Erlang or Elixir more for a programmer who wish to learn to become a better programmer?

                  Originally posted by vegabook View Post
                  But yes, I concur that Python is probably not the place for this. FWIW I was a very big 2.7 fan precisely for the reasons I think you're getting at: 3 was trying to be too "serious" and 2.7 was a fantastically pseudocode like place. I've since learned to love 3.x but I _still_ think for a new programmer 2.7 was (not is) better. The only reason I wouldn't recommend 2.7 now is because it's no longer being maintained and 3 has some nice new stuff notably async, and f-strings are pretty cool too, as is proper division. Unicode-everywhere is still a horrendous mess though as soon as you need to interface out.
                  I've coded mostly in Python 3, but only some in Python 2, and to me it was all the same, except that Python 3 was nicer for me because of the easier Unicode handling.

                  Originally posted by bachchain View Post

                  It's basically a much more awkward version of rust's if-let syntax
                  I really like Rust, but to me Rust is a programming language for developers, for professional programmers, while I think of Python as something that should appeal to non-developers from various different fields and backgrounds.

                  Things like the match statement which I love in Rust, doesn't excite me in other languages like Python, C#, PHP and TypeScript. The match statement is amazing in Rust but it is because it is very strongly and statically typed, and have algebraic data types (tagged unions, enums). In a weakly, dynamically typed language without algebraic data types I don't see much appeal in the match statement.

                  It is good that languages intended for professional developers have some nice features, but for a language like Python, I think it is better if it is simple and doesn't have so many more rarely used features that mostly appeal to professional developers.

                  Comment


                  • #10
                    Separating the concept of strings and binary data, and having strings be unicode was absolutely the right choice. As someone who has a native language that benefits from unicode, I have seen way too much software (in python and other languages as well) that simply didn't do the right thing with unicode data, or failed in strange ways when translated.

                    It is thankfully much rarer these days, both thanks to greater awareness, but also due to languages that makes you do the right thing by default (like Python 3.x) and forces you to think about it when converting back and forth.

                    Yes it is sometimes a bit annoying, for me mostly when dealing with the subprocess module. But the fix is usually easy: .decode('utf-8') or .encode('utf-8'). (Not sure if that would work correctly on Windows, since it uses UTF-16, but maybe python hides that, not a platform I personally target.)

                    Comment

                    Working...
                    X