A Python interpreter rewritten in Rust, that can run pip • Hacker News Board

Re: A Python interpreter rewritten in Rust, that can run pip

#31

Post by pansa2 » Fri, Feb 05, 2021, 1:12 AM UTC

ransom_rs wrote: post #4

This uses [lalrpop]( https://github.com/lalrpop/lalrpop ) under the hood I believe, which is a pretty awesome parser generator library for Rust.

> LALRPOP in fact uses LR(1) by default (though you can opt for LALR(1)), and really I hope to eventually move to something general that can handle all CFGs (like GLL, GLR, LL(*), etc).

Seems overkill for a language whose grammar is LL(1)?

Re: A Python interpreter rewritten in Rust, that can run pip

#32

Post by p1necone » Fri, Feb 05, 2021, 1:13 AM UTC

Jasper_ wrote: post #21

Phrodo_00 wrote: post #19

Earlier quoted context omitted.

Jython and IronPython don't have a GIL so you can see the effect there (it's not as bad as I thought it would be)

OK, I'll bite: how? They need some form of locking around Python objects accessed from multiple threads, since Python has no ownership model. Do they add a lock around each individual object?

Most languages with proper multithreading that I've used don't have an ownership model. Most the the standard library collection types are explicitly not thread safe, and then there's separate concurrent versions for if you're writing multithreaded code. And you're given locking/mutex primitives if you want to roll your own stuff.

Re: A Python interpreter rewritten in Rust, that can run pip

#33

Post by pansa2 » Fri, Feb 05, 2021, 1:16 AM UTC

Phrodo_00 wrote: post #19

glandium wrote: post #17

Earlier quoted context omitted.

I suspect an interpreter that "solves" the GIL problem will break tons of modules that currently only work in concurrent contexts because the GIL exists.

Jython and IronPython don't have a GIL so you can see the effect there (it's not as bad as I thought it would be)

Jython and IronPython can work without a GIL more easily than CPython because they don’t support native (C-based) extension modules. Does RustPython intend to support existing Python extensions written in C?

Re: A Python interpreter rewritten in Rust, that can run pip

#34

Post by Bostonian » Fri, Feb 05, 2021, 1:21 AM UTC

smitty1e wrote: post #30

Bostonian wrote: post #28

Earlier quoted context omitted.

A single period means is interpreted as "Why?"?

Source?

I was asking. That's how people in the thread appeared to interpret it.

Re: A Python interpreter rewritten in Rust, that can run pip

#35

Post by smitty1e » Fri, Feb 05, 2021, 1:24 AM UTC

Bostonian wrote: post #34

smitty1e wrote: post #30

Earlier quoted context omitted.

Source?

I was asking. That's how people in the thread appeared to interpret it.

No: in bash, '.' means the same thing as 'source'.

Re: A Python interpreter rewritten in Rust, that can run pip

#36

Post by [deleted] » Fri, Feb 05, 2021, 1:25 AM UTC

Bostonian wrote: post #34

smitty1e wrote: post #30

Earlier quoted context omitted.

Source?

I was asking. That's how people in the thread appeared to interpret it.

[deleted]

Re: A Python interpreter rewritten in Rust, that can run pip

#37

Post by burkaman » Fri, Feb 05, 2021, 1:27 AM UTC

Bostonian wrote: post #28

cylde_frog wrote: post #2

.

A single period means is interpreted as "Why?"?

I think they edited their comment to replace whatever was there with "."

Re: A Python interpreter rewritten in Rust, that can run pip

#38

Post by sitkack » Fri, Feb 05, 2021, 1:43 AM UTC

popotamonga wrote: post #8

ransom_rs wrote: post #4

This uses [lalrpop]( https://github.com/lalrpop/lalrpop ) under the hood I believe, which is a pretty awesome parser generator library for Rust.

Nice, long go the days (20 yrs ago) i had to make a JS transpiler with lex+yacc. The pain

had to? or got to? Sounds great, please tell us more.

Re: A Python interpreter rewritten in Rust, that can run pip

#39

Post by sitkack » Fri, Feb 05, 2021, 1:48 AM UTC

ris wrote: post #23

Jasper_ wrote: post #21

Earlier quoted context omitted.

OK, I'll bite: how? They need some form of locking around Python objects accessed from multiple threads, since Python has no ownership model. Do they add a lock around each individual object?

> They need some form of locking around Python objects accessed from multiple threads, since Python has no ownership model. "Ownership models" are not a given. C++ has no "ownership model" and it doesn't lock around objects. Multi-threading users are just given the synchronization primitives and are expected to manage their own solutions. The same is true in Python: https://docs.python.org/3/library/threading.html#lo…

FreeBSD went through a similar issue back in the late 90s, early 2000s when they added pervasive multithreading into the kernel.

The GIL isn't some halting problem level thing. As you allude to, Python could definitely decide to go multithreaded and add in the requisite locks. They haven't.

I really wish that the PSF would

* Make a spec

* Break out the stdlib into a portable library, and by portable, something that can be shared across PyPy, Graal, Jython, etc.

* ??? yes

Re: A Python interpreter rewritten in Rust, that can run pip

#40

Post by uranusjr » Fri, Feb 05, 2021, 1:50 AM UTC

pansa2 wrote: post #31

ransom_rs wrote: post #4

This uses [lalrpop]( https://github.com/lalrpop/lalrpop ) under the hood I believe, which is a pretty awesome parser generator library for Rust.

> LALRPOP in fact uses LR(1) by default (though you can opt for LALR(1)), and really I hope to eventually move to something general that can handle all CFGs (like GLL, GLR, LL(*), etc). Seems overkill for a language whose grammar is LL(1)?

Although the CPython implementation contains an LL(1) parser (which is being deprecated for a new PEG parser), the grammar contains bits that are not context-free, which involved a pre-parsing step before being fed into the LL(1) parser. That structure isn’t particularly good and it’d be beneficial for a new implementation to use something else.