Richard Oudkerk added the comment:
Updated version which adds checks for handle leaks on Windows.
--
Added file: http://bugs.python.org/file30561/fdleak.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18174
Changes by Richard Oudkerk shibt...@gmail.com:
--
nosy: +sbt
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9122
___
___
Python-bugs-list mailing
New submission from Richard Oudkerk:
Currently when a module is garbage collected its dict is purged by replacing
all values except __builtins__ by None. This helps clear things at shutdown.
But this can cause problems if it occurs *before* shutdown: if we use a
function defined in a module
Richard Oudkerk added the comment:
Do you want something like
f.done() and not f.cancelled() and f.exception() is None
--
nosy: +sbt
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18212
Changes by Richard Oudkerk shibt...@gmail.com:
--
nosy: +pitrou
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18214
___
___
Python-bugs-list
Richard Oudkerk added the comment:
On 15/06/2013 7:11pm, Antoine Pitrou wrote:
Usually garbage collection will end up clearing the module's dict anyway.
This is not true, since global objects might have a __del__ and then hold
the whole module dict alive through a reference cycle. Happily
Richard Oudkerk added the comment:
I think if you use timeit then the code is wrapped inside a function before it
is compiled. This means that your code can mostly use faster local lookups
rather than global lookups.
--
nosy: +sbt
___
Python
Changes by Richard Oudkerk shibt...@gmail.com:
--
stage: committed/rejected -
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18252
___
___
Python
Changes by Richard Oudkerk shibt...@gmail.com:
--
stage: - committed/rejected
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18252
___
___
Python
Changes by Richard Oudkerk shibt...@gmail.com:
--
keywords: +gsoc -patch
resolution: - rejected
stage: - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16507
Richard Oudkerk added the comment:
We don't do non-security updates on Python 2.6 anymore.
As a workaround you might be able to do something like
import sys, multiprocessing
sys.frozen = True# or multiprocessing.forking.WINEXE = True
...
if __name__ == '__main__
Richard Oudkerk added the comment:
I just tried freezing the program
from multiprocessing import freeze_support,Manager
if __name__ == '__main__':
freeze_support()
m=Manager()
l = m.list([1,2,3])
l.append(4)
print(l)
print(repr(l))
using cx_Freeze
Changes by Richard Oudkerk shibt...@gmail.com:
--
resolution: - fixed
stage: - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17018
Richard Oudkerk added the comment:
See also #9573 and #15914.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18122
___
___
Python-bugs-list
Changes by Richard Oudkerk shibt...@gmail.com:
--
resolution: - works for me
stage: - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15198
Richard Oudkerk added the comment:
This is a very similar issue to #17985.
While it may seem counter-intuitive, I don't see how it makes any difference.
Another thread/process might remove the item before you can get it.
I find it very difficult to imagine a real program where you can safely
Richard Oudkerk added the comment:
Why would you use a multi-process queue to pass messages from one part of the
program to another part, in the same process and thread? Why not just use a
deque?
Is this something you actually did, or are you just trying to come up with a
plausible example
Richard Oudkerk added the comment:
Apologies for being dense, but how would you actually use such a loader?
Would you need to install something in sys.meta_path/sys.path_hooks? Would it
make all imports lazy or only imports of specified modules?
--
nosy: +sbt
Richard Oudkerk added the comment:
Shouldn't the import lock be held to make it threadsafe?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17621
Richard Oudkerk added the comment:
I did this to use the same abstraction that was used extensively for
other purposes, instead of recreating the same abstraction with a deque
as its basis.
So you wanted a FIFO queue and preferred the API of Queue to that of deque?
Well it will be *much
Richard Oudkerk added the comment:
unfinished_tasks is simply used as a counter. It is only accessed while
holding self._cond. If you get this error then I think the error text is
correct -- your progam calls task_done() to many times.
The proposed patch silences the sanity check by making
Changes by Richard Oudkerk shibt...@gmail.com:
--
resolution: - fixed
stage: - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15818
Richard Oudkerk added the comment:
I was thinking about the line
self.__dict__.update(state)
overwriting new data with stale data.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17621
Richard Oudkerk added the comment:
1. but should not cause any pratical difficulties -- you have a typo in
'pratical' there.
2. What exactly do you mean by managed queues in the new addition?
Woops. Fixed now see 860fc6a2bd21, 347647a1f798. A managed queue is
one created like
Changes by Richard Oudkerk shibt...@gmail.com:
--
assignee: - docs@python
components: +Documentation -IO, Interpreter Core
nosy: +docs@python
resolution: - fixed
stage: - committed/rejected
status: open - closed
type: behavior -
___
Python
Richard Oudkerk added the comment:
This is really a documentation issue. The doc fix for #18277 covers this.
--
components: +Library (Lib) -Extension Modules
resolution: - wont fix
stage: - committed/rejected
status: open - closed
type: - behavior
Richard Oudkerk added the comment:
I think in Python 3 makefile() returns a TextIOWrapper object by default. To
force the use of binary you need to specfiy the mode:
fileobj = ss.makefile(mode='rb')
--
nosy: +sbt
___
Python tracker rep
Richard Oudkerk added the comment:
When modules are garbage collected the associated globals dict is purged -- see
#18214. This means that all values (except __builtins__) are replaced by None.
To work around this run_path() apparently returns a *copy* of the globals dict
which was created
Richard Oudkerk added the comment:
I think this is a duplicate of #17899.
--
nosy: +sbt
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18332
Changes by Richard Oudkerk shibt...@gmail.com:
--
resolution: - fixed
stage: - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17097
Richard Oudkerk added the comment:
Patch attached.
--
keywords: +patch
Added file: http://bugs.python.org/file30748/buf-readall.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18344
Changes by Richard Oudkerk shibt...@gmail.com:
--
resolution: - fixed
stage: - committed/rejected
status: open - closed
title: multiprocessing.pool.Pool task/worker handlers are not fork safe - Pool
methods can only be used by parent process.
type: behavior -
versions: +Python 2.7
Changes by Richard Oudkerk shibt...@gmail.com:
--
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14206
___
___
Python-bugs
Changes by Richard Oudkerk shibt...@gmail.com:
--
resolution: - fixed
stage: - committed/rejected
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14206
Changes by Richard Oudkerk shibt...@gmail.com:
--
resolution: - fixed
stage: - committed/rejected
status: open - closed
versions: +Python 3.3, Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17261
Richard Oudkerk added the comment:
Reopening because I think this is again a problem for Win64 and 3.x. The Win64
buildbots always seem to crash on test_marshal (and I do too).
It appears to be BugsTestCase.test_loads_2x_code() which crashes, which is
virtually the same
Richard Oudkerk added the comment:
Closing because this is caused by #17206 and is already discussed there.
--
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2286
Changes by Richard Oudkerk shibt...@gmail.com:
--
resolution: - works for me
stage: test needed - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7292
Richard Oudkerk added the comment:
I think I know what's going on here. For socket IO readline() uses a
readahead buffer size of 1.
Why is that? I think that makefile(mode='rb') and fdopen() both create
BufferedReader objects with the same buffer size.
It looks to me like
Richard Oudkerk added the comment:
Using
while True:
if not fileobj.read(8192):
break
instead of
for line in fileobj:
pass
results in higher throughput, but a similar slowdown with makefile(). So this
is not a problem specific
Richard Oudkerk added the comment:
The only real reason for implementing SocketIO in pure Python is because read()
and write() do not work on Windows with sockets. (I think there are also a few
complications involving SSL sockets and the close() method.)
On Windows I have implemented a file
Richard Oudkerk added the comment:
Ah. I had not thought of socket timeouts.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18329
Richard Oudkerk added the comment:
I find that by adding the lines
fileobj.raw.readinto = ss.recv_into
fileobj.raw.read = ss.recv
the speed with makefile() is about 30% slower than with fdopen().
--
___
Python tracker rep
Richard Oudkerk added the comment:
Shouldn't the child process be terminating using os._exit()?
--
nosy: +sbt
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6642
Richard Oudkerk added the comment:
Does that test always fail?
--
nosy: +sbt
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18382
___
___
Python
Richard Oudkerk added the comment:
- would improve POSIX compatibility, it mimics what os.pipe()
does on those OS
I disagree.
On Windows fds can only be inherited if you start processes using the spanwn*()
family of functions. If you start them using CreateProcess() then the
underlying
Richard Oudkerk added the comment:
Oops. I confused os.popen() with os.spawn*(). os.spawnv() IS still
implemented using spawnv() in Python 3.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4708
Changes by Richard Oudkerk shibt...@gmail.com:
--
nosy: +sbt
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18455
___
___
Python-bugs-list mailing
Changes by Richard Oudkerk shibt...@gmail.com:
--
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18344
___
___
Python-bugs
Changes by Richard Oudkerk shibt...@gmail.com:
--
resolution: - fixed
stage: needs patch - committed/rejected
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18344
Richard Oudkerk added the comment:
Thanks for the report.
This should be fixed now in 2.7. (3.1 and 3.2 only get security fixes.)
--
resolution: - fixed
stage: - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
Richard Oudkerk added the comment:
Thanks for the patches!
--
resolution: - fixed
stage: patch review - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17778
Richard Oudkerk added the comment:
RawIOBase.readall() does the sensible thing already. Maybe FileIO should be
allowed to inherit it.
The alternative patch (which probably only works for raw unbuffered case)
diff -r ca54c27a9045 Lib/subprocess.py
--- a/Lib/subprocess.py Tue Aug 21 14:54:22
Richard Oudkerk added the comment:
FileIO.readall() already has an overallocation mechanism which should
yield linear complexity. Perhaps it needs to be tweaked a bit?
(look at new_buffersize in Modules/_io/fileio.c)
I think it needs a bit more than a tweak;-) Looks like it increases
Richard Oudkerk added the comment:
In each loop before calling read() the buffer size is recalculated based on the
amount of space used, causing a realloc *regardless* of how much empty space is
left in the buffer. And each read is only producing a smallish chunk (5120
bytes).
So assuming
Richard Oudkerk added the comment:
The attached patch (readall-resize.patch) makes the resizes only happen when
the buffer is full. It produces
amount = 1 MB; time taken = 0.02 secs; rate = 64.10 MB/s
amount = 2 MB; time taken = 0.03 secs; rate = 64.10 MB/s
amount = 4 MB; time taken = 0.06
Richard Oudkerk added the comment:
Alternative patch (readall-chunks.patch) which delegates to RawIOBase.readall()
if the file cannot be stat-ed or appears to have size zero.
amount = 1 MB; time taken = 0.02 secs; rate = 64.10 MB/s
amount = 2 MB; time taken = 0.02 secs; rate = 128.21 MB/s
Richard Oudkerk added the comment:
It seems we could do both (fix the resizing logic, and fallback on
chunks if the size is unknown).
Combined patch attached.
--
Added file: http://bugs.python.org/file26963/readall-combined.patch
___
Python
Changes by Richard Oudkerk shibt...@gmail.com:
Removed file: http://bugs.python.org/file26953/popen_communicate.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15758
Changes by Richard Oudkerk shibt...@gmail.com:
Removed file: http://bugs.python.org/file26960/readall-chunks.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15758
Changes by Richard Oudkerk shibt...@gmail.com:
Removed file: http://bugs.python.org/file26959/readall-resize.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15758
Changes by Richard Oudkerk shibt...@gmail.com:
Removed file: http://bugs.python.org/file26963/readall-combined.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15758
Richard Oudkerk added the comment:
Here is the patch (with the old ones removed).
Note that the old code mishandled the case where _PyBytes_Resize() failed by
assuming that the old bytes object would still be valid.
I have assumed that stream psuedo-files will never claim to have a size
Richard Oudkerk added the comment:
After playing with the patch on Linux it seems that Linux much prefers the
realloc() scheme to the list-of-chunks scheme.
This new patch only does list-of-chunks on Windows.
--
Added file: http://bugs.python.org/file26985/readall-combined.patch
Richard Oudkerk added the comment:
Attached is an alternative benchmark program which does not use subprocess.
--
Added file: http://bugs.python.org/file26986/readall-benchmark.py
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Changes by Richard Oudkerk shibt...@gmail.com:
Removed file: http://bugs.python.org/file26952/push-thru-cat.py
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15758
Changes by Richard Oudkerk shibt...@gmail.com:
Removed file: http://bugs.python.org/file26970/readall-combined.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15758
Richard Oudkerk added the comment:
What about the method call overhead in RawIO.readall(), and the
different progression of buffer sizes? (the realloc scheme uses larger
and larger read() sizes, while RawIO.readall() uses a constant read()
size).
For this benchmark the call overhead does
New submission from Richard Oudkerk:
Since WindowsError became an alias of OSError, the error number shown in the
stringification of an OSError err can either be a windows error code
(err.winerror) or a posix style error number (err.errno), with no way to tell
which.
For instance
Changes by Richard Oudkerk shibt...@gmail.com:
Added file: http://bugs.python.org/file27002/winerror.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15784
Changes by Richard Oudkerk shibt...@gmail.com:
Removed file: http://bugs.python.org/file27001/winerror.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15784
Richard Oudkerk added the comment:
Well, Error and Errno are rather hard to distinguish
Embarrassingly, I did not even notice the was a difference.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15784
Richard Oudkerk added the comment:
The changeset is 2e587b9bae35.
Georg, could you copy it to your release branch please.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15784
New submission from Richard Oudkerk:
When inspect.getframeinfo() tries to collect lines of context it never shows
the first line (unless context is as big as the number of lines in the file).
The relevant code is
start = lineno - 1 - context//2
try:
lines, lnum
Changes by Richard Oudkerk shibt...@gmail.com:
--
nosy: +sbt
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15818
___
___
Python-bugs-list mailing
Richard Oudkerk added the comment:
Would it simplify matters to stop treating 0,1,2 specially and just add them to
pass_fds instead?
--
nosy: +sbt
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15798
Richard Oudkerk added the comment:
I tried building from out-of-tree with a read-only srcdir, but I found two
other files which the build process tries to create in the source directory:
$(srcdir)/Objects/typeslots.inc
$(srcdir)/Lib/_sysconfigdata.py
--
nosy: +sbt
Richard Oudkerk added the comment:
Richard: what was your use case?
Building on the main host and a VM without having to commit and synchronize
temporary changes. (The VM has read-only access to the host's repositories).
What steps did you take that resulted in getting typeslots.inc
Richard Oudkerk added the comment:
Why is that? python will work just fine if it can't write pyc files.
When I hacked around the _sysconfigdata.py issue, running the created python
produced
Fatal Python error: Py_Initialize: Unable to get the locale encoding
Traceback (most recent call last
Richard Oudkerk added the comment:
It looks like the code which writes the byte-compiled codes checks for and
ignores PermissionError (EACCES, EPERM) and FileExistsError (EEXIST).
However, for me it is EIO which is raised.
--
___
Python tracker rep
New submission from Richard Oudkerk:
As discussed in
http://bugs.python.org/issue15819
trying to run python built outside a read-only source directory fails for me
because OSError(EIO, ...) is raised when importlib tries to write the byte
compiled file. (I built python in a Linux VM
Richard Oudkerk added the comment:
I have opened a new issue:
http://bugs.python.org/issue15833
It is a regression because in Python 3.2 all failures to open the file for
writing were supressed.
But as I said: I'd also be fine with declaring this VM software
unsupported. If this work
Richard Oudkerk added the comment:
If sysconfig._generate_posix_vars() creates the build directory and
pybuilddir.txt (instead of setup.py) then it could write _sysconfigdata.py in
the correct place. Then setup.py would not have to mess with its own sys.path.
One issue with having
Richard Oudkerk added the comment:
Alternative patch.
--
Added file: http://bugs.python.org/file27122/alt_sysconfigdata.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15298
Richard Oudkerk added the comment:
builddir should have added
+(-pydebug if hasattr(sys, gettotalrefcount) else )
Oops, yes.
the installation installs this to the lib-dynload directory, which
maybe is not desired.
The lines
+ -rm $(DESTDIR)$(DESTSHARED)/_sysconfigdata.py
Richard Oudkerk added the comment:
Updated patch.
--
Added file: http://bugs.python.org/file27125/alt_sysconfigdata.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15298
Changes by Richard Oudkerk shibt...@gmail.com:
Removed file: http://bugs.python.org/file27125/alt_sysconfigdata.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15298
Richard Oudkerk added the comment:
Try again.
--
Added file: http://bugs.python.org/file27126/alt_sysconfigdata.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15298
Changes by Richard Oudkerk shibt...@gmail.com:
Added file: http://bugs.python.org/file27127/alt_sysconfigdata.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15298
Changes by Richard Oudkerk shibt...@gmail.com:
Removed file: http://bugs.python.org/file27126/alt_sysconfigdata.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15298
Changes by Richard Oudkerk shibt...@gmail.com:
Removed file: http://bugs.python.org/file27122/alt_sysconfigdata.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15298
Changes by Richard Oudkerk shibt...@gmail.com:
--
nosy: +sbt
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15881
___
___
Python-bugs-list mailing
Richard Oudkerk added the comment:
The documentation needs updating for Python 3 so that a byte string is used.
So the line becomes
s = Array('c', b'hello world', lock=lock)
--
nosy: +sbt
___
Python tracker rep...@bugs.python.org
http
Changes by Richard Oudkerk shibt...@gmail.com:
--
resolution: - fixed
stage: - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15901
New submission from Richard Oudkerk:
Currently rawiobase_read() reads to a bytearray object and then copies the data
to a bytes object.
There is a TODO comment saying that the bytes object should be created
directly. The attached patch does that.
--
files: iobase_read.patch
keywords
Richard Oudkerk added the comment:
I see the same error on Windows (when pressing ^C), but on Linux I get
Error in sys.exitfunc:
Traceback (most recent call last):
File /usr/lib/python2.7/atexit.py, line 28, in _run_exitfuncs
import traceback
File /usr/lib/python2.7/traceback.py, line 3
New submission from Richard Oudkerk:
With Python 2.7 on Windows the following crashes with an assertion:
import os
[43042 refs]
f = open(foobar, wb)
[43048 refs]
os.close(f.fileno())
[43048 refs]
f.close()
Failed assertion
A box pops up with
Program: C
Richard Oudkerk added the comment:
If buffering is off then they all fail the assertion except isatty().
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15904
Richard Oudkerk added the comment:
I suspect the problem is caused by nose's isolate plugin.
With this enabled, a copy of sys.modules is saved before each test and then
restored after the test. This causes garbage collection of newly imported
modules. The destructor for the module type
Richard Oudkerk added the comment:
Actually, I am not so sure it is the isolate plugin. But I do think that
sys.modules is being manipulated somewhere before shutdown.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15881
501 - 600 of 736 matches
Mail list logo
