41–50 of 133 posts
Earlier quoted context omitted.
I did a similar project, a typed perl. cperl. I could import most the modules, and did add types to some of the important modules. Eg testing was 2x faster. I needed typing patches for about 10% for most CPAN packages. A type is a contract, not a hint!
> A type is a contract, not a hint! In Python it is a hint.
Earlier quoted context omitted.
Reading the next sentence clears the confusion: > SPy is not a "compiler for Python". There are features of the Python language which will never be supported by SPy by design. Don't expect to compile Django or FastAPI with SPy.
Yeah but then don't say that SPy is a (interpreter and) compiler in the first place? Just say it's a interpreter.
SPy is a compiler. SPy is not a compiler for OCaml. SPy is not a compiler for COBOL. SPy is not a compiler for Python.
The problem with this is that the main value of Python is its ecosystem. SPy aims to be able to import Python libraries, but also not implement all Python features. If you are not 100% compatible how can you reliably import libraries? SPy seems most likely to be more likely to be appealing as a more Pythonic alternative to Cython rather than a Python replacement.
hello, author of the blog post and author of SPy here. > how can you reliably import libraries? the blog post specifies it but probably not in great level of detail. Calling python libs from spy will go through libpython.so (so essentially we will embed CPython). So CPython will import the library, and there will be a SPy CPython interop layer to convert/proxy objects on the two worlds.
I like the idea of a compiled language that takes the look and ethos of Python (or at least the "looks like pseudocode, but runs"-ethos) I don't think the article gives much of an impression on how SPy is on that front.
This is what F# provides. F# has a similar whitespace syntax to Python, but is statically typed and can be compiled AoT. Bubble sort Python: mylist = [64, 34, 25, 12, 22, 11, 90, 5] n = len(mylist) for i in range(n-1): for j in range(n-i-1): if mylist[j] > mylist[j+1]: mylist[j], mylist[j+1] = mylist[j+1], mylist[j] print(mylist) Bubble sort F#: let mylist = ResizeArray [ 64; 34; 25; 12; 22; 11; 90; 5 ] let n = Seq.l…
I like the idea of a compiled language that takes the look and ethos of Python (or at least the "looks like pseudocode, but runs"-ethos) I don't think the article gives much of an impression on how SPy is on that front.
This is what F# provides. F# has a similar whitespace syntax to Python, but is statically typed and can be compiled AoT. Bubble sort Python: mylist = [64, 34, 25, 12, 22, 11, 90, 5] n = len(mylist) for i in range(n-1): for j in range(n-i-1): if mylist[j] > mylist[j+1]: mylist[j], mylist[j+1] = mylist[j+1], mylist[j] print(mylist) Bubble sort F#: let mylist = ResizeArray [ 64; 34; 25; 12; 22; 11; 90; 5 ] let n = Seq.l…
var mylist = [64, 34, 25, 12, 22, 11, 90, 5]
let n = mylist.len
for i in 0..n-2:
for j in 0..n-i-2:
if mylist[j] > mylist[j + 1]:
swap(mylist[j], mylist[j + 1])
echo mylistIt'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…
> SPy does something different: on one hand, it removes the dynamic features which make Python "slow", but on the other hand it introduces new features which make it possible to implement and use the same pythonic patterns which we like.
The author seems unusually focused on explaining his new way, which may help it feel more like a new language with a coherent philosophy and unique benefits in its own right.
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?
Common Lisp doesn't use (expensive) CLOS dispatch in the core language, e.g. to add two numbers or find the right equality operator. That's one known pain point due to CLOS having been "bolted-on" rather than part of the language which makes the divide between internal (using typecase and similar) and external (generic functions) dispatch pretty ugly; and gave use the eql/equal/equalp/etc... hell. Thing is that you n…
You don't like those? I've always considered them a fairly elegant deconstruction of the problem domain of equality checking. DWIM languages can get very confusing when they DWIM or don't DWIM.
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 advantage…