New submission from Antoine Pietri :
In 3.7 a lot of high level functions have been added to the asyncio API, but
nothing to start blocking functions as non-blocking threads. You still have to
call get_event_loop() then await loop.run_in_executor(None, callable). I think
this pattern is
Antoine Pietri added the comment:
Actually I don't think it's possible with the current implementation to cancel
the concurrent.Future after a timeout, so maybe we should remove that argument.
So, this signature instead:
async def create_thread(callable, *args, *, kwargs=None,
Antoine Pietri added the comment:
> run_in_executor doesn't necessarily create a new thread each time so
> create_thread would be misleading. run_in_thread might be better.
Right, the idea was to have an analogy with create_task, because the
run_in_executor would be wrapped in
Antoine Pietri added the comment:
On Sat, Oct 12, 2019 at 1:24 PM Caleb Hattingh wrote:
> Even before task groups land, this API can be easily improved by adding
>
> asyncio.run_in_executor(func, *args, **kwargs)
>
> - Only valid inside a coro or async context (uses g
Antoine Pietri added the comment:
Yes, that's why I'm in favor of calling it run_thread. Because it
fundamentally *isn't* a way to run a function in an executor, it's a
way to run a function in a thread.
--
___
Py
Antoine Pietri added the comment:
Yeah I'm pretty sure this solves it:
https://github.com/python/cpython/pull/20143
Closing the issue, thanks.
--
resolution: -> fixed
___
Python tracker
<https://bugs.python.org
New submission from Antoine Pietri:
>>> b'a' + 'a'
Traceback (most recent call last):
File "", line 1, in
TypeError: can't concat bytes to str
This error message is misleading because it is reversed: what is really
happening is that we're c
Changes by Antoine Pietri :
--
pull_requests: +2447
___
Python tracker
<http://bugs.python.org/issue30762>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Antoine Pietri :
--
components: +Interpreter Core
___
Python tracker
<http://bugs.python.org/issue30762>
___
___
Python-bugs-list mailing list
Unsub
Antoine Pietri added the comment:
Trivial way to reproduce, run this as root:
systemd-run -p DynamicUser=yes -t python3
--
nosy: +antoine.pietri
___
Python tracker
<https://bugs.python.org/issue10
Antoine Pietri added the comment:
Would it make sense to backport this fix in 3.6 and 3.7? As distros
increasingly move in the direction of using DynamicUser=yes for most stateless
services, it would really help to have that, for instance in Debian Buster
(which will probably be on 3.7 if
Antoine Pietri added the comment:
I can reproduce this bug. This behavior is really confusing.
--
nosy: +seirl
___
Python tracker
<http://bugs.python.org/issue30
Antoine Pietri added the comment:
In Windows/Python 3.6, the behavior matches the documented one, so this could
actually be an important silent bug when executing a code wrote for Windows in
another OS. I'd argue to fix it in 3.6 too.
--
___
P
Antoine Pietri added the comment:
By the way, I'm pasting what I said on the PR here:
For what it's worth, this bug was the cause of an important downtime in our
organization, because someone needed to normalize a path that was later passed
to a .mkdir(parents=True), and it wa
Antoine Pietri added the comment:
I'm on it.
--
___
Python tracker
<http://bugs.python.org/issue30177>
___
___
Python-bugs-list mailing list
Unsubscr
Antoine Pietri added the comment:
I added a fix for the tests and the code.
--
___
Python tracker
<http://bugs.python.org/issue30177>
___
___
Python-bugs-list m
Antoine Pietri added the comment:
I checked, the current doc gives a good explanation. I'm closing the issue.
--
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.
Changes by Antoine Pietri :
--
stage: test needed -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue21044>
___
___
Pyth
Antoine Pietri added the comment:
So, I asked a friend to check again with a more recent Python version on
Windows and he can't reproduce the documented behavior, so the bug seems to
also be present on Windows. My patch doesn't address that for now, which
explains why the build fail
Antoine Pietri added the comment:
I updated the PR to fix the Windows part of the issue thanks to Zachary who
gave me access to a Windows machine.
--
___
Python tracker
<http://bugs.python.org/issue30
Antoine Pietri added the comment:
The code has been reviewed by (the other) Antoine, I guess there is now
everything needed to merge it?
--
___
Python tracker
<http://bugs.python.org/issue30
Changes by Antoine Pietri :
--
pull_requests: +2052
___
Python tracker
<http://bugs.python.org/issue30177>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pietri added the comment:
The only backport was for 3.6 as the previous versions don't have the strict=
parameter. PR submitted here: https://github.com/python/cpython/pull/1985
--
___
Python tracker
<http://bugs.python.org/is
Changes by Antoine Pietri :
--
pull_requests: +2188
___
Python tracker
<http://bugs.python.org/issue30177>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Antoine Pietri :
--
pull_requests: +2189
___
Python tracker
<http://bugs.python.org/issue30177>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Antoine Pietri :
--
pull_requests: +5784
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue22674>
___
___
Python-bugs-list mai
Antoine Pietri added the comment:
I updated Vajrasky's patch to rebase it onto master, use the clinic argument
parser and improve the docs. I made a PR on GitHub so the review can be easier
than a patch.
I left a Co-Authored-By field so I'm not stealing the ownership of this
Antoine Pietri added the comment:
Yes, sorry, the issue is that we decided with pitrou to remove the osx specific
handling.
The fix should be:
diff --git a/Lib/test/test_signal.py b/Lib/test/test_signal.py
index fbb12a5b67..ae0351e992 100644
--- a/Lib/test/test_signal.py
+++ b/Lib/test
Change by Antoine Pietri :
--
pull_requests: +5846
stage: needs patch -> patch review
___
Python tracker
<https://bugs.python.org/issue22674>
___
___
Python-
Antoine Pietri added the comment:
Done, https://github.com/python/cpython/pull/6085
As I said in the PR body, I can't test it myself, I don't have an OSX VM setup.
--
___
Python tracker
<https://bugs.python.o
Antoine Pietri added the comment:
Hey everyone,
We would like to have that feature for a project where we have to use ctypes to
achieve that. I don't know the answers to vajrasky's questions but I just
wanted to chime in to say having this feature would be greatly appreciated. I
Change by Antoine Pietri :
--
keywords: +patch
pull_requests: +4084
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue29116>
___
___
Py
New submission from Antoine Pietri :
SHA-1 has been broken a while ago. While the general recommandation is to
migrate to more recent hashes (like SHA-2 and SHA-3), a lot of industry
applications (notably Merkle DAG implementations like Git or Blockchains)
require backwards compatibility
Antoine Pietri added the comment:
On Wed, Oct 10, 2018 at 11:27 PM STINNER Victor wrote:
> I dislike modifying a hash function to return its output but keep the same
> name. For name, "SHA1" must remain "SHA1". If you want a variant, it should
> have a diffe
Antoine Pietri added the comment:
Tracking down the issue a bit further:
a = 10
def main():
a = 42
class wtf():
print(a)
class wtf2():
print(a)
a = 2
main()
prints:
42
10
It seems that when there is an
Antoine Pietri added the comment:
Thanks, those arguments are convincing. I guess for applications that really
can't move to a more secure hash, it would be better for them to rely on
third-party libraries that implement the "band-aid".
I'm closing this for no
New submission from Antoine Pietri:
I just found a very strange bug today, and it took me like two hours to figure
out the problem.
We first create a package "package", which contains an __init__.py, which makes
an absolute import of package/foo.py (import package.foo), whic
Antoine Pietri added the comment:
Okay, maybe my message was unclear. I figured out on my own how to work around
this issue (for instance using relative imports), the main problem for me is
that this issue is very difficult to debug. The "import" statement should at
least fail w
New submission from Antoine Pietri:
The fact that tempfile.TemporaryFile() has a "name" integer attribute causes
weird behavior when interacting with libraries that rely on this attribute
being a valid string for file objects.
For instance, it led to this exception with the "
Antoine Pietri added the comment:
Alternatively, if the "name" attribute can't be removed, I propose the
following diff for the tarfile module:
-if name is None and hasattr(fileobj, "name"):
+if name is None and hasattr(fileobj, "name"
Antoine Pietri added the comment:
I attached a patch for tarfile with eryksun's suggestion.
--
keywords: +patch
Added file: http://bugs.python.org/file34603/tarfile-fileobjname.diff
___
Python tracker
<http://bugs.python.org/is
Antoine Pietri added the comment:
Here's the test case as requested by berkerpeksag in the patch review.
--
Added file: http://bugs.python.org/file34605/test_tarfile_fobj_int.diff
___
Python tracker
<http://bugs.python.org/is
Antoine Pietri added the comment:
Yes, the bug report was originally titled like this ("TemporaryFile should'nt
have a name attribute") but apparently this is a common and expected behavior
for FileIO subclasses.
--
___
Python
Antoine Pietri added the comment:
Well, this behavior seems pretty inconsistent to me, it means that every
library has to check if the name attribute is actually a string (which would
correspond to a path) or an int (that would mean a fd), and I think a "fd"
attribute would
Antoine Pietri added the comment:
Ping. The patch is just one line and there's a test case, if someone could
review that, it would be great!
(For the record I signed the contributor agreement a week ago and my profile
still hasn't be
Antoine Pietri added the comment:
Well, that seems complicated: you can't overwrite a io.FileIO().name attribute,
and doing so would be nonsensical for tarfile, which would try to perform IO
operations on a random file descriptor... Also, I can't think of any case where
a .name
Antoine Pietri added the comment:
Actually, thinking about it, it seems safer to use os.open() + os.fdopen() than
TemporaryFile(), like in the equivalent test for 'gzip'.
This new patch replaces last one.
--
nosy: +seirl
Added file: http://bugs.python.org
Antoine Pietri added the comment:
> I think that `absolute` method should call `expanduser` and `expandvars` (do
> you plan to include it?) automatically. This should be optional (via default
> arguments: `expanduser=True, expandvars=True`.
I think it shouldn't. (Or shouldn&#x
Antoine Pietri added the comment:
> Also, Serhiy, I think you may have got me mixed up with someone else. I don’t
> think I did any patches here, so I probably shouldn’t be credited for them :)
Yeah, but I don't mind if I'm not in the ACKS file for a one-line
Antoine Pietri added the comment:
This change does not need to be merged on 2.7 anyway, as the os.fdopen sets the
name attribute to '' and not to the fd, this check is not required
prior to python 3.
Still, it would be interesting to investigate why this breaks
New submission from Antoine Pietri:
In the new types.coroutines() documentation, it is not clearly stated whether
this function is idempotent or not: what happens when it is called on a
function that is already a native coroutine?
--
assignee: docs@python
components: Documentation
Antoine Pietri added the comment:
Lgtm!
--
___
Python tracker
<http://bugs.python.org/issue24692>
___
___
Python-bugs-list mailing list
Unsubscribe:
52 matches
Mail list logo
