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
<arigato>
I thought that the fast-path could only work if l2 was a W_ListObject, but your approach might be better(?)
<cfbolz>
I think so
<arigato>
right, the creation of the W_ListObject will cost more in terms of checking the types and unwrapping them all, but that's a strategy-preserving bonus
<cfbolz>
that's the hope, at least
<cfbolz>
arigato: also, note that we would be doing it in the general setslice case anyway
<arigato>
yes
<arigato>
so in the end if you ensure that w_any is a W_ListObject you can use copy_into() again
<cfbolz>
hm, I see
<cfbolz>
ok, trying
<cfbolz>
arigato: did I tell you about my idea of implementing an unresizable variant of all list strategies, to remove one level of indirections?
<arigato>
ouch
<cfbolz>
not completely clear where to create them
<arigato>
:-)
<cfbolz>
on slicing, I suppose
<cfbolz>
and maybe list comprehensions? definitely literals
<arigato>
or on extend() from the empty strategy
<cfbolz>
hah
<cfbolz>
arigato: and if we have that, we could even think about "immutable" list strategies, for fixed sized lists that are stored in globals or on classes
<arigato>
look at all usages of copy_into() and check if it would make sense to make the copy a unresizable variant instead?
<arigato>
ah, I see
<arigato>
advanced
<cfbolz>
maybe, it feels like work ;-)
<arigato>
...and [None] * 1234 makes an unresizable variant, and the well-known hack of writing "lst *= 1" makes it unresizable...
<cfbolz>
haha
<cfbolz>
arigato: I am mainly annoyed that we have this level of indirection, and cpython doesn't ;-)
<arigato>
yes, too bad that we're more compact in many cases but not the most general case
<cfbolz>
yeah :-)
<arigato>
note that we could shave off one level of indirection in most cases
<cfbolz>
arigato: yeah, well, we could stop using resizable lists in listobject.py
<arigato>
by having an unresizable rpython list and doing the overallocation ourselves again
<cfbolz>
yeah
<cfbolz>
but then stuff like space.viewlist is annoying
<arigato>
long ago we played with the idea of GC support, I think?
<cfbolz>
how would that work?
<arigato>
have a GC array but with two lengths in it, and the smaller one is the number of really used items
<arigato>
which can grow up to the larger length
<cfbolz>
right
<cfbolz>
arigato: or I wonder about the following hack: when we call viewlist, we return the unresizable list but wrapped in a resizable struct
<cfbolz>
you are anyway not supposed to mutate the result
<arigato>
ouch, right
<arigato>
like an rpython way to say "resizable = fixed[:] but don't bother making a full copy"
<cfbolz>
yeah
<cfbolz>
more like fixed[:len]
<cfbolz>
but yes
<arigato>
there is an annotation for "SomeList which is never modified" right?
<arigato>
if so, that may be a safe enough idea
<cfbolz>
to make sure that the caller *cannot* do anything?
<cfbolz>
arigato: I suspect we can 'can never be modified', but that also means 'is fixed sized'
<fijal>
"it looks like this branch is cursed, would you like to just wipe it out of earth surface?"
<cfbolz>
fijal: in this case there's this one assert, which was always there but accidentally disabled (in the JIT). while doing kind of unrelated stuff, I noticed and enabled, and it seems broken :-/
<fijal>
heh
<cfbolz>
only on 32bit of course
<cfbolz>
so I can't easily debug locally
jcea has joined #pypy
lritter has quit [Ping timeout: 246 seconds]
Dejan has quit [Read error: Connection reset by peer]