The faulthandler module is invaluable for tracking down segfaults in native
code, however it is really lacking the ability to add some kind of useful
breadcumb to aide debugging. Imagine you are running a large-scale distributed
job over tens of millions of images and a single one causes opencv
> Until you have this have you considered turning on core dumps? Then you will
> be able to see the image id in the dump file.
Alternatively you could write the context to a file. Then log the contents of
the file in a wrapper script that handlers python exiting on SEGV.
> I understand what you
If anyone is interested, I had a play around with this and came up with a
pretty simple-ish implementation: https://github.com/orf/cpython/pull/1/files.
___
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to python-ideas
In the context of building Docker images, it is often required to download
stuff. If curl/wget is available, great, but often slim images don't
include that. The urllib could provide a very simple download functionality
(like http offers a simple server):
from urllib.request import urlopen
dat
red.
IMHO, the benefit-cost ratio is quite good:
* can be a lifesaver (just like http.server) every once in a while in
particular in a container or testing context
* low implementation effort
* easy to test and to maintain
Tom
___
Python-ideas mailing
while downloading a 1.9 GB file in under three minutes
(other
clients where using the same connection).
Tom
___
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org
You are absolutely right, the functionality is there, but the idea is to make
it easily available from the command line.
Here is a line (with shortened URL) from a Dockerfile which installs poetry as
suggested in the docs:
RUN python -c "from urllib.request import urlopen;
print(urlopen('h
Thanks, finally a +1! \o/
It's funny that "entry point" triggered your reaction, because I think it's not
the correct technical term.
What I'm proposing is very similar to http.server:
https://github.com/python/cpython/blob/3.10/Lib/http/server.py#L1257
Just like "python -m http.server" you co
A question for the Python experts: What is the correct technical term for a
functionality like "http.server", i.e., a module with an actual "main" function?
___
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to python-i
Thanks. Not as catchy as I would have hoped, though. ;-)
One person except me in favor of this idea.
Any other feedback? How to proceed?
___
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Thanks for the nudge.
If anyone is interested (or could approve to make the pipeline run), here's the
PR: https://github.com/python/cpython/pull/29217
___
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to python-ideas-
Page Not Found
I couldn't easily work out what the correct link should be, but part of
the solution seems to be httpS://
Perhaps someone here knows how to wrangle gmane.org?
--
Tom Hale
___
Python-ideas mailing list
Python-ideas@python
e risk.
Prior art:
* https://bugs.python.org/issue36656 (already mentioned above)
* https://stackoverflow.com/a/55742015/5353461
* https://git.savannah.gnu.org/cgit/coreutils.git/tree/src/ln.c
--
Tom Hale
___
Python-ideas mailing list
[email protected]
sting
the updated links, or is there a specific channel for web updates?
--
Tom Hale
___
Python-ideas mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
On 14/5/19 10:53 am, Brett Cannon wrote:
Bugs about the website should be reported to
https://github.com/python/pythondotorg .
Thanks, reported at: https://github.com/python/pythondotorg/issues/1435
--
Tom Hale
___
Python-ideas mailing list
Python
will use a password which is valuable to them.
Should this "feature" be turned off for new subscribers?
--
Tom Hale
___
Python-ideas mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: h
The Google Web Search API is no longer available. Please migrate to the
Google Custom Search API (https://developers.google.com/custom-search/)
--
Tom Hale
___
Python-ideas mailing list
[email protected]
https://mail.python.org/mailman/listinfo/pyt
On 14/5/19 4:46 pm, Tom Hale wrote:
How do I search this list's archives?
Inspiration struck:
Google for:
site:https://mail.python.org/pipermail/python-ideas/ search terms
--
Tom Hale
___
Python-ideas mailing list
[email protected]
al of 8
functions, with ugly names like "hardlink_overwrite_follow_links" or
"softlink_non_overwrite_link_to_links".
It seems far more practicable to have only two functions with sensible
boolean defaults, with the split being based on the underlying os mo
e is more
likely be implemented poorly/incorrectly on a roll-your-own basis. To
me, I see this as adding weight to the case of inclusion in a library.
--
Tom Hale
___
Python-ideas mailing list
[email protected]
https://mail.python.org/mailman/listin
to have someone to review and bounce ideas off given this will
be my first stdlib contribution.
If someone is willing to mentor, please contact me via private mail.
[1] https://docs.python.org/library/os.html
[2] https://pubs.opengroup.org/onlinepubs/9699919799/
They say silence is golden... But I'm still looking for some feedback on
the below.
Cheers!
--
Tom Hale
On 16 May 2019 21:13:50 Tom Hale wrote:
Thanks to all who have contributed to the discussion so far.
I've noticed that the documentation[1] for both os.link and os.symli
=
This is an example of atomicity ensuring that a condition remains valid
*during* the operation.
I gave an example of this in my initial post:
On 13/5/19 4:38 pm, Tom Hale wrote:
> It would be tempting to do:
>
> while True:
> try:
>
heers,
--
Tom Hale
On 26/6/19 2:58 am, Serhiy Storchaka wrote:
04.06.19 10:25, Inada Naoki пише:
If "ln -sf" is not atomic and do remove & symlink, web server or php
will return 404 error between remove and symlink.
I feel this use case is more real world application than
"I don&#x
A protocol that other Future implementations would be great. The Dask
distributed library has an API compatible with concurrent.futures, but would
never be appropriate for inclusion in the standard library. It'd be perfect if
Dask's Future objects would work well with concurrent.futures.as_compl
Hello,
I would like to suggest adding a simple “once” method to functools. As the name
suggests, this would be a decorator that would call the decorated function,
cache the result and return it with subsequent calls. My rationale for
suggesting this addition is twofold:
First: It’s fairly commo
Sun, Apr 26, 2020 at 03:03:16PM +0100, Tom Forbes
> wrote:
> > Hello,
> > I would like to suggest adding a simple ???once??? method to functools.
> As the name suggests, this would be a decorator that would call the
> decorated function, cache the result and return it wit
which would be
> exactly equivalent to lru_cache in the expected use case (i.e. decorating a
> function without arguments). It seems like a good way to cause confusion,
> especially for beginners. Based on the Zen, there should be one obvious way
> to do it.
>
> On Sun, Ap
;
> def once(func):
> return func()
>
> @once
> def pwd():
> return os.getcwd()
>
> print(pwd)
>
> On Sun, Apr 26, 2020 at 7:09 AM Tom Forbes <mailto:[email protected]>> wrote:
> Hello,
> I would like to suggest adding a simple “once” method to fun
2020 at 1:54 PM Tom Forbes <mailto:[email protected]>> wrote:
> This is a good idea but some cases need to be lazily evaluated. Without that
> property `once()` loses a lot of utility. In the case of Django some of the
> decorated functions create objects that cannot be insta
I would think that would be a great name, it’s more explicit and fits more in
with its siblings “lru_cache” and “cached_property”.
Not to imply that there is a consensus to move forward, I would be interested
in knowing what the next steps would be if there was. Would this require a PEP
to be s
Thank you Kyle and everyone else who chimed in here. I’ve made a post to the
python-dev mailing list - it has yet to appear, but perhaps it’s in a
moderation queue. I’ll ensure it’s posted tomorrow.
Tom
> On 27 Apr 2020, at 21:56, Kyle Stanley wrote:
>
> Christopher Barker wrote:
&g
(before `once`) or having the chance that it’s
called more than once (after `once`).
Tom
> On 29 Apr 2020, at 08:15, Andrew Barnert via Python-ideas
> wrote:
>
> On Apr 28, 2020, at 16:25, Steven D'Aprano wrote:
>>
>> On Tue, Apr 28, 2020 at 11:45:49AM -0700, Raymon
re now slower.
Seems generally more correct, even in single threaded cases, to pay the
overhead only in the first call if you want `call_once` semantics. Which is why
you would be using `call_once` in the first place?
> On 29 Apr 2020, at 18:51, Andrew Barnert wrote:
>
> On Apr 29, 2020
30 Apr 2020, at 03:09, Andrew Barnert wrote:
>
> On Apr 29, 2020, at 11:15, Tom Forbes <mailto:[email protected]>> wrote:
>>
>>> Thread 2 wakes up with the lock, calls the function, fills the cache, and
>>> releases the lock.
>>
>> What exact
Raymond Hettinger
> wrote:
>
>
>
>> On Apr 29, 2020, at 11:15 AM, Tom Forbes wrote:
>>
>> What exactly would the issue be with this:
>>
>> ```
>> import functools
>> from threading import Lock
>>
>> def once(func):
>&g
important especially when it’s more performant in the
general case. And clearly the current use of this pattern in the stdlib means
others have come to the same conclusion.
> On 2 May 2020, at 06:45, Andrew Barnert wrote:
>
> On May 1, 2020, at 09:51, Tom Forbes wrote:
>>
>&
ed from
using them in the first place.
So yeah, that was my argument for making tokens 16 bytes long instead of
32. Please let me know if and why I am
completely wrong:P
Regards,
Tom
___
Python-ideas mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Ok, thank you. I will make the issue and pull request once the switch to GitHub
issues is done.
On Sun, Mar 6, 2022, at 10:20 AM, Eric V. Smith wrote:
>
>> On Mar 6, 2022, at 5:05 AM, Barry Scott wrote:
>>
>>
>>> On 6 Mar 2022, at 07:19, [email protected] wrote:
>>>
>>> For reference, this re
39 matches
Mail list logo
