Think about the name and a naming convention

[antocuni]

I called it pyhandle for now, but we might want a better name. We surely need a reasonable calling convention: I suggest that the new API calls should not start with Py, to make it easier to distinguish the new and the old ones.

Let's take PyObject_GetAttr as an example; some random ideas for the new name:

• PyHandle_GetAttr: this starts with Py, probably not a good idea

• PHandle_GetAttr: no more Py :)

• NPyObject_GetAttr: NPy stands for "New Python", but might be confused with numpy

• NPy_GetAttr: if we want to kill the distinction between the object protocol, number procotol etc, we might want this

• BPyObject_GetAttr: "Better Python"; hard to pronunce

• YpObject_GetAttr: I like the joke of being a "reversed Py", not sure I like the pronunciation though :)

I'd like to hear new ideas

[vstinner]

Another idea:

• Add "H" to Py" to get HPy prefix: HPyLong_FromLong(), HPyString_FromString()

[antocuni]

Good idea, HPy is my favorite one so far

[windelbouwman]

Thanks for starting this innitiative! It would indeed be useful for python implementations not to be forced down the cpyext road (which is impressive, but also mind-melting :D).

My ideas for naming this project:

• new-py-api -> obviously not a good name, since it will soon be superceeded by new-py-api-2
• Simply py-api or PyApi without the C. It would signify an api to python, which is not tied to CPython.
• PyExtensionApi, to indicate the API is intended for usage by python extension developers.

Another idea might be to split the API into groups (which could be namespaces in C++ for example). I cannot think of logical groups of functions, but it makes sense to group them, and add maturity levels to the seperate groups.

[pmp-p]

Other ideas:

ApiValley ! ( be happy with that api or hang by the neck until you do )

Pi* for Python Interface ( i like short like Yp* )

also ApiCircus in case ApiValley is not possible since it can't fly yet but surely will

ref to happy valley : youtube.com/watch?v=o0LUUFQ4MNM

[antocuni]

Thanks for the suggestions!
However, I think that the naming of the project should derive from a reasonable prefix/naming convention which looks nice in C: the visual appearance of the API plays a role in the way people will see it.
So, PyApi, ApiValley, PyExtensionsApi etc. are not valid names because they are either too long or they starts with Py (which is a bad idea because it causes confusion with the existing one).

So far HPy is winning and we are using it for the first draft/code examples; it is short, sufficiently different from Py and also easy to pronounce. It could stand for "handles for python" but also e.g. for "higher python" :). I am starting to liking it!

[pmp-p]

you're welcome

i like HPy too it's still short , but for finding the name it sure will be a ApiThon ( that one is dedicated to @vstinner ;) )

[antocuni]

HandlePy: the project which handles Python and brings it to the future :)

[windelbouwman]

HPy seems reasonable to me!

Minor note: It also seems a bit arbitrary to me, to name it after the usage of handles, which is an implementation detail of the API. The whole point of this idea is hiding implementation details right?

Agreed that names starting with Py are too confusing.

Other ideas:

• XPy -> just a random letter + Py
• APY -> API, spelled in a pythonic way.
• YPY -> Nicely reversable prefix.

[antocuni]

Minor note: It also seems a bit arbitrary to me, to name it after the usage of handles, which is an implementation detail of the API. The whole point of this idea is hiding implementation details right?

I think it's the opposite: a handle is a fully opaque thing, so it is the most abstract way of representing an object. Unless you object that having a way to referencing objects with a C variable is an implementation detail :)

Anyway, I renamed the repo to pyhandle/hpy and updated the README, so I think that this is going to be the official name of the project from now on.

I couldn't rename the organization to hpy because the username is already taken, but I don't think it's too bad

[windelbouwman]

Another idea for a name: PAPI (python API). Easy to pronounce. Reasonable short, in line with PyPI (fully unrelated, but still).

[arigo]

How about PODs: Python Object Descriptors. From the file descriptor analogy?  It gives a reasonable prefix for all functions and types, like POD_Add().

[antocuni]

Closing it again. It seems HPy has won since we have been writing lots of code already :)