
Improving SyntaxError in PyPy - mattip
https://morepypy.blogspot.com/2018/04/improving-syntaxerror-in-pypy.html
======
xapata
Great ideas that should be backported into CPython. Especially the message
when forgetting the colon!

------
bratao
PyPy is a very underrated project. I really pray that after the C-extensions
improvements that the upcoming versions brings, a major wave of adoptions
come.

~~~
chubot
I've been programming in Python for 15 years and I've known about PyPy for at
least 10, and still haven't really found a reason to use it.

Part of it is because I don't choose what interpreter we use at work. At home,
I just use CPython and it works fine for everything.

But I recently started learning more about PyPy, and it's technically crazy
and ahead of its time [1]. It started in 2003 and I think something else like
it didn't appear for more than 10 years [2], and is still research while PyPy
is used in production.

So yeah it is hugely impressive, from a technical standpoint. But I see that
there's not enough "carrot" to pay the cost of adoption, for most users. It's
faster for some workloads, but predicting the speedup is nontrivial. And it
also uses more memory.

It's unfortunate that the Python/C API is so complex and the extension
ecosystem is so fragmented with wrappers as a result (SWIG, ctypes, cffi,
etc.). I think there is a network effect with CPython that is very hard to
break.

Everyone builds for CPython because it already has a large amount of useful C
code in its ecosystem -- not to mention stuff like NumPy, Pandas, etc. which
are a mix of C and Cython, Cython being a totally separate effort to write
"faster Python".

[1] [https://llvm.org/pubs/2006-10-DLS-
PyPy.html](https://llvm.org/pubs/2006-10-DLS-PyPy.html)

[2] Graal and Truffle seems like the closest thing, i.e. a meta-tracing JIT
where you get a "JIT for free": [https://blog.plan99.net/graal-
truffle-134d8f28fb69](https://blog.plan99.net/graal-truffle-134d8f28fb69)

[http://tratt.net/laurie/research/pubs/html/bolz_tratt__the_i...](http://tratt.net/laurie/research/pubs/html/bolz_tratt__the_impact_of_metatracing_on_vm_design_and_implementation/)

~~~
daveFNbuck
At work, I use PyPy to run a Luigi server for our data pipeline. It gave us a
pretty dramatic decrease in latency and allowed us to scale our workload with
a trivial change. It's unfortunate you can't choose your interpreter, but when
you can it's pretty easy to just test both and see which one is faster.

I also use it at home to solve Project Euler problems. For anything that takes
more than half a second or so, it's usually a big win and can turn minutes
into seconds.

~~~
Myrmornis
Do any of the Project Euler questions actually require lengthy computation, or
is that more a sign that one should be looking for some mathematical insight
that leads to a more efficient computation?

~~~
xapata
PyPy won't change your data structures and algorithms, so it's not finding
mathematical insight.

~~~
Myrmornis
Yes that’s the point I was making. Maybe you intended your comment to be a
sibling to mine.

~~~
daveFNbuck
It seems that you're saying that I should be finding mathematical insight
instead of using PyPy, while xapata is saying that if my code runs fast in
PyPy then I've already found enough mathematical insight.

------
DonbunEf7
Excellent! It hadn't occurred to me before that PyPy's parser error messages
could be different from CPython's; I must have forgotten that they rewrote the
parser [0].

[0] [https://morepypy.blogspot.com/2009/08/pypy-gets-new-
compiler...](https://morepypy.blogspot.com/2009/08/pypy-gets-new-
compiler_25.html)

------
askvictor
I have had similar experiences teaching python; the error messages take a
while to be able to decode. One idea I've had is to write an exception handler
or wrapper that catches all exceptions and tries to display them in a more
beginner friendly way (more human, and with some possible hints to how to
fix). Unfortunately never had time to implement it among the actual teaching.
This enhancement is a good start, but could be a bit better still with
simpler/less technical language. Other common (runtime) errors (e.g.
IndexError, TypeError) would also be a good target for this approach.

~~~
Myrmornis
That does seem like a good and totally doable idea.

------
sigmonsays
i'm still waiting for a 100% compatible pypy implementation. People will not
switch if "python" can't run on it. Like it or not, but CPython is the
standard python.

Anyone know where unladen swallow ended up?

I feel like the improved python interpreter is a pipe dream, but this is
coming from someone who has long moved on from python to go due to pythons
scaling troubles ( in my unique environment)

~~~
wyldfire
> People will not switch if "python" can't run on it.

For my use, it's been remarkably close to CPython. Where does it fall short
for you?

I think it's a design goal to match CPython behavior, so I think it would be
rare if they were to NOFIX a doesnt-match-CPython bug.

If you're writing anything other than I/O bound code in pure python, you're
probably doing it wrong. Write an extension in C or rust for the inner loops
and their critical data structures, and keep everything else in python.

~~~
bastawhiz
In my experience, as someone who runs a fairly hefty Python application, the
biggest source of incompatibility is the C extensions. One that's a thorn in
my side is psycopg2. There's a version that works with cffi, but then you're
crossing your fingers hoping that it matches the main psycopg2 package in
terms of functionality and security updates.

I would gladly throw money at someone to figure out how to take the juicy
compat bits from Pyston and bring them into Pypy.

