[Python-ideas] Re: `importlib.resources` access whole directories as resources
On 16/05/22 5:05 pm, Christopher Barker wrote: a directory is not a binary artifact -- it can't have actually data in it like a file can. and: the entire point of resources is to provide an abstraction -- the individual resources may not be files on disk at all These two statements are contradictory. If a resource is an abstraction, why can't it be represented by a collection of files in a directory rather than a single file? -- Greg ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/BATVPGYYGZJX3IJCMVGAV54J3GVXFUS2/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: `importlib.resources` access whole directories as resources
I honestly wasn't aware that this was added in 3.7 -- I always thought handling resources was up to setuptools or hand-written code. So it's nice to see that it's there in the stdlib. And while I haven't actually used this feature, I have read through the docs and have a few comments. On Sun, May 15, 2022 at 7:21 AM Greg Werbin wrote: > Currently, resources must be individual files inside a package. A > directory cannot itself be a "resource". According to the docs, " a *resource* is a binary artifact that is shipped within a package." a directory is not a binary artifact -- it can't have actually data in it like a file can. So I'm not sure how it wouel make sense for a directory to be a resource. > my_great_app/ > __init__.py > something.py > data/ > assets/ > images/ > a.png > a.png > c.png > > Each of data/ assets/ and images/ must also be a package, with its own > __init__.py file. You cannot access the resource data/assets/images/a.png > in the package my_great_app, you must access the resource a.png in the > package my_great_app.data.assets.images. This is (in my opinion) > unintuitive, easy to forget, and moderately annoying. > It doesn't seem that bad to me -- my thoughts is that if you have that much structure to your resources, maybe the resource system is not the right tool for the job. nevertheless ... > Alternatively, if for some reason directories cannot themselves be > resources, allowing file resources in subdirectories (without creating a > new subpackage) would also be a nice ergonomic improvement. > That might be possible, and would make sense to me. However, the entire point of resources is to provide an abstraction -- the individual resources may not be files on disk at all -- so extending the nested path concpet may not make sense. That being said, I also note that importlib.abc.ResourceReader is an ABC -- so I think you could very well make your own ResourceReader that could traverse a directory hierarchy if you wanted to. """ And the contents() method is defined as: Returns an iterable of strings over the contents of the package. Do note that it is not required that all names returned by the iterator be actual resources, e.g. it is acceptable to return names for which is_resource() would be false. Allowing non-resource names to be returned is to allow for situations where how a package and its resources are stored are known a priori and the non-resource names would be useful. For instance, returning subdirectory names is allowed so that when it is known that the package and resources are stored on the file system then those subdirectory names can be used directly. """ which implies to me that the system is expected to optionally handle subdirs. Perhaps you can write a ResourceResader that meets your needs, and it turns out to be generally useful, it could be later added to the stslib. -CHB -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/7QTDMP6CASWOA7HQ3PWKZGSQOUMPQ4GO/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Time to relax some restrictions on the walrus operator?
I'm sorry Steven, I didn't mean to denigrate your examples. Please note that I said I was in favour of relaxing the restrictions on the walrus operator. I guess I just meant that using the walrus operator generally adds extra complexity to code and means that more effort is required to read and understand it. Or, at least, its use often results in fewer lines of code (whether or not that was the primary motive) which means that particular lines of code become more complicated and harder to understand. I try (so far fairly successfully I think 😁) to resist the temptation to use the walrus operator just to save a line of code. (Isn't it "Pythonic" to do one thing and one thing only on each line of code? I'm sure I read that somewhere.) I try to only use the walrus when performance matters and I think (or know, from testing) that it will improve performance by avoiding re-evaluating an expression. Or, possibly, when there is some other compelling reason (sorry, can't think of an example offhand). Best wishes Rob Cliffe On 08/05/2022 17:38, Steven D'Aprano wrote: On Sun, May 08, 2022 at 04:00:47PM +0100, Rob Cliffe wrote: Yes, I know unrestricted use of the walrus can lead to obfuscated code (and some of Steven's examples below might be cited as instances 😁). They're intended as the simplest, least obfuscatory examples of using the walrus operator that is not pointless. That is, an example of the walrus as a sub-expression embedded inside another expression. If you think my examples are obfuscated, then that is an argument in favour of keeping the status quo. I could have given an example like this: ((a, b) := [1, 2]) but there is no good reason to use the walrus operator there, it is not a sub-expression, and it Just Works if you use the assignment statement instead. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/7T5AFGK7MAIFHX4H2VSSZ4MQARKCX2Y2/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Awaiting until a condition is met
On 2022-05-16 00:47, Steven D'Aprano wrote: On Sun, May 15, 2022 at 03:34:15PM +0100, MRAB wrote: On 2022-05-15 03:10, Aaron Fink wrote: >Hello. > >I've been thinking it would be nice to be able to use await to suspend >execution until a condition is met (as represented by a function or >lambda which returns a boolean. [...] It's still just polling, so it could be expensive to check very often. All the callback is returning is True/False, which isn't very helpful for deciding how often it should check. https://www.youtube.com/watch?v=18AzodTPG5U Exactly. Now imagine that happening 60 times a second! ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/AOKD57X3FKOGPIBSIGKOSXYKB25STXEE/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Awaiting until a condition is met
On Sun, May 15, 2022 at 03:34:15PM +0100, MRAB wrote: > On 2022-05-15 03:10, Aaron Fink wrote: > >Hello. > > > >I've been thinking it would be nice to be able to use await to suspend > >execution until a condition is met (as represented by a function or > >lambda which returns a boolean. [...] > It's still just polling, so it could be expensive to check very often. > All the callback is returning is True/False, which isn't very helpful > for deciding how often it should check. https://www.youtube.com/watch?v=18AzodTPG5U -- Steve ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/5WKGELADXCYMD5VAIGM33IP63RVDSCEY/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Improving -x switch on CLI interface
On Sun, May 15, 2022 at 07:32:56PM -0300, Rafael Nunes wrote: > Hi. Thanks for asking. > In .BAT files we could write some Windows Shell commands before python code > and python interpreter would ignore them. Hi Rafael, You have answered Eric's question with *what* you would do (write Windows Shell commands in a .BAT file) but a use-case is *why* you would do it. What sort of real-world problems are you solving by turning a .py file into a .bat file with Windows shell commands at the beginning? Which shell commands do you expect to use? The next question would be, couldn't you re-write those shell commands as Python code? Or have the .BAT file call Python and run the .py file? -- Steve ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/S36CLS3NKSLJCQCXVOJ7ZQRUP3TZXBW3/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Improving -x switch on CLI interface
Hi, Rafael. Can you give a use case where you’d find this helpful? Thanks. -- Eric > On May 14, 2022, at 1:15 PM, Rafael Nunes wrote: > > > Hi. > What about improving the -x switch by passing the number of lines to ignore? > Ex: -x (default=1 line) > -x n (Python will ignore first n lines of file). > > I think it will allow us to execute some Windows commands before running > python. Install modules, etc... > > Thanks in advance. > > -- > > > Rafael Nunes > nunes.raf...@gmail.com > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/QCFJ6D2264KQHQ2NV2DCIHEXYE4EES5N/ > Code of Conduct: http://python.org/psf/codeofconduct/ ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/6U625LR2MXJYBH5WUZWZDKVYG636JRCI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Improving -x switch on CLI interface
Hi. Thanks for asking. In .BAT files we could write some Windows Shell commands before python code and python interpreter would ignore them. Em dom, 15 de mai de 2022 19:14, Eric V. Smith escreveu: > Hi, Rafael. > > Can you give a use case where you’d find this helpful? > > Thanks. > > -- > Eric > > On May 14, 2022, at 1:15 PM, Rafael Nunes wrote: > > > Hi. > What about improving the -x switch by passing the number of lines to > ignore? > Ex: -x (default=1 line) > -x n (Python will ignore first n lines of file). > > I think it will allow us to execute some Windows commands before running > python. Install modules, etc... > > Thanks in advance. > > -- > > > Rafael Nunes > nunes.raf...@gmail.com > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/QCFJ6D2264KQHQ2NV2DCIHEXYE4EES5N/ > Code of Conduct: http://python.org/psf/codeofconduct/ > > ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/AGI3MOY4XVNJGT36TIURHFBYF47EZ4ZR/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Awaiting until a condition is met
On 2022-05-15 03:10, Aaron Fink wrote: Hello. I've been thinking it would be nice to be able to use await to suspend execution until a condition is met (as represented by a function or lambda which returns a boolean. Currently, as far as I can tell, the way to accomplish this is with a while loop which frequently checks the condition, suspending execution in between checks. My use case is in robotics, so I'll use that. Here's a minimal version of my current approach. start_moving_to(dest) while distance_to(dest) > tolerance: await asyncio.sleep(1 / 60) This requires choosing a somewhat arbitrary frequency with which to check the condition. But if the frequency is too high, the function may not be suspended often enough for other tasks to run and if it's too low, there's a significant delay before the condition's satisfaction can be noticed. So here's my proposal for syntax that I think is quite a bit cleaner: start_moving_to(dest) await lambda: distance_to(dest) <= tolerance This eliminates the need to choose a frequency and makes the code even more readable. Of course, a previously-defined function could be used in place of a lambda, which would allow for the even cleaner expression await has_arrived if has_arrived is already defined. While I only have a basic understanding of how the event loop works, it seems to me it should be fairly straightforward to add a list of that pairs conditions with callbacks and check those conditions on each pass through the list of registered callbacks, fairly similarly to how scheduled callbacks created with asyncio.sleep wait until enough time has passed. Looking forward to hearing people's thoughts. I don't see how that could work. It's still just polling, so it could be expensive to check very often. All the callback is returning is True/False, which isn't very helpful for deciding how often it should check. As for your robotics example, you could adjust the frequency of checking according to how far it still has to go and how fast it's getting there - if it won't get anywhere close to the destination in, say, the next second, there's not much point in checking every 1/60 seconds. There can be a minimum frequency of checking, and you can increase the frequency as it gets very close to the destination. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/KXNSV3TBAGPTYGVJVQQZJOGYNFP76HU6/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: `importlib.resources` access whole directories as resources
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/ assets/ images/ a.png a.png c.png Each of data/ assets/ and images/ must also be a package, with its own __init__.py file. You cannot access the resource data/assets/images/a.png in the package my_great_app, you must access the resource a.png in the package my_great_app.data.assets.images. This is (in my opinion) unintuitive, easy to forget, and moderately annoying. So I think the feature request here is that Python start allowing directories as "resources", rather than just single files within a package. Alternatively, if for some reason directories cannot themselves be resources, allowing file resources in subdirectories (without creating a new subpackage) would also be a nice ergonomic improvement. I'm not sure if this poses issues for package resolution, namespace packages, etc. I imagine that this somewhat-obvious feature was omitted for a good reason. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/Q4KE5NQFZ4KMCRZQPKX73JXKNARYQXVE/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Awaiting until a condition is met
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_event))
await done_event
print('Arrived!')
And naturally you could wrap an existing function that returns a Boolean:
async def move_to(dest) -> bool:
...
async def set_if_success(event, awaitable):
result = await awaitable
if result:
event.set()
async def main():
dest = ...
done_event = asyncio.Event()
create_task(set_if_success(done_event, move_to(dest)))
await done_event
print('Arrived!')
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/QBR45ENLKZBUFF2M5YOSOJTF4AY7QECS/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Awaiting until a condition is met
On Sun, 15 May 2022 at 23:00, Aaron Fink wrote: > > Hello. > > I've been thinking it would be nice to be able to use await to suspend > execution until a condition is met (as represented by a function or lambda > which returns a boolean. > > Currently, as far as I can tell, the way to accomplish this is with a while > loop which frequently checks the condition, suspending execution in between > checks. My use case is in robotics, so I'll use that. Here's a minimal > version of my current approach. > > start_moving_to(dest) > while distance_to(dest) > tolerance: > await asyncio.sleep(1 / 60) > > This requires choosing a somewhat arbitrary frequency with which to check the > condition. But if the frequency is too high, the function may not be > suspended often enough for other tasks to run and if it's too low, there's a > significant delay before the condition's satisfaction can be noticed. > > So here's my proposal for syntax that I think is quite a bit cleaner: > > start_moving_to(dest) > await lambda: distance_to(dest) <= tolerance > > This eliminates the need to choose a frequency and makes the code even more > readable. But the frequency has to be defined somewhere. How does Python know when to check the function? Syntax doesn't remove that question, it only moves it around. What I would recommend is having your own "wait for condition" function that hides that logic away. Something like this (untested): POLL_FREQUENCY = 60 async def poll_until(pred): while not pred(): await asyncio.sleep(1 / POLL_FREQUENCY) Then, if you want to change your polling frequency, it's in one place, and not part of the logic of "are we there yet" which now only needs to concern itself with positions. A possibly-more-elegant solution might be to design your own event loop with an intrinsic frame rate, always advancing by precisely the same sleep interval and then checking whatever needs to be checked. But that would be a lot more work :) ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/CHJ6YVKVJYJP2CB6DGHB6VGWMTP5IPGA/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Awaiting until a condition is met
Hello. I've been thinking it would be nice to be able to use await to suspend execution until a condition is met (as represented by a function or lambda which returns a boolean. Currently, as far as I can tell, the way to accomplish this is with a while loop which frequently checks the condition, suspending execution in between checks. My use case is in robotics, so I'll use that. Here's a minimal version of my current approach. start_moving_to(dest) while distance_to(dest) > tolerance: await asyncio.sleep(1 / 60) This requires choosing a somewhat arbitrary frequency with which to check the condition. But if the frequency is too high, the function may not be suspended often enough for other tasks to run and if it's too low, there's a significant delay before the condition's satisfaction can be noticed. So here's my proposal for syntax that I think is quite a bit cleaner: start_moving_to(dest) await lambda: distance_to(dest) <= tolerance This eliminates the need to choose a frequency and makes the code even more readable. Of course, a previously-defined function could be used in place of a lambda, which would allow for the even cleaner expression await has_arrived if has_arrived is already defined. While I only have a basic understanding of how the event loop works, it seems to me it should be fairly straightforward to add a list of that pairs conditions with callbacks and check those conditions on each pass through the list of registered callbacks, fairly similarly to how scheduled callbacks created with asyncio.sleep wait until enough time has passed. Looking forward to hearing people's thoughts. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/BYHSWSIWEOWHVCCTXRKQRKN7KGA33ON6/ Code of Conduct: http://python.org/psf/codeofconduct/
