cfbolz changed the topic of #pypy to: PyPy, the flexible snake (IRC logs: https://botbot.me/freenode/pypy/ ) | use cffi for calling C | the secret reason for us trying to get PyPy users: to test the JIT well enough that we're somewhat confident about it
<njs>
dfee: I don't think there is a way right now, but if you raise it as an issue on the distutils-sig mailing list or https://github.com/pypa/packaging-problems/issues/ then it increases the chance that it will get fixed
<njs>
(there are some other limitations that people have run into with python_requires, like the awkwardness in Rotonen's example, so hopefully it will get extended at some point, and if your issue has been raised publically then it increases the chance that it'll get taken into account if/when that happen)
<dfee>
njs: do you know if there is a way to specify python3.6+ but not prevent installation on pypy6.0.0? setup_requires seems to
<dfee>
Rotonen: thanks, let me check that out
<njs>
dfee: I don't know of a way
<dfee>
Rotonen: unfortunately, z.i doesn't specify pypy vs cpython :(
<dfee>
it's kinda hacky, but i wonder if i could detect that the interpreter is PyPy and adjsut the requirements from there (i.e. downgrade to 3.5)
<njs>
dfee: not in a wheel
<njs>
dfee: though you could python_requires: >= 3.5, and then at import time error out if you discover you're on cpython 3.5
<dfee>
njs: i'm still not clear on what a wheel is.
<dfee>
is it just defining the package through setup.cfg rather than setup.py?
<njs>
there are two standard ways to distribute a python package. Option A is as an "sdist" (= "source distribution"), which is a tarball of your source tree, including a setup.py file, and you run the setup.py file to build it, or get metadata, or do anything with it really
<njs>
and Option B is as a "wheel", which is a pre-built version of your package, with static metadata in some specific format and a bunch of files that just get dropped at appropriate places in your system, no setup.py involved at all
<dfee>
ok
<njs>
the distinction is most important for packages that have complicated build processes, binary extensions, etc., but it still makes sense for pure python packages too
<dfee>
i wonder if i should just not support pypy then until it gains py36 compatibility. it's a bummer, but i don't know of any other way
<dfee>
this is a fairly trivial installation: no dependencies, but it does have complexity in requiring ordered dicts.
<dfee>
"insertion ordered" dicts
<njs>
dfee: do you expect that there will be people trying to install it on cpython 3.5 and getting frustrated, or...?
<dfee>
njs: yeah, i can imagine that happening.
[Arfrever] has quit [Ping timeout: 264 seconds]
<dfee>
i'm trying to support pypy, but the package is really 3.6+ due to the "insertion ordered" dicts requirement
jacob22__ is now known as jacob22
<dstufft>
well
<dstufft>
you can produce a wheel that's good for pypy6+
<dstufft>
and a wheel that's good for any Python implementation 3.6+
<dfee>
dstufft: again, i'm sort of lacking in knowledge here, but that'd be idea
<dfee>
*ideal
<dstufft>
and a sdist that's good for only 3.6?
<njs>
dstufft: oh heh sneaky
<dfee>
oh jeez, is the sdist recipe necessary then?
<njs>
dstufft: is there in fact a platform tag that means "pypy 6+"? I remember pip/wheel have some weird hacks around pypy platform tags...
<dstufft>
well producing a sdist is good hygiene, it's not mandatory but downstream redistributors will generally want you to produce them
<dstufft>
njs: I don't remember TBH
<dstufft>
this is mostly just a random sketch of how it could work
<dstufft>
not a fully fledged plan
<dstufft>
unfortunately making it work is probably going to require a bit of effort, because it's an esoteric enough want that none of the tooling is designed for it, so you're going off the beaten path
<njs>
dstufft: I guess if you want to be really clever it could even be a single wheel like: somepkg-1.0-py35.pp6-none-any.whl
<dfee>
and of course jenkins doesn't support pypy6.0.0 so there'll be no testing for it.
<njs>
dstufft: also a lot of tooling doesn't look at the metadata inside the wheel so just renaming the file is often enough to fool things...
<dfee>
maybe i just do an sdist and check sys.version_info?
<dstufft>
Hmm
<dstufft>
simpler idea:
<dstufft>
well first
<dstufft>
dfee: has any version of this library ever supported 3.5+?
<dstufft>
er
<dstufft>
<3.6
<dstufft>
I mean
<dfee>
dstufft: nothing that's been released on pypi
<dfee>
so, no public customers of the code
<dstufft>
dfee: Ok, so easiest thing, produce a wheel that's 3.6+, produce a sdist that works for anything, and check sys.version_info in setup.py and error out if it's not supported
<dstufft>
a 3.6+ Python will get the wheel, which is the happy case for installs (faster, etc)
<dstufft>
something like PyPy 6 would get the sdist, and work cuz your setup.py code would allow it
<dstufft>
Something like CPython 3.5 or even 2.7 would get the sdist and fail, cuz your setup.py code wouldn't allow it
<dstufft>
does that make sense?
<dfee>
dstufft: i'll need to learn how to build the wheel, but that sounds reasonable.
<dfee>
dstufft: unfortunately, sys.version_info doesn't seem to report that the interpreter is pypy
<dfee>
all the other options are defined in the setup.cfg file
[Arfrever] has joined #pypy
<dfee>
if this works, is there a benefit to doing a wheel or is that just extra overhead?
<dstufft>
dfee: wheels install faster
<dfee>
of course platform.python_version_information returns strings, not ints... ugh. can i trust that they'll actually remain str-cast ints? https://paste.ofcode.org/bAp4BHTtKaW355dmPNyWRF
jcea has quit [Quit: jcea]
<njs>
dfee: just use sys.version_info
<dfee>
njs: thanks
<Rotonen>
sounds like pypy would need to poke the setuptools folks to add pypy_version (or have one of those available pypy-only and tell packagers to conditionally inject that in at setup.py runtime)
<Rotonen>
like one can already do platform specific trickery
exarkun has quit [Read error: Connection reset by peer]
antocuni has joined #pypy
marky1991 has joined #pypy
exarkun has joined #pypy
mcyprian has quit [Ping timeout: 260 seconds]
mcyprian has joined #pypy
jcea has quit [Remote host closed the connection]
jcea has joined #pypy
kenaan has joined #pypy
<kenaan>
antocuni gc-disable a75d8c7f141f /rpython/translator/goal/gcbench.py: add an option to control how the gc works inside gcbench: you can choose whether to use gc.disable() and/or g...
<kenaan>
antocuni gc-disable 91902e174491 /pypy/module/gc/: the app-level gc.{enable,disable} now call also the rgc equivalent, to actually disable major collections
<cfbolz>
RemoteFox: that's a fairly internal operation. maybe it got removed in some refactoring? why?
commandoline has quit [Ping timeout: 245 seconds]
commandoline has joined #pypy
<fijal>
cfbolz: I like your euphemism for "really really obscure"
jcea has quit [Remote host closed the connection]
awygle is now known as aygle
marky1991 has quit [Remote host closed the connection]
marky1991 has joined #pypy
aygle is now known as awygle
marky1991 has quit [Remote host closed the connection]
marky1991 has joined #pypy
kcr has quit []
kcr has joined #pypy
marky1991 has quit [Remote host closed the connection]
marky1991_2 has joined #pypy
SunDwarf is now known as Guest52326
_habnabit is now known as Guest67145
mwhudson is now known as Guest32565
graingert is now known as Guest25333
tito is now known as Guest31483
ionelmc is now known as Guest55264
phlebas is now known as Guest87736
tos9 is now known as Guest20026
nedbat is now known as Guest74655
bjs is now known as Guest2337
danchr is now known as Guest51510
ronny is now known as Guest36932
Guest74655 is now known as nedbat
dfee has joined #pypy
<dfee>
can i count on `a` to be less than `b` in this psuedocode? {'a': nextval(), 'b': nextval()}. i'm not clear what happens at the AST level
<RemoteFox>
cfbolz: I am writing interpreter and I have object memory layout of my language, where there are something like classes (maps, it is a prototype based OOP), and instances of objects points to this map, and I think I need a reference from map back to objects
<RemoteFox>
so that when map change, I am able to change also all instances
<RemoteFox>
and I thought that I will use weakrefs from maps to objects, so I won't prevent GC collecting them
marky1991_2 has quit [Ping timeout: 264 seconds]
<RemoteFox>
cast_object_to_weakaddress is mentioned in the rpython documentation
<RemoteFox>
but I've found, that it is not present anymore
<RemoteFox>
I've found rweaklist, but I don't know if I can use that
<redj>
_habnabit: I'm sorry it's a bit messy, I'm preparing another gist
<_habnabit>
aw jeez why would you crosspost into #pypy
<redj>
sorry, that ^^ was for ronny and RemoteFox
<redj>
_habnabit: I'm sorry, where should I post?
<_habnabit>
redj, well, probably not #pypy, but definitely not crossposting
<redj>
_habnabit: won't happen again
<ronny>
redj: you might want to gi #pypa
<RemoteFox>
cfbolz: any other trick? maybe scanning of all "instances" using given map, via the gc?
<cfbolz>
No, sorry
<cfbolz>
Why do you need to do that anyway?
<redj>
ronny: thanks
<cfbolz>
PyPy is using maps too, and we don't update all instances either
<dfee>
i just relaized that in order to support < py3.5 i have to figure out how to pull my type annotations out of my code. ugh.
<RemoteFox>
cfbolz: I don't know whether this make sense in class-based languages, but my language (inspired by Self), you may add or remove slots from the map, and I supposed that I would want to update all instances using that map
<cfbolz>
RemoteFox: what's the value of the newly added slot? Some default?
<RemoteFox>
Nil
<RemoteFox>
so, yeah
<cfbolz>
Then you don't need to store that into every instance, but do it lazily when you touch that field the next time
<RemoteFox>
ok, I will try that
<RemoteFox>
thanks
ciphergoth has joined #pypy
ciphergoth has quit [Remote host closed the connection]