cfbolz changed the topic of #pypy to: PyPy, the flexible snake (IRC logs: https://quodlibet.duckdns.org/irc/pypy/latest.log.html#irc-end ) | use cffi for calling C | if a pep adds a mere 25-30 [C-API] functions or so, it's a drop in the ocean (cough) - Armin
jcea has joined #pypy
dmalcolm has joined #pypy
jvesely has quit [Quit: jvesely]
jvesely has joined #pypy
jvesely has quit [Client Quit]
jvesely has joined #pypy
dddddd has quit [Remote host closed the connection]
jvesely has quit [Quit: jvesely]
jvesely has joined #pypy
created has joined #pypy
<created>
Hi
jvesely has quit [Client Quit]
<created>
Something that's nice in javascript and - so far - I wasn't able to approximate in python/pypy:
jvesely has joined #pypy
jvesely has quit [Client Quit]
<nedbat>
created: we're all waiting with bated breath
<created>
In javascript, you can write a zero-cost transpiler from some other dynamic language by prefixing all member accesses with some unique prefix and adding methods from the source language - with that unique prefix - to the builtin types' prototypes
<created>
This isn't pretty and pollutes the prototypes, but that's no a problem if you pick a unique enough prefix and it does achieve zero-cost transpiling
<nedbat>
created: i don't understand how this accomplishes transpiling?
<created>
(E.g. a.b may get transpiled to a.my_unique_prefix_b, and methods with names beginning with "my_unique_prefix_" may be added to builtin types like number/string
<created>
nedbat - it doesn't accomplishes by itself of course, but it helps make it zero-cost
<nedbat>
created: and what in python is getting in the way of that?
<created>
Without this ability, as far as I can tell, you would have to transpile all method accesses to something like my_wrapper(a).b
<created>
Where my_wrapper would check the type of a and wrap it if it's a built-in type
<created>
nedbat - oh, the "ability" missing from python is adding methods to builtin types
<created>
And yeah, usually it's a good thing, not being able to do that (though js programmers may disagree)
<created>
But in this particular case, the lack of ability seems to prevent zero-cost transpiling
<created>
I suppose with pypy, the my_wrapper won't cost too much, though, hopefully
<created>
Especally if it does only a single check to separate builtins from non-builtins
<created>
My question is, really - is there a better way to accomplish this in python?
<ammar2>
why do you think this is "zero-cost" in javascript?
nimaje has joined #pypy
<ammar2>
there is likely a cost associated with modifying the builtin type's protos
<created>
ammar2 - because method access goes to method access. I'm talking about cost of access of regular user-defined properties
<created>
ammar2 - I'm talking about cost of method access, which happens many OOMs more frequently than modifying the builtin type's protos and maybe calling the wrapped builtin functions
<created>
(OOM - order of magnitude)
<created>
(Correction: It's only zero-cost for accessing non-builtin properties, and hopefully-minimal-cost for accessing builtin properties)
<created>
That said, perhaps the my_wrapper can be jitted away by pypy, that's the sorta thing it does well, I think
<created>
(It would help if there was a working recommended way to measure things on pypy)
<created>
(timeit is giving suspecious results, even for a microbenchmark where I don't care about jit warmup)
<created>
(And there is no perf module)
<created>
Even with pyperf, no matter what I do, I can only get meaningless-seeming results unless I use a "c" api like what I assume math.floor (and thus is_number) delegates to.
<created>
Even if I read/write globals for the calculation being profiled, so either pypy optimizes those aways too, or something else is preventing pyperf/timeit from giving accurate results
<created>
Okay, reading/writing to the SAME global seems to help get more reasonable results
<created>
Or maybe not, just differently questionable results....
jvesely has joined #pypy
<created>
Alternatively, maybe pypy is really that good at eliding all this code
<arigato>
created: pypy is indeed very good at removing nonsense code, so dummy microbenchmarks are pointless
<arigato>
about the fastest way to add "methods" to built-in types with pypy: I guess it depends on the usage patterns
<arigato>
I wouldn't know a priori what the fastest way is, so you really need to try out several variations in real-looking code
<arigato>
as long as you follow a few rules, all the cruft should be removed by the JIT, but at some cost to the JIT itself (if the JIT removes too much cruft everywhere, then it will tend to not inline anything because it all looks too long before simplification)
Dejan has joined #pypy
oberstet has joined #pypy
junna has quit [Ping timeout: 268 seconds]
junna has joined #pypy
junna has quit [Ping timeout: 250 seconds]
lritter has joined #pypy
junna has joined #pypy
junna has quit [Ping timeout: 265 seconds]
jcea has joined #pypy
jcea has quit [Remote host closed the connection]
jcea has joined #pypy
Rhy0lite has joined #pypy
junna has joined #pypy
marky1991 has joined #pypy
junna has quit [Ping timeout: 240 seconds]
marky1991 has quit [Remote host closed the connection]
marky1991 has joined #pypy
jvesely has joined #pypy
marky1991 has quit [Remote host closed the connection]
marky1991 has joined #pypy
junna has joined #pypy
marky1991 has quit [Ping timeout: 276 seconds]
junna has quit [Ping timeout: 268 seconds]
jvesely has quit [Quit: jvesely]
adamholmberg has joined #pypy
adamholmberg has quit [Remote host closed the connection]
<kenaan>
mattip default 38dd5be2287d /.hgtags: Added tag release-pypy2.7-v7.3.0rc1 for changeset e6471221abc1
<kenaan>
mattip release-pypy3.6-v7.x 533398cfd64e /lib-python/3/: merge py3.6 into release
<kenaan>
mattip default 86951c9b1898 /.hgtags: Added tag release-pypy3.6-v7.3.0rc1 for changeset 533398cfd64e