<mattip> Joannah wrote a proposal for a different interface for objects based on work for a gc for CPython
computerfarmer has joined #hpy
<antocuni> it seems to me that what she describes is *exactly* hpy's handles :)
<cfbolz> Except that they are allocated more cheaply by using a bump pointer like approach
<cfbolz> But I think the proposal is not fleshed out enough to really understand the details
<antocuni> I mean, HPy handles are generic enough that they can be implemented in multiple ways, including the one proposed by Joannah, if I understand correctly what she proposes
<cfbolz> antocuni: right
<cfbolz> Yes that's plausible
<antocuni> but hpy handles are better designed, IMHO. To start with, by wrapping the int inside a struct you get a compile time error if you try to compare two handles with ==
<antocuni> moreover, the unanswered question of Joannah's proposal is what to do with PyObject* fields inside structs
<cfbolz> antocuni: many unanswered questions
<antocuni> true
jboi has quit [Remote host closed the connection]
jevinskie[m] has quit [Remote host closed the connection]
jboi has joined #hpy
jevinskie[m] has joined #hpy
computerfarmer has quit [Quit: Konversation terminated!]
ronan__ has joined #hpy
ronan has quit [Ping timeout: 264 seconds]
ronan__ is now known as ronan
<antocuni> I just opened a PR: https://github.com/hpyproject/hpy/pull/212
<antocuni> it adds a doc page which documents the real world usage of the CPython APIs to build bytes/unicode objects
<antocuni> once the PR is merged, I'll open a proper issue to discuss possible API designs for a HPyBytesBuilder and HPyStrBuilder (or HPyUnicodeBuilder)