Nir Friedman added the comment:
Okay, fair enough.
--
___
Python tracker
<https://bugs.python.org/issue45250>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nir Friedman added the comment:
Wouldn't a nicer resolution for this be to change `iter` (which effectively
defines what is "iterable"), so that if `iter` does not find the `__iter__` or
sequence protocol, it then looks for the iterator protocol (`__next__`), and if
it finds th
Nir Soffer added the comment:
Updating python version, this is not relevant to 3.6 now.
On linux users can use "sync --file-system /path" but it would be nice if we
have something that works on multiple platforms.
--
nosy: +nirs
versions: +Python 3.11 -
Nir Soffer added the comment:
Does https://github.com/python/cpython/pull/1799 solve this issue
for synchronous with?
with closing(this), closing(that):
If it does, can we backport this fix to python 3.6?
3.6 is used as system python for RHEL/Centos 8, will be used for at
least 5 years
Nir Soffer added the comment:
Does this really affect only python 3.7?
We see this in RHEL 8.2, using python 3.6.8:
https://bugzilla.redhat.com/show_bug.cgi?id=1837199#c69
Likely caused by:
lvs = dict(self._lvs)
Without locking. self._lvs is a dict that may contain 1000's of items
Nir Soffer added the comment:
I find this new behavior a usability regression. Before this change, code
(e.g python 2 code ported to python 3) could do:
fd = sock.fileno()
Without handling errors, since closed socket would raise (good). Now such code
need to check the return value (bad
Change by Nir Soffer :
--
nosy: +nirs
___
Python tracker
<https://bugs.python.org/issue26868>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nir Soffer added the comment:
Doesn't it affect also 2.7, 3.6, 3.7, and 3.8?
--
___
Python tracker
<https://bugs.python.org/issue20215>
___
___
Python-bug
Change by Nir Soffer :
--
nosy: +nirs
___
Python tracker
<https://bugs.python.org/issue20215>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Nir Barel :
parent_parser = argparse.ArgumentParser(add_help=False)
main_parser = argparse.ArgumentParser(prog='app_cli')
service_subparsers = main_parser.add_subparsers(title="service",
dest="service_command"
Nir Soffer <nir...@gmail.com> added the comment:
Attaching reproducer for os.fdopen()
--
Added file: https://bugs.python.org/file47492/fdopen_nfs_test.py
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Nir Soffer <nir...@gmail.com> added the comment:
Attaching reproducer for mmapobject.size()
--
Added file: https://bugs.python.org/file47491/mmap_size_nfs_test.py
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Nir Soffer <nir...@gmail.com> added the comment:
Antoine, thanks for fixing this on master! but I don't think this issue
can be closed yet.
First, the issue is not a performance but reliability. I probably made
bad choice when I marked this as performance.
When you call mmap.mmap()
Nir Soffer <nir...@gmail.com> added the comment:
Python cannot protect raw file descriptor from bad multi-threaded
application. For example the application may close a file descriptor twice
which may lead to closing unrelated file descriptor created by another
thread just after it was
Change by Nir Soffer <nir...@gmail.com>:
--
pull_requests: +5787
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33021>
___
__
Change by Nir Soffer <nir...@gmail.com>:
--
keywords: +patch
pull_requests: +5786
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
New submission from Nir Soffer <nir...@gmail.com>:
If the file descriptor is on a non-responsive NFS server, calling
fstat() can block for long time, hanging all threads. Most of the fstat()
calls release the GIL around the call, but some calls seems to be
forgotten.
In python 3, the
Change by Nir Soffer <nir...@gmail.com>:
--
keywords: +patch
pull_requests: +4563
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Change by Nir Soffer <nir...@gmail.com>:
--
pull_requests: +4564
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32186>
___
__
Nir Soffer <nir...@gmail.com> added the comment:
Forgot to mention - reproducible with python 2.7.
Similar issues exists in python 3, but I did not try to reproduce since we
are using python 2.7.
I posted patches for both 2.7 and master:
- https://github.com/python/cpython/pull/4651
-
New submission from Nir Soffer <nir...@gmail.com>:
Using io.FileIO can hang all threads when accessing an inaccessible NFS
server.
To reproduce this, you need to open the file like this:
fd = os.open(filename, ...)
fio = io.FileIO(fd, "r+", closefd=True)
In
Nir Soffer <nir...@gmail.com> added the comment:
When using highlevel request() api, users can control the block size by
wrapping the file object with an iterator:
class FileIter:
def __init__(self, file, blocksize):
self.file = file
self.blo
Change by Nir Soffer <nir...@gmail.com>:
--
keywords: +patch
pull_requests: +4241
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
New submission from Nir Soffer <nir...@gmail.com>:
blocksize is hardcoded to 8192 in send() and _read_readable(), preventing
efficient upload when using file-like body.
Users of the module that are not interested in chunked encoding can rewrite
the copy loop using HTTPConnectio
Nir Soffer added the comment:
Victor, I mostly agree with you, but I think we have here several bugs, and
we should do the minimal fix for each of them. Your PR is too big, trying
to fix too much.
(Bug 1) The dispatcher A closes the dispatcher B. Currently, asyncore calls the
handlers
Changes by Nir Soffer <nir...@gmail.com>:
--
pull_requests: +2952
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30980>
___
__
Changes by Nir Soffer <nir...@gmail.com>:
--
pull_requests: +2951
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30980>
___
__
Changes by Nir Soffer <nir...@gmail.com>:
--
pull_requests: +2950
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30980>
___
__
Nir Soffer added the comment:
Giampaolo, people using only 3.7 should probably use asyncio. Fixing
asyncore is more important to those that can use only 2.7 (e.g.Centos/RHEL)
or have to support both python 3 and 2.
Do you think using _closed is safer for backport? This can also clash
Nir Soffer added the comment:
> I use the same trick all over the place in pyftpdlib:
> https://github.com/giampaolo/pyftpdlib/blob/1268bb185cd63c657d78bc33309041628e62360a/pyftpdlib/handlers.py#L537
This allow detection of closed sockets, but does not fix the issue of
accessing the
Nir Soffer added the comment:
The "new" closing attribute is old as asyncore, it was just unused :-)
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.py
Nir Soffer added the comment:
On my PR 2854, Nir added these comments (extract):
> "And now we try to read from close dispatcher. I think we should wait
> for #2804 (...)"
> Sorry, I don't understand. My PR fixes described the bug that you
> described in msg298682
Nir Soffer added the comment:
Using a quick test with 1000 clients sending 100 pings, I could not see
significant difference between master and this patch. Seems that the extra
copy is hidden by the noise.
Having this documented is good enough if someone want to use this.
--
stage
Nir Soffer added the comment:
The advantage is avoiding wasteful copy on each iteration.
--
nosy: +Nir Soffer
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Nir Soffer added the comment:
I agree that this change alone is may not be important enough to fix in
asyncore today - but this enables easy detection of closed sockets needed for
https://github.com/python/cpython/pull/2764 or the alternative
https://github.com/python/cpython/pull/2854
Changes by Nir Soffer <nir...@gmail.com>:
--
pull_requests: +2872
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30994>
___
__
New submission from Nir Soffer:
Asyncore is not thread safe, and cannot be called from multiple threads. Hence
it does not need to copy the socket_map when preparing for poll or
select.
The copy was introduced in:
commit d74900ebb5a22b387b49684990da1925e1d6bdc9
Author: Josiah Carlson
Changes by Nir Soffer <nsof...@redhat.com>:
--
nosy: +haypo
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30985>
___
__
New submission from Nir Soffer:
This is an old issue with asyncore - asyncore has a "closing" attribute,
but it was never used. Every user has to implement the closing once
logic in dispatcher subclasses.
Here is a typical fixes in user code:
- https://github.com/oVirt/vdsm/blob/maste
Nir Soffer added the comment:
This saves memory, but using str(uuid.uuid4()) requires even less memory.
If you really want to save memory, you can keep the uuid.uuid4().int.
Can you explain someone would like to have 100 uuid objects, instead of
100 strings? What is the advantage
Changes by Nir Soffer <nir...@gmail.com>:
--
pull_requests: +2839
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30980>
___
__
New submission from Nir Soffer:
Commit 4d4c69dc35154a9c21fed1b6b4088e741fbc6ae6 added protection for double
close in file_wrapper.close, but the test did not consider that fact that
file_wrapper is dupping the file descriptor, making the test ineffective.
>>> fd1, fd2 = os.pip
Nir Soffer added the comment:
Adding more info after discussion in github.
After polling readable/writeable dispatchers, asyncore.poll(2) receive a list
of ready file descriptors, and invoke callbacks on the dispatcher objects.
If a dispatchers is closed and and a new dispatcher is created
Nir Soffer added the comment:
Can you provide a minimal reproducer, or best add a failing test?
--
nosy: +Nir Soffer
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
New submission from Nir Soffer:
To reproduce:
checkout
https://github.com/nirs/cpython/commit/9648088e6ccd6d0cc04f450f55628fd8eda3784c
mkdir debug
cd debug
../configure --with-pydebug
make
make test
...
==
FAIL
Nir Soffer added the comment:
I rebased the patch on master (it was created against the legacy git tree
in github), and sent a pull request.
--
nosy: +Nir Soffer
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Changes by Nir Soffer <nir...@gmail.com>:
--
pull_requests: +2747
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25516>
___
__
Changes by Nir Soffer <nir...@gmail.com>:
--
pull_requests: +2702
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29854>
___
__
Changes by Nir Soffer <nir...@gmail.com>:
--
pull_requests: +2701
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29854>
___
__
Changes by Nir Soffer <nir...@gmail.com>:
--
pull_requests: +2698
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29854>
___
__
Changes by Nir Soffer <nir...@gmail.com>:
--
pull_requests: +2687
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29854>
___
__
Nir Soffer added the comment:
So we have version 0x502 without libedit emulation succeeding on
FreeBSD 9.x, and failing on 10.x.
I think we are missing something, or maybe the libedit check is wrong.
We need results from all builders to do something with this. I think
at least for now we want
Nir Soffer added the comment:
I like the idea, may be also useful in
https://github.com/sosreport/sos/blob/master/sos/plugins/python.py
--
nosy: +Nir Soffer
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Nir Soffer added the comment:
The failures looks like libedit failures on OS X, where history size is
ignored. The test is skipped if is_editline is set, we should probably skip on
these platforms too.
--
nosy: +Nir Soffer
___
Python tracker <
Nir Soffer added the comment:
This issue does not exist on OS X 10.11.6 (latest my old mac can install).
I tested using .editrc file:
$ cat ~/.editrc
history size 5
With history file with 10 items that crashes on Linux using GNU readline.
This settings is ignored, adding items to the history
Nir Soffer added the comment:
I think the issue can be solved in readline or in the code using it, but I
don't have more time to dig into this, and I think that python should not crash
in this case.
I don't have an environment to test Apple editline, so I cannot test this
issue. The PR
Nir Soffer added the comment:
Sure, I'll add news entry and tests.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29854>
___
___
New submission from Nir Soffer:
GNU readline let the user select limit the history size by setting:
$ cat ~/.inputrc
set history-size 1000
So I cooked this test script:
$ cat history.py
from __future__ import print_function
import readline
readline.read_history_file(".history&quo
Changes by Nir Soffer <nir...@gmail.com>:
--
nosy: +nirs
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26180>
___
___
Python
Nir Cohen added the comment:
I would love some comments (and PRs, of course) on ld. Wanna make it as robust
as possible.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/
Nir Cohen added the comment:
I have a premliminary implementation of it: https://github.com/nir0s/ld
Would love some help. It tries to use adhere to the standards (os-release
first, lsb-release later, then, distro-specific release files).
It also returns more types of values then there were
Nir Cohen added the comment:
I didn't mean to say that it was. Still, it's important to have some
implementation of identifying linux distributions and their properties..
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.p
Nir Cohen added the comment:
Apologies.
This can be simply installed by running `pip install ld` (from
https://pypi.python.org/pypi/ld).
Some notes:
* I've just now started writing tests
* Haven't tested on versions other than 2.7.x and 2.6.x
* There's some stray code there. This works
Changes by Nir Soffer <nir...@gmail.com>:
--
keywords: +patch
Added file:
http://bugs.python.org/file40941/0001-Issue-254074-Test-condition-behavior-instead-of-inte.patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
New submission from Nir Soffer:
test_reset_internal_locks is looking at Event's _cond._lock - this make it
harder to change internal details of the Condition object and make the test
fragile.
We should test the condition behavior instead.
--
components: Tests
messages: 254074
nosy
Changes by Nir Soffer <nir...@gmail.com>:
--
nosy: +haypo, pitrou
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25516>
___
__
Changes by Nir Soffer <nir...@gmail.com>:
--
type: -> behavior
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25516>
___
___
Nir Soffer added the comment:
The commit hash in the previous message is a git commit from the github mirror:
https://github.com/python/cpython/commit/8cb1ccbb8b9ed01c26d2c5be7cc86682e525dce7
--
___
Python tracker <rep...@bugs.python.org>
New submission from Nir Soffer:
When using threading.Lock, threading.Condition._is_owned is assuming that the
calling thread is owning the condition lock if the lock cannot be acquired.
This check is completely wrong if another thread owns the lock.
>>> cond = threading.
Nir Soffer added the comment:
The issue was introduced in this commit:
commit 8cb1ccbb8b9ed01c26d2c5be7cc86682e525dce7
Author: Guido van Rossum <gu...@python.org>
Date: Thu Apr 9 22:01:42 1998 +
New Java-style threading module. The doc strings are in a separate
Changes by Nir Soffer <nir...@gmail.com>:
--
keywords: +patch
Added file:
http://bugs.python.org/file40900/0001-Issue-25516-threading.Condition._is_owned-fails-when.patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
New submission from Nir Soffer:
Using "with" is more clear and less error prone.
--
components: Library (Lib)
files: 0001-Use-with-instead-of-try-finally.patch
keywords: patch
messages: 252716
nosy: nirs
priority: normal
severity: normal
status: open
title: Use with inst
Changes by Nir Soffer <nir...@gmail.com>:
Added file:
http://bugs.python.org/file40741/0001-In-threading-module-use-with-instead-of-try-finally.patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Nir Soffer <nir...@gmail.com>:
--
nosy: +pitrou
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25298>
___
__
Changes by Nir Soffer <nir...@gmail.com>:
--
nosy: +gregory.p.smith
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25319>
___
_
New submission from Nir Soffer:
When Event._reset_internal_locks was called after fork, it use to
reinitialize its condition without arguments, using RLock instead of
Lock.
--
components: Library (Lib)
files: 0001-Keep-lock-type-when-reseting-internal-locks.patch
keywords: patch
Changes by Nir Soffer <nir...@gmail.com>:
Added file:
http://bugs.python.org/file40688/0001-Keep-lock-type-when-reseting-internal-locks.patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Nir Soffer <nir...@gmail.com>:
Added file:
http://bugs.python.org/file40687/0001-Keep-lock-type-when-reseting-internal-locks-2.7.patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Nir Soffer <nir...@gmail.com>:
--
components: Tests
files: 0001-Add-lock-rlock-weakref-tests.patch
keywords: patch
nosy: nirs
priority: normal
severity: normal
status: open
title: Add lock and rlock weakref tests
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6
New submission from Nir Soffer:
Same patch works also for 2.7
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25298>
___
___
Pyth
New submission from Nir Soffer:
The module define unsafe replacement if tempfile.mkstemp is not available.
This function is available in both master and 2.7 branches.
--
components: Tests
files: 0001-Remove-unneeded-and-unsafe-mkstemp-replacement.patch
keywords: patch
messages: 251720
Changes by Nir Soffer <nir...@gmail.com>:
Added file:
http://bugs.python.org/file40601/0001-Remove-unneeded-and-unsafe-mkstemp-replacement-2.7.patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Nir Soffer nir...@gmail.com:
--
nosy: +nirs
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6721
___
___
Python-bugs-list mailing list
Nir Soffer added the comment:
This is a duplicate of http://bugs.python.org/issue6721
--
nosy: +nirs
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22697
Nir Soffer nir...@gmail.com added the comment:
As someone who has to develop on ARM OABI, I find this won't fix policy rather
frustrating.
If you happen to need this patch on 2.7, this is the same patch as
arm-float2.diff, which can be applied cleanly to release 2.7.2.
Changes from arm
Nir Aides n...@winpdb.org added the comment:
For the record, turns out there was a bit of misunderstanding.
I used the term deprecate above to mean warn users (through documentation)
that they should not use (a feature) and not in its Python-dev sense of
remove (a feature) after a period
Nir Aides n...@winpdb.org added the comment:
Hi Gregory,
Gregory P. Smith g...@krypto.org added the comment:
No Python thread is ever fork safe because the Python interpreter itself can
never be made fork safe.
Nor should anyone try to make the interpreter itself safe. It is too complex
Nir Aides n...@winpdb.org added the comment:
then multiprocessing is completely brain-damaged and has been
implemented by a moron.
Please do not use this kind of language.
Being disrespectful to other people hurts the discussion.
--
___
Python
Nir Aides n...@winpdb.org added the comment:
(BTW: there are religions without god, so whom shall e.g. i praise for the
GIL?)
Guido? ;)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6721
Nir Soffer nir...@gmail.com added the comment:
The idea is good, but seems that error handling should be inlined into
initiate_send.
Also those 3 special exceptions should be defined once in the module instead of
repeating them.
--
nosy: +nirs
Nir Aides n...@winpdb.org added the comment:
Here is a morning reasoning exercise - please help find the flaws or refine it:
5) Sanitizing worker threads in the multiprocessing module
Sanitizing a worker thread in the context of this problem is to make sure it
can not create a state that may
Nir Aides n...@winpdb.org added the comment:
Well, my brain did not deadlock, but after spinning on the problem for a while
longer, it now thinks Tomaž Šolc and Steffen are right.
We should try to fix the multiprocessing module so it does not deadlock
single-thread programs and deprecate fork
Changes by Nir Aides n...@winpdb.org:
--
title: threading module can deadlock after fork - malloc
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue874900
Changes by Nir Aides n...@winpdb.org:
--
title: malloc - threading module can deadlock after fork
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue874900
Nir Aides n...@winpdb.org added the comment:
Would you like to work on a patch to add an atfork mechanism?
I will start with an attempt to generate a summary report on this rabbit hole
of a problem, the views and suggestions raised by people here and what we may
expect from atfork approach
Nir Aides n...@winpdb.org added the comment:
Sorry, I fail to see how the import graph is related to the correct
lock acquisition order. Some locks are created dynamically, for
example.
Import dependency is a reasonable heuristic to look into for inter-module
locking order.
The rational
Nir Aides n...@winpdb.org added the comment:
- what would be the API of this atfork() mechanism (with an example of how it
would be used in the library)?
The atfork API is defined in POSIX and Gregory P. Smith proposed a Python one
above that we can look into.
http://pubs.opengroup.org
Nir Aides n...@winpdb.org added the comment:
Well, I ping my view that we should:
1) Add general atfork() mechanism.
2) Dive into the std lib and add handlers one by one, that depending on case,
either do the lock/init thing or just init the state of the library to some
valid state
Nir Aides n...@winpdb.org added the comment:
I believe that the comp.programming.threads post from
David Butenhof linked above explains why adding atfork()
handlers isn't going to solve this.
In Python atfork() handlers will never run from signal handlers, and if I
understood correctly
Nir Aides n...@winpdb.org added the comment:
Right! I updated the patch and added a test for the aligned stream/buffer case.
--
Added file: http://bugs.python.org/file22114/cpython-bz2-streams.patch
___
Python tracker rep...@bugs.python.org
http
1 - 100 of 224 matches
Mail list logo
