I think I might have confused things further, my apologies. I see 3 related but
distinct feature requests here:
1) Allow a directory to be a resource in and of itself, and provide APIs for
working with "directory-type" resources.
2) Allow resources with "/" in the name, and provide APIs to
Non-"binary" resources are already in widespread use, so perhaps that
requirement shouldn't be in the docs at all. In practice, a resource is "any
data file other than a Python source file."
Moreover, I see no reason why a resource name in general shouldn't be allowed
to contain a "/" character
I think this is a bit of an "XY" feature request.
Currently, resources must be individual files inside a package. A directory
cannot itself be a "resource". So for example if you have a directory structure
like this:
my_great_app/
__init__.py
something.py
data/
ass
The generally-accepted solution for this task is to set an Event, rather than
just returning a Boolean:
def move_to(dest, done_event):
...
done_event.set()
async def main():
dest = ...
done_event = asyncio.Event()
create_task(move_to(dest, done_eve
>From a "hobbyist / programming aesthete" perspective, I think this is a great
>idea. I think pattern matching in ML-descended languages is wonderfully
>elegant. Packing and unpacking tuples is already a common syntactic idiom in
>Python, and now that we have Structural Pattern Matching (SPM), i
file() would pass along its kwargs to open(), and the user could
use lambda, partial, or write a utility function to customize the loader itself.
If we are really really leery of adding a new top-level builtin, you could
namespace it under a "loadfile" module:
from loadfile import lo
You can also use typing.cast for the handful of cases where your particular
type checker (e.g. MyPy) fails to refine the type properly in a case like the
following:
def lookup_usernames(db, user_ids: Optional[List[int]] = None) -> List[str]:
if user_ids is None:
return []
