Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

  • Hacker News
  • As a prospective user the first thing I look for is lists, list comprehension, list slices, string methods, zip, zip*, tuple destructuring, generators, dicts and sets. These data structures, their syntax, and associated methods are what make Python a joy to use. They are what make it possible to solve a puzzle in a one-liner.

    The examples in the playground are neat but I don’t see any of the Python bread and butter usage. I see C with Python syntax.

    I’d like to see Python syntax solving a problem in a pythonic way, albeit with type annotations. And then I’d like to see the compiled version run 30x-100x faster. Is that ultimately the promise of this project?

  • If in the end we can just have .spy on some files that have performance critical functions in them and the rest is just normal python, this could be down right amazing.

    We recently swapped out mypyc optimised module for a rust implementation to get a 2-6x speed up, and not having to do that would be great.

  • This seems to be going for a somewhat similar goal to Mojo [0] - anyone here who used both and is willing to offer a comparison?

    [0] https://www.modular.com/mojo

  • Common Lisp also allows you to redefine everything at runtime but doesn't suffer from the same performance issues that Python has, does it?

    Doe anyone have insight into this?

  • Neat idea! Author’s ideas about different subsets of Python are worth the price of admission. What you can express in the type system, what performs well under JIT, what’s basically same and reasonable, may not be precisely specified, but are still useful and distinct ideas.
  • Antonio Cuni gave a great talk about SPy at EuroPython 2024: https://ep2024.europython.eu/session/spy-static-python-lang-...
  • Looks very interesting!

    I remember chatting with one of the creators of PyPy (not the author of TFA) a number of years ago at HPI. He had just given a talk about how RPython was used in PyPy development, and I was fascinated.

    To me, it seemed completely obvious that RPython itself seemed like a really interesting standalone language, but he would have none of it.

    Whenever I suggested that RPython might have advantages over PyPy he insisted that PyPy was better and, more strangely, just as fast. Which was sort of puzzling, because the reason given for RPython was speed. When I then suggested that they could (after bootstrap) just use PyPy without the need for RPython, he insisted that PyPy was too slow for that to be feasible.

    The fact that both of these statements could not really be true at the same time did not register.

  • It's weird, but the pain of moving to a whole new language seems less than the pain of using one of these language subsets. I guess it might be because of "loss aversion": we dislike losing something we have more the value we put on gaining it. In a new language each newly added feature is a gain, but in a language subset you're always encountering things you would have in the full language. So no matter how good the rational case is, there is a bias against them. I can't think of a successful one actually - anyone?
    by ajb

Explore Birbla archives