Changes by Richard Oudkerk :
--
title: Creating new processes after importing multiprocessing.managers consumes
more and more memory -> ForkAwareThreadLock leak after fork
versions: +Python 3.3, Python 3.4
___
Python tracker
<http://bugs.pyth
Changes by Richard Oudkerk :
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Richard Oudkerk added the comment:
Pickling an exception (assuming it works) does not capture the traceback.
Doing so would be difficult/impossible since the traceback refers to a linked
list of frames, and each frame has references to lots of other stuff like the
code object, the global
Changes by Richard Oudkerk :
--
nosy: +sbt
___
Python tracker
<http://bugs.python.org/issue17778>
___
___
Python-bugs-list mailing list
Unsubscribe:
Richard Oudkerk added the comment:
Would this mean that the destructor could be run more than once (or
prematurely)?
--
nosy: +sbt
___
Python tracker
<http://bugs.python.org/issue17
Richard Oudkerk added the comment:
In Python 3 "/" gives float division, whereas in Python 2 it is integer
division, the same as "//".
--
nosy: +sbt
___
Python tracker
<http://bug
Richard Oudkerk added the comment:
Just to clarify, if you use float division then you get rounding errors.
309657313492949847071 is a rounding error:
>>> x = 284397269195572115652769428988866694680//17
>>> x - int(float(x))
3096
Richard Oudkerk added the comment:
Yes.
--
resolution: -> invalid
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Richard Oudkerk added the comment:
Duplicate of #13831.
--
resolution: -> duplicate
___
Python tracker
<http://bugs.python.org/issue17836>
___
___
Python-
Richard Oudkerk added the comment:
It might be possible to come up with a hack so that when the exception is
unpickled in the main process it gets a secondary exception chained to it using
__cause__ or __context__ whose stringification contains the stringification of
the original traceback
Changes by Richard Oudkerk :
--
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue17836>
___
___
Pyth
Richard Oudkerk added the comment:
Some sort of error is expected.
On Windows any functions or classes used in a task sent the executor must be
picklable/unpicklable. This means that they must be defined in an importable
module rather than being defined in the interactive shell.
On Unix
Richard Oudkerk added the comment:
> Ah. Then, a documentation error. The error message ("queue.Full"?) and
> the documentation are totally not clear about that.
Once something goes wrong you are likely to get a cascade of errors, and the
first one reported is not necessar
Richard Oudkerk added the comment:
It might be simplest to make the implementation match the docs by making
AsyncResult an alias for ApplyResult.
--
___
Python tracker
<http://bugs.python.org/issue17
Richard Oudkerk added the comment:
Attached is a patch for 3.4 which uses the __cause__ hack to embed the remote
traceback in the local traceback. It will not work for 2.x though.
>>> import multiprocessing, subprocess
>>> with multiprocessing.Pool() as p: p.apply(su
Richard Oudkerk added the comment:
Here is an updated patch. It is only really the example in the docs which is
different, plus a note about daemon threads.
Antoine, do think this is ready to be committed?
--
Added file: http://bugs.python.org/file30140/finalize.patch
Richard Oudkerk added the comment:
The only (non-doc, non-comment) changes were the two one-liners you suggested
in msg172077. So I will commit.
--
___
Python tracker
<http://bugs.python.org/issue15
Richard Oudkerk added the comment:
I don't see any difference in meaning:
http://idioms.thefreedictionary.com/as+far+as+possible
--
nosy: +sbt
___
Python tracker
<http://bugs.python.org/is
Changes by Richard Oudkerk :
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Changes by Richard Oudkerk :
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Changes by Richard Oudkerk :
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Richard Oudkerk added the comment:
The relevant changeset was c4f92b597074, but I wrote the wrong issue number in
the commit message and Misc/NEWS.
--
___
Python tracker
<http://bugs.python.org/issue13
Richard Oudkerk added the comment:
The test seems to be failing on Windows.
--
nosy: +sbt
status: closed -> open
___
Python tracker
<http://bugs.python.org/issue1
Richard Oudkerk added the comment:
I think the problem is that the __del__ method fails on Windows, maybe because
sys.stdout and sys.__stderr__ have been replaced by None.
Consider the following program:
import os
class C:
def __del__(self, write=os.write):
write(1, b
Richard Oudkerk added the comment:
I will try a fix.
--
___
Python tracker
<http://bugs.python.org/issue1545463>
___
___
Python-bugs-list mailing list
Unsubscribe:
Richard Oudkerk added the comment:
On Windows my encoding for stdout, stderr is "cp1252" which is implemented in
pure python.
By the time that _PyGC_DumpShutdownStats() runs the encoding.cp1252 module has
been purged so stdout and stderr are broken.
I am afraid I will have to lea
Richard Oudkerk added the comment:
> If the name is a qualified dotted name, it will be split and the first
> part becomes the __module__.
That will not work correctly if the module name has a dot in it.
--
nosy: +sbt
___
Python tracker
Changes by Richard Oudkerk :
--
nosy: +sbt
___
Python tracker
<http://bugs.python.org/issue17969>
___
___
Python-bugs-list mailing list
Unsubscribe:
Richard Oudkerk added the comment:
> In general, deallocators should have no side effects, I think.
> Releaseing the GIL is certainly a side effect.
Notice that socket and file objects also release the GIL when being
deallocated. At least for sockets close() can block (e.g. if you y
Richard Oudkerk added the comment:
> We can consider two options then:
> 1) A multiprocessing specific fix. Removing this handle close gil
> release (which is superfluous, since these calls aren't blocking in any
> real sense) will certainly remove _this_ instance
Richard Oudkerk added the comment:
When pickling a class (or instance of a class) there is already a check
that the invariant
getattr(sys.modules[cls.__module__], cls.__name__) == cls
holds.
>>> import pickle
>>> class A: pass
...
>>> A.__module__ = '
Richard Oudkerk added the comment:
Kristjan, could you confirm whether joining the pool explicitly before shutdown
(in the way I suggested earlier) fixes the problem. I think it should -- at
shutdown you won't switch to a thread if it has already been j
New submission from Richard Oudkerk:
In the attached file is an experimental implementation of an AsyncPopen
class. It should work for Python 3.3, 3.4 on Unix and Windows. Unlike
http://code.google.com/p/subprocdev
(see #1191964) this does not depend on using time.sleep() and polling.
It
Richard Oudkerk added the comment:
>From the docs:
qsize()
Return the approximate size of the queue. Because of
multithreading/multiprocessing semantics, this number
is not reliable.
Adding a short sleep before calling qsize() and empty() should make things
appear to work.
Richard Oudkerk added the comment:
On 15/05/2013 10:25pm, Andre Dias wrote:
> But qsize() is working. what is not working is empty()
empty() returns False when there is data in the underlying pipe. But
the data does not enter the pipe until a background thread has written
it to the p
Richard Oudkerk added the comment:
On 15/05/2013 11:33pm, Andre Dias wrote:
> But the example program has no races, no threads, nothing.
> empty() is returning TRUE even though qsize() is >0 (which actually is)
> And it happens almost every time I run that small example.
> I had
Richard Oudkerk added the comment:
I have done an updated patch. It no longer special cases Windows, so realloc()
is always used for enlarging the buffer (except when fstat() is missing).
Antoine, do you think this is ready to commit?
--
Added file: http://bugs.python.org/file30287
Changes by Richard Oudkerk :
Removed file: http://bugs.python.org/file26986/readall-benchmark.py
___
Python tracker
<http://bugs.python.org/issue15758>
___
___
Python-bug
Richard Oudkerk added the comment:
The line
sock = socket.socket(socket.AF_UNIX, socket.SOCK_DGRAM)
overwrites the old broken socket with a new one with the same fd. The old
socket's destructor closes the fd of the new socket.
--
nosy:
Richard Oudkerk added the comment:
Rather than
self.sock = None
I would do
self.sock.close()
which should work better for non-refcounted Pythons.
Of course it would be better to do this immediately after forking (i.e. before
any more fds are created), otherwise you could still
Richard Oudkerk added the comment:
Updated patch adressing Antoine's comments.
--
Added file: http://bugs.python.org/file30291/readall.patch
___
Python tracker
<http://bugs.python.org/is
Changes by Richard Oudkerk :
Removed file: http://bugs.python.org/file26985/readall-combined.patch
___
Python tracker
<http://bugs.python.org/issue15758>
___
___
Pytho
Changes by Richard Oudkerk :
Added file: http://bugs.python.org/file26986/readall-benchmark.py
___
Python tracker
<http://bugs.python.org/issue15758>
___
___
Python-bug
Changes by Richard Oudkerk :
Removed file: http://bugs.python.org/file30287/readall.patch
___
Python tracker
<http://bugs.python.org/issue15758>
___
___
Python-bugs-list m
Changes by Richard Oudkerk :
Added file: http://bugs.python.org/file30293/readall.patch
___
Python tracker
<http://bugs.python.org/issue15758>
___
___
Python-bugs-list m
Changes by Richard Oudkerk :
Removed file: http://bugs.python.org/file30291/readall.patch
___
Python tracker
<http://bugs.python.org/issue15758>
___
___
Python-bugs-list m
Richard Oudkerk added the comment:
New patch.
--
___
Python tracker
<http://bugs.python.org/issue15758>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Richard Oudkerk :
Added file: http://bugs.python.org/file30295/readall.patch
___
Python tracker
<http://bugs.python.org/issue15758>
___
___
Python-bugs-list m
Changes by Richard Oudkerk :
Removed file: http://bugs.python.org/file30293/readall.patch
___
Python tracker
<http://bugs.python.org/issue15758>
___
___
Python-bugs-list m
Changes by Richard Oudkerk :
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Richard Oudkerk added the comment:
Given that the change could only be made to 3.4, and we already have
concurrent.futures.ThreadPoolExecutor, I am not sure there is much point to
such a change now.
--
nosy: +sbt
___
Python tracker
<h
Richard Oudkerk added the comment:
I don't understand what you mean by "explicit message passing" and
"call-and-response model".
--
___
Python tracker
<http:
Richard Oudkerk added the comment:
As far as I can see they are mostly equivalent. For instance, ApplyResult (the
type returned by Pool.apply_async()) is virtually the same as a Future.
When you say "explicit message passing", do you mean creating a queue and
making the worker
Richard Oudkerk added the comment:
> It's a very different architecture from that assumed by futures,
> so you need to drop down to the pool layer rather than using the
> executor model.
AIUI an ThreadPoolExecutor object (which must be explicitly created)
represents a thread/pro
Changes by Richard Oudkerk :
--
nosy: +sbt
___
Python tracker
<http://bugs.python.org/issue6461>
___
___
Python-bugs-list mailing list
Unsubscribe:
Richard Oudkerk added the comment:
I understand that a thread pool (in the general sense) might be used to
amortise the cost. But I think you would probably have to write this from
scratch rather than use the ThreadPool API.
The ThreadPool API does not really expose anything that the
Changes by Martin Richard :
--
nosy: +martius
___
Python tracker
<http://bugs.python.org/issue22638>
___
___
Python-bugs-list mailing list
Unsubscribe:
Martin Richard added the comment:
Hi,
Actually, closing and creating a new loop in the child doesn't work either, at
least on Linux.
When, in the child, we call loop.close(), it performs:
self.remove_reader(self._ssock)
(in selector_events.py, _close_self_pipe() around line 85)
Bot
Martin Richard added the comment:
Guido,
Currently in my program, I manually remove and then re-adds the reader to the
loop in the parent process right after the fork(). I also considered a dirty
monkey-patching of remove_reader() and remove_writer() which would act as the
original versions
Martin Richard added the comment:
I said something wrong in my previous comment: removing and re-adding the
reader callback right after the fork() is obviously subject to a race condition.
I'll go for the monkey patching.
--
___
Python tr
Martin Richard added the comment:
Currently, this is what I do in the child after the fork:
>>> selector = loop._selector
>>> parent_class = selector.__class__.__bases__[0]
>>> selector.unregister = lambda fd: parent_class.unregister(selector, fd)
New submission from Martin Richard:
Hi,
I would like to submit 3 trivial modifications which break a cycle each. It is
not much, but those three cycles caused a lot of objects to be garbage
collected. They can now be freed using the reference counting mechanism, and
therefore, reduce the
Changes by Martin Richard :
--
components: +asyncio
nosy: +gvanrossum, haypo, yselivanov
type: -> performance
versions: +Python 3.4
___
Python tracker
<http://bugs.python.org/issu
Martin Richard added the comment:
I updated the selector patch so BaseSelector.get_key() raises KeyError if the
mapping is None. All the (non skipped) tests in test_selectors.py passed.
Anyway, if there is an other problem with freeing the mapping object (I don't
know, maybe "re
Changes by Martin Richard :
--
nosy: +martius
___
Python tracker
<http://bugs.python.org/issue17911>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Richard Hansen:
PyBuffer_ToContiguous() has an off-by-one error when copying a buffer it thinks
is non-contiguous.
To reproduce, put the following in foo.pyx and compile with Cython v0.21.2:
cpdef foo():
cdef unsigned char[:] v = bytearray("te
New submission from Richard Hansen:
According to
https://docs.python.org/2/c-api/buffer.html#the-new-style-py-buffer-struct if
the suboffsets member of Py_buffer is non-NULL and all members of the array are
negative, the buffer may be contiguous.
PyBuffer_IsContiguous() does not behave this
Changes by Richard Hansen :
--
type: -> behavior
___
Python tracker
<http://bugs.python.org/issue23352>
___
___
Python-bugs-list mailing list
Unsubscrib
Richard Hansen added the comment:
> The patch has an obvious syntax error :-)
Doh!
> Other than that, adding a comment would be nice.
Agreed, will do.
> Bonus points if you can write a test (3.x has infrastructure for that, see
> Lib/test/test_buffer.py).
I'll tak
Richard Hansen added the comment:
I've attached a new version of the patch. Suggestions for simplifying the test
code would be appreciated.
--
Added file: http://bugs.python.org/file37916/PyBuffer_IsContiguous_v2.patch
___
Python tracker
Changes by Richard Hansen :
--
versions: +Python 3.2, Python 3.3
___
Python tracker
<http://bugs.python.org/issue23352>
___
___
Python-bugs-list mailing list
Unsub
Changes by Richard Hansen :
--
versions: -Python 3.2, Python 3.3
___
Python tracker
<http://bugs.python.org/issue23352>
___
___
Python-bugs-list mailin
Changes by Richard Hansen :
--
title: memoryview.to_bytes() and PyBuffer_ToContiguous() off-by-one error for
non-contiguous buffers -> PyBuffer_ToContiguous() off-by-one error for
non-contiguous buffers
___
Python tracker
<http://bugs.pyth
Richard Hansen added the comment:
> People might rely on the fact that contiguous implies suboffsets==NULL.
Cython (currently) relies on all-negatives being acceptable and equivalent to
suboffsets==NULL. See:
https://github.com/cython/cython/pull/367
http://thread.gmane.
Richard Hansen added the comment:
(The following message is mostly off-topic but I think it is relevant to those
interested in this issue. This message is about the clarity of the
documentation regarding flag semantics, and what I think the flags should mean.)
> Cython doesn't fo
Richard Hansen added the comment:
Attached is a documentation patch that adds what I said in msg235141. I doubt
everyone will agree with the changes, but maybe it will be a useful starting
point.
(Despite not having an asterisk next to my username, I have signed the
contributor agreement
Changes by Richard Hansen :
Added file: http://bugs.python.org/file37953/doc_c-api_buffer.patch
___
Python tracker
<http://bugs.python.org/issue23352>
___
___
Python-bug
Changes by Richard Hansen :
Removed file: http://bugs.python.org/file37952/doc_c-api_buffer.patch
___
Python tracker
<http://bugs.python.org/issue23352>
___
___
Python-bug
Changes by Richard Hansen :
Removed file: http://bugs.python.org/file37953/doc_c-api_buffer.patch
___
Python tracker
<http://bugs.python.org/issue23352>
___
___
Python-bug
Changes by Richard Hansen :
Added file: http://bugs.python.org/file37954/doc_c-api_buffer.patch
___
Python tracker
<http://bugs.python.org/issue23352>
___
___
Python-bug
Richard Hansen added the comment:
> This leaves me +-0 for the change, with the caveat that applications
> might break.
How might an application break with this change? Compared to the current
PyBuffer_IsContiguous(), the patched version is the same except it returns true
for a wider
Richard Hansen added the comment:
>> When I compile and run the above (latest Cython from Git master), I
>> get:
>>
>> ()
>> ()
>
> With Cython version 0.20.1post0 I get:
>
> >>> foo.foo()
> (-1,)
> (-1,)
>
> If you get
Richard Hansen added the comment:
>> How might an application break with this change?
>
>assert(view->suboffsets == NULL);
Fair point.
--
___
Python tracker
<http://bugs.pyt
Richard Hansen added the comment:
My preference is to apply the patch, of course. There is a legitimate concern
that it will break existing code, but I think there are more points in favor of
applying the patch:
* there exists code that the current behavior is known to break
* it's e
New submission from Richard Dymond:
importlib.import_module() sometimes fails to import a module that has just been
written to the filesystem, aborting with an ImportError.
Example output when executing the attached file with Python 3.3 or 3.4:
Wrote tmpwbzb35.py
Successfully imported
Martin Richard added the comment:
I read the patch, it looks good to me for python 3.5. It will (obviously) not
work with python 3.4 since self._selector won't have an _at_fork() method.
I ran the tests on my project with python 3.5a1 and the patch, it seems to work
as expected: ie. w
Martin Richard added the comment:
In that case, I suggest a small addition to your patch that would do the trick:
in unix_events.py:
+def _at_fork(self):
+super()._at_fork()
+self._selector._at_fork()
+self._close_self_pipe()
+self._make_self_pipe
Martin Richard added the comment:
The goal of the patch is to create a duplicate selector (a new epoll()
structure with the same watched fds as the original epoll). It allows to remove
fds watched in the child's loop without impacting the parent process.
Actually, it's true tha
Martin Richard added the comment:
Hi,
My patch was a variation of haypo's patch. The goal was to duplicate the
loop and its internal objects (loop and self pipes) without changing much
to its state from the outside (keeping callbacks and active tasks). I
wanted to be conservative with
Martin Richard added the comment:
015-05-26 20:40 GMT+02:00 Yury Selivanov :
>
> Yury Selivanov added the comment:
> The only solution to safely fork a process is to fix loop.close() to
> check if it's called from a forked process and to close the loop in
> a safe way (t
Changes by Richard Futrell :
--
nosy: canjo
priority: normal
severity: normal
status: open
title: Inconsistent behavior between set and dict_keys/dict_items: for
non-iterable object x, set().__or__(x) raises NotImplementedError, but
{}.keys().__or__(x) raises TypeError
type: behavior
Martin Richard added the comment:
Hi,
I would like to update this patch so it can finally land in cpython, hopefully
3.6.
tl;dr of the thread:
In a nutshell, the latest patch from Kristján Valur Jónsson updates
SSLContext.load_cert_chain(certfile, keyfile=None, password=None) and
Martin Richard added the comment:
You are right.
And if certfile and keyfile (args of load_cert_chain()) accept file-like
objects, we agree that cafile (load_verify_location()) should accept them too?
--
___
Python tracker
<http://bugs.python.
Martin Richard added the comment:
I'm not sure I know how to do this correctly: I lack of experience both
with openssl C API and writing python modules in C.
It may be more flexible, but unless the key is protected/crypted somehow,
one would need a string or bytes buffer to hold the key
New submission from Martin Richard:
An exception can be raised in SubprocessTransport.__init__() from
SubprocessTransport._start() - for instance because an exception is raised in
the preexec_fn callback.
In this case, the calling function never gets a reference to the transport
object, and
New submission from Richard Neumann:
The class subprocess.CompletedProcess is currently lacking a __bool__() method.
It might be a practical feature to have the possibility to evaluate a
CompletedProcess instance in an if/else block without the necessity to handle
the exception raised by
Richard Neumann added the comment:
A useless use case is attached.
Basically it boils down to having the ability to evaluate the CompletedProcess
directly by if/else rather than comparing its returncode attribute to zero each
time or handling the exception raised by check_returncode().
I use
New submission from Richard Tupper:
resolved
--
components: Windows
files: Garcinia Cambogia Free Trial UK.html
messages: 254940
nosy: omskinbourbe1977, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Bug
type: enhancement
versions
Richard PALO added the comment:
I tried this patch out on pkgsrc, it does seem reasonable and appropriate. So
+1 from me.
It does only look for libraries the actual $PREFIX directory used by packaging
systems such as pkgsrc and csw. (typically /usr/local, /opt/local or /opt/csw
in the case
Richard PALO added the comment:
I notice similar problems, as found when running the test suite for lxml 3.5.0
on python2.7
==
ERROR: test_etree_parse_io_error (lxml.tests.test_io.ETreeIOTestCase
901 - 1000 of 1064 matches
Mail list logo
