The Array and Group classes have methods that are synchronous, but many of these methods rely on async code. To solve this problem, the Array and Group classes have _async_array and _async_group attributes respectively. To use Array as an example, the Array._async_array attribute is an AsyncArray that actually does all of the IO, and so many Array methods just wrap a synchronized invocation of the corresponding AsyncArray invocation.
An alternative would be a single class with a mix of sync and async methods, where the sync form invokes the async form within a blocking function.
My question for this issue is whether we like our current design with two classes. Do people find it intuitive, etc?
I'm not arguing for changing anything, but I will note that I experience a mild distaste when I look up the implementation of an array method and find that it's actually just wrapping a method defined in a completely different class, which I must then look up to figure out what's really going on. The Array class has just 1 attribute, _async_array, which does all the work.
I'm not aware of a "synchronized layer above async layer" solution that doesn't involve extensive wrapping (if someone knows of one please share it!), but from a discoverability standpoint, Array._get_selection wrapping Array._a_get_selection seems a bit better than Array._get_selection wrapping AsyncArray._get_selection, especially if, in the first case, the sync and async methods are defined right next to each other in the source code.
The
ArrayandGroupclasses have methods that are synchronous, but many of these methods rely on async code. To solve this problem, theArrayandGroupclasses have_async_arrayand_async_groupattributes respectively. To useArrayas an example, theArray._async_arrayattribute is anAsyncArraythat actually does all of the IO, and so manyArraymethods just wrap a synchronized invocation of the correspondingAsyncArrayinvocation.An alternative would be a single class with a mix of sync and async methods, where the sync form invokes the async form within a blocking function.
My question for this issue is whether we like our current design with two classes. Do people find it intuitive, etc?
I'm not arguing for changing anything, but I will note that I experience a mild distaste when I look up the implementation of an array method and find that it's actually just wrapping a method defined in a completely different class, which I must then look up to figure out what's really going on. The
Arrayclass has just 1 attribute,_async_array, which does all the work.I'm not aware of a "synchronized layer above async layer" solution that doesn't involve extensive wrapping (if someone knows of one please share it!), but from a discoverability standpoint,
Array._get_selectionwrappingArray._a_get_selectionseems a bit better thanArray._get_selectionwrappingAsyncArray._get_selection, especially if, in the first case, the sync and async methods are defined right next to each other in the source code.