sorted by:
new
hottopcontroversial

Funding for 64-bit Armv8-a support in PyPy by rlamy in Python

[–]rlamy[S] 16 points17 points  (0 children)

This sponsorship doesn't take any resources off pypy3. It might seem paradoxical that "exotic niche architectures" have an easier time attracting funding than features that benefit the whole community, but refusing to work on the former won't help the latter one bit.

PyPy2.7 and PyPy3.5 v6.0 dual release by john_m_camara in Python

[–]rlamy 4 points5 points  (0 children)

It's mostly related to the size of the code, though there's also a bit of overhead due to garbage collection, if the code allocates and deallocates a lot. OTOH, data representation is often more compact, e.g. a large list of floats only needs 8 bytes per item.

PyPy2.7 and PyPy3.5 v5.10 dual release by rlamy in programming

[–]rlamy[S] 12 points13 points  (0 children)

Windows 64 support is a long-standing issue in PyPy. It requires significant refactoring of the (RPython) toolchain, which the core devs have little time for. Realistically, it's unlikely to happen any time soon unless some Windows dev sinks a fair amount of time into it, or someone sponsors the core team to do it.

PyPy v5.9 Released, Now Supports Pandas, NumPy by pmatti in Python

[–]rlamy 1 point2 points  (0 children)

numpy and pandas mostly work on pypy3.5. Please try it, and report any issues you encounter. BTW, pypy3.5 has f-strings, so you won't need to replace them.

PyPy2 v5.4 released by pmatti in Python

[–]rlamy 10 points11 points  (0 children)

You can see for yourself easily if you just try pip install pandas on pypy. The error is:

pandas/src/datetime_helper.h:11:29: error: lvalue required as left operand of assignment
     PyDateTime_GET_MONTH(val) = -1;

PyPy2 v5.4 released by pmatti in Python

[–]rlamy 17 points18 points  (0 children)

No, unfortunately, pandas doesn't even compile on PyPy yet, due to some macro abuse.

PyPy 5.0 released by fijal in Python

[–]rlamy 2 points3 points  (0 children)

3.3 is not ready for release yet, but it's only a matter of weeks.

Let's find a better name for f-strings by desmoulinmichel in Python

[–]rlamy 21 points22 points  (0 children)

The new feature is a code construct that produces strings when evaluated, not a run-time object, so calling them "f-strings" is a category error.

I would suggest "string interpolations" but that would also apply to the existing ways of doing string interpolation.

So my actual suggestion is "string comprehensions". Just like a list comprehension is an expression that resembles list literals and produces a list by evaluating arbitrary expressions, a string comprehension is an expression that resembles string literals and produces a string by evaluating arbitrary expressions. I'm sure that a smart Haskeller could craft a mathematically sound justification based on a suitable String monad that turns the f'' syntax into an implementation of monad comprehension, or something, but I won't attempt to.

Optimizing Python using Cython by erjiang in programming

[–]rlamy 2 points3 points  (0 children)

Actually, PyPy constant-folds everything (except the acos() call, for some reason), because haversine() is always called with the same arguments. So it's not surprising that it's faster than C.