[Feature Request] Resuscitate PyPy support #324
Comments
|
Running in the same setup/container, python 3.8 doesn't have the same issue: |
|
Huh. Oddness intensifies. For unknown reasons that are probably boring, there seems to be a discrepancy here between the standard # In the "typing" module for Python 3.9:
class ForwardRef(_Final, _root=True):
"""Internal wrapper to hold a forward reference."""
__slots__ = ('__forward_arg__', '__forward_code__',
'__forward_evaluated__', '__forward_value__',
'__forward_is_argument__', '__forward_is_class__',
'__forward_module__')
def __init__(self, arg, is_argument=True, module=None, *, is_class=False):
if not isinstance(arg, str):
raise TypeError(f"Forward reference must be a string -- got {arg!r}")
try:
code = compile(arg, '<string>', 'eval')
except SyntaxError:
raise SyntaxError(f"Forward reference must be an expression -- got {arg!r}")
self.__forward_arg__ = arg
self.__forward_code__ = code
self.__forward_evaluated__ = False
self.__forward_value__ = None
self.__forward_is_argument__ = is_argument
self.__forward_is_class__ = is_class
self.__forward_module__ = moduleMy current patch release of Python 3.9 is Python 3.9.18. That's fairly late in the Python 3.9 release cycle. I'm now suspecting that earlier patch releases of Python 3.9 (...which you're probably on, maybe?) omit the I'll tighten this up and push out a new stable beartype 0.17.2 release tonight. Until then, I sigh. 😮💨 |
leycec
changed the title
typing.ForwardRef fails to reliably define __forward_module__ under Python 3.9
This commit relaxes the assumption that *all* Python 3.9 patch releases unconditionally define the standard `typing.ForwardRef.__forward_module__` dunder attribute, resolving issue #324 kindly submitted by stone-cold typonista @jvesely (Jan Vesely). Although Python ≥ 3.9.18 definitively defines this attribute, an unknown range of older Python 3.9 patch releases fail to do so. This commit resolves this by naively pretending that *all* Python 3.9 patch releases fail to do so. Although somewhat non-ideal, it's unclear whether this attribute is ever used (i.e., set to a non-empty string) under Python 3.9. (*Rhapsodic aphrodisiac over a melodic afro!*)
**Beartype 0.17.2** nervously skitters about on thin ice. Cracks form, yet beartype 0.17.2 fails to return to shore. "What are you even doing!?", the crowd exclaims. Verily, it is best not to ask questions: ```bash pip install --upgrade beartype ``` This patch release comes courtesy these proud [GitHub Sponsors](https://github.com/sponsors/leycec), without whom @leycec's cats would currently be eating grasshoppers: * @sesco-llc (SESCO Enterprises), "The Power of Innovation in Trading": <sup>*this inspires me to get out of the house and do something*</sup> https://sescollc.com * @DylanModesitt (Dylan Modesitt), quantitative strategies energy trading associate: <sup>*...wikipedia, don't fail me now!*</sup> https://dylanmodesitt.com Thanks so much, masters of fintech. ## This Release Kinda Sucks, Huh? **Alright, alright.** You found us out already. Beartype 0.17.2 is an *extremely* minor patch release that exists purely to relax the bad assumption that *all* Python 3.9 releases unconditionally define the standard `typing.ForwardRef.__forward_module__` dunder attribute, resolving issue #324 kindly submitted by stone-cold typonista @jvesely (Jan Vesely). Although Python ≥ 3.9.18 definitively defines this attribute, an unknown range of older Python 3.9 patch releases fail to do so. Beartype 0.17.2 resolves this by naively pretending that *all* Python 3.9 releases fail to do so. Although kinda non-ideal, it's unclear whether this attribute is even used (i.e., set to a string) under Python 3.9. In fact, it's unclear whether this attribute is even used anywhere, ever. It probably will be under Python ≥ 3.13, but that's putting the proverbial cart before the horse. *Anyyyyyyway.* We now return to your regularly scheduled Python hackathon. (*Sappy haptics tickle happy tick-tock clocks!*)
beartype/beartype#324 Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
Hit circular import on pypy3 beartype/beartype#324 Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
beartype/beartype#324 Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
Hit circular import on pypy3 beartype/beartype#324 Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
|
@leycec thank you. 0.17.2 fixes the cpython3.9 issue. However, the pypy issue is still there in 0.17.2. should I open a new bug for that? |
|
...heh. PyPy, huh? Now there is a name I have not heard in a very long time. The short answer is that you probably want to conditionally avoid applying @beartype when the current Python interpreter is PyPy. Please consider boilerplate like this for the foreseeable future: # In your "{your_package}.__init__" submodule:
from platform import python_implementation
# If the current Python interpreter is *NOT* PyPy, apply @beartype.
if python_implementation() != 'PyPy': # <-- standard way to detect pypy
from beartype.claw import beartype_this_package
beartype_this_package()The long answer is... Nobody Wants to Hear This, But PyPy Kinda SucksPyPy kinda sucks. I used to be Team PyPy. Once, I was all for PyPy. In theory, PyPy sounds great. In theory, PyPy should be perfectly compatible with pure-Python packages like @beartype. Right? Sadly, that's just theory. In practice, PyPy simply doesn't work for any definition of "work." PyPy breaks compatibility with literally everything – even pure-Python packages like @beartype. A few years ago, @beartype fully supported PyPy. As @beartype grew taller, stronger, and more ribbed with muscle, however, supporting PyPy basically became impossible. The core issue is that PyPy isn't Python. PyPy is PyPy. Much like Cython or Mondo or Numba or Pyodide or whatevah, PyPy is a distinct language that only masquerades as Python. PyPy developers reading this are now attempting to burn me alive at the stake. Still, it is true. At the end of the day, PyPy's mimicry of Python is just a masquerade. It's not Python: it just looks alot like Python. PyPy fundamentally breaks compatibility with low-level public types and APIs standardized by CPython. @beartype really cares about those types and APIs... but PyPy really doesn't. I mean, PyPy should. But PyPy doesn't and PyPy probably never will. This is why nothing works under PyPy. Personally, I've never actually been able to install or run anything meaningful under PyPy – especially heavy-set ML frameworks like JAX or PyTorch. And I'm a Gentoo Linux compiler bro! We compile everything by hand in Gentoo Land. Why? Because masochists. That is the answer. But even I – an unabashed "fight me" masochist – never succeeded in getting PyPy to do anything. Personally, I strongly prefer Nuitka. Even when PyPy works, so, never? PyPy comes with significant startup costs. When performance is at a premium, I usually just want to compile to C in a CPython-compatible manner. Enter Nuitka. Unlike PyPy, it's mostly CPython-compatible. Unlike PyPy, @beartype officially supports Nuitka. Unlike PyPy, Nuitka-compiled binaries exhibit fast startups. tl;dr: just Nuitka. So, You Hate PyPy. We're Agreed. What Now?I... don't know. I'm painfully behind on the @beartype roadmap for 2024. It'd be irresponsible to devote a month or so to PyPy, when what everybody wants is deep type-checking of standard containers via I'm definitely committed to restoring PyPy support to @beartype at some point. I just don't know when that might be. If this issue attracts attention, I'll happily reprioritize this for rapid resolution. Will that happen? Dunno. Does anyone still use PyPy? Dunno. Let's see if anybody starts yelling at me. |
leycec
changed the title
typing.ForwardRef fails to reliably define __forward_module__ under Python 3.9
leycec
changed the title
Hit circular import on pypy3 beartype/beartype#324 Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
Hit circular import on pypy3 beartype/beartype#324 Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
Hit circular import on pypy3 beartype/beartype#324 Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
Hit circular import on pypy3 beartype/beartype#324 Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
Hit circular import on pypy3 beartype/beartype#324 Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
Hit circular import on pypy3 beartype/beartype#324 Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
Hit circular import on pypy3 beartype/beartype#324 Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
Hit circular import on pypy3 beartype/beartype#324 Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu> fixup beartype
Hit circular import on pypy3 beartype/beartype#324 Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu> fixup beartype
Hit circular import on pypy3 beartype/beartype#324 Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu> fixup beartype
Hit circular import on pypy3 beartype/beartype#324 Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu> fixup beartype
beartype crashes when run on the following annotated function:
with the following stack trace:
The issue appeared with beartyp-0.17.1[0], the issue doesn't manifest in beartype-0.17.0 [1].
[0] https://ci.appveyor.com/project/jvesely/psyneulink-cuda/build/job/aiafois7rd9pefx8
[1] https://ci.appveyor.com/project/jvesely/psyneulink-cuda/builds/49179845/job/8d10aojadmta8le5
The text was updated successfully, but these errors were encountered: