Naming of async variants

Django Internals Async
1

Hi y’all :wave:,

First off, sorry for bikeshedding :biking_man:. I would like to start (hopefully :crossed_fingers:) short discussion about naming async variants of methods and functions in the Django. We have patches waiting for reviews so it’s about time to make the final decision. Please focus on these three:

  1. "_async" prefix,
  2. "_async" suffix (mentioned in the DEP 9),
  3. "a" prefix (consistent with Python :snake:, e.g. __aiter__, __anext__, __aenter__, __aexit__ etc.)

The second option should be preferred as it’s mentioned in the DEP. However, the 3rd option has a big plus as it introduces API consistent with Python internals and I don’t see anything wrong in aget(), aset(), aiter(), or atouch().

Best,
Mariusz

2 Likes
2

Personally love option 3 from a syntax point of view.

1 Like
3

Hey @felixxm — Since this is your first post to the forum, let me say Welcome! :grinning:

I think we should ping @andrewgodwin to ask for his input, because there’s little point us having a conservation without him.

Thanks for raising this. :+1:

1 Like
4

I have come around on the a prefix; initially I was thinking .a.get() and so forth, but honestly I absolutely agree with idea number 3 here and think .aget() and kin are a great idea, and do directly match Python.

4 Likes
5

I think that’s several votes for the a prefix. (You preferred it right @felixxm?)

Do we need to update the DEP? Do we need anything formal for that? (I never know, think we do, and then feel it shouldn’t be such that it’s a barrier to progress, so suspect that we don’t…:exploding_head:)

6

Yes, absolutely.

IMO, we don’t need to increase bureaucracy :writing_hand:. We’ve reached a consensus :heavy_check_mark:, so I can point folks to this discussion.

Thanks y’all :medal_sports:

4 Likes