Richard Oudkerk shibt...@gmail.com added the comment:
Every use of _get_osfhandle() should be guarded by _Py_VerifyFd().
Grepping through the source it seems that that is now true, but we could
instead use
#define _PY_GET_OSFHANDLE(fd) _Py_VerifyFd(fd) ? _get_osfhandle(fd
Richard Oudkerk shibt...@gmail.com added the comment:
Sorry about that...
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15261
___
___
Python
New submission from Richard Oudkerk shibt...@gmail.com:
If I create a venv on Windows called py3 then py3/Scripts/Activate.ps1
defines the prompt to be
function prompt {
Write-Host -NoNewline -ForegroundColor Green [(py3) ]
_OLD_VIRTUAL_PROMPT
}
However this prompt
New submission from Richard Oudkerk shibt...@gmail.com:
With unix, and a source build, sysconfig.get_config_var('srcdir') and
sysconfig.get_path('include') misbehave:
user@mint-vm ~/Repos/cpython $ cd /
user@mint-vm / $ ~/Repos/cpython/python
Python 3.3.0b1 (default:671894ae19a2, Jul 16
New submission from Richard Oudkerk shibt...@gmail.com:
For Unix I follow the practice suggested in README of running configure from a
subdir of the main python directory, eg
mkdir release
cd release
../configure
make
But if I create a venv then I cannot use it to compile C
New submission from Richard Oudkerk shibt...@gmail.com:
On Windows I can't use a source build of Python to create a venv which will
compile C extensions because pyconfig.h cannot be found. For example
running build
running build_ext
building 'demo' extension
creating build
Richard Oudkerk shibt...@gmail.com added the comment:
The attached patch works for me.
--
keywords: +patch
Added file: http://bugs.python.org/file26395/build_ext.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15367
Richard Oudkerk shibt...@gmail.com added the comment:
The attached patch seems to fix the problem.
--
keywords: +patch
Added file: http://bugs.python.org/file26397/distutils-sysconfig.patch
___
Python tracker rep...@bugs.python.org
http
Richard Oudkerk shibt...@gmail.com added the comment:
Updated patch. Old one broke test_distutils...
--
Added file: http://bugs.python.org/file26399/distutils-sysconfig.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Richard Oudkerk shibt...@gmail.com added the comment:
Updated patch which does not fail test_distutils.
--
Added file: http://bugs.python.org/file26400/build_ext.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15367
Richard Oudkerk shibt...@gmail.com added the comment:
I don't recall what the issue was the resulted in the check-in that you
mention.
I think it was http://bugs.python.org/issue8577. The issue was about having
srcdir != builddir. The initial patch caused a test failure, and 356d0ea8ea34
Richard Oudkerk shibt...@gmail.com added the comment:
In the attached patch _safe_realpath() is only called after calculating the
absolute path for srcdir.
--
keywords: +patch
Added file: http://bugs.python.org/file26407/sysconf.patch
___
Python
Richard Oudkerk shibt...@gmail.com added the comment:
Updated patch which clarifies that for an installed python on a posix system,
get_config_var('srcdir') == get_path('stdlib').
Eg, if sys.executable == '/usr/local/bin/python3.3' then
get_config_var('srcdir') == '/usr/local/lib/python3.3
Richard Oudkerk shibt...@gmail.com added the comment:
Beyond that, I don't understand why the patch behavior depends on
whether the srcdir is an absolute path or not.
The os.path.isabs() test is actually redundant since os.path.join(base, srcdir)
== srcdir if srcdir is an absolute path. I
Richard Oudkerk shibt...@gmail.com added the comment:
Here is an updated patch which also modifies distutils.sysconfig.
For installed pythons on posix systems it makes
get_config_var('srcdir') == os.path.dirname(get_makefile_filename())
(The older patches would give the same result only
Richard Oudkerk shibt...@gmail.com added the comment:
Forgot to remove some unnecessary code in patch.
--
Added file: http://bugs.python.org/file26427/sysconf.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15364
Richard Oudkerk shibt...@gmail.com added the comment:
I suspect the problem is related to http://bugs.python.org/issue15298.
Basically the global sysconfig module caches the results of parsing Makefile in
Lib/_sysconfigdata.py. This can cause you to get the config vars from an old
configure
Richard Oudkerk shibt...@gmail.com added the comment:
I'd make get_config_var('srcdir') to be None for installed systems,
because the source tree is not available there.
While playing with a version of the patch which returns None for non-source
builds, I found that distutils.support
Richard Oudkerk shibt...@gmail.com added the comment:
Can't you unbind without any changes to the C code by doing
def unbind(f):
if hasattr(f, '__func__'):
return f.__func__
self = getattr(f, '__self__', None)
if self is not None and not isinstance(self
Richard Oudkerk shibt...@gmail.com added the comment:
The problem is that os.wait() is returning when the wrong process exits.
You can fix this by specifying the pid you are waiting for by doing
os.waitpid(pid, 0) instead of os.wait().
Arguably os.popen() and subprocess.communicate() etc
Richard Oudkerk shibt...@gmail.com added the comment:
Actually, if you replace
print(os.popen(uname).read())
with
f = os.popen(uname)
print(f.read())
f.close()
or
with os.popen(uname) as f:
print(f.read())
then things should work
New submission from Richard Oudkerk shibt...@gmail.com:
In the documentation on weakrefs there is the following quote
Note: Weak references to an object are cleared before the object’s
__del__() is called, to ensure that the weak reference callback
(if any) finds the object still
Richard Oudkerk shibt...@gmail.com added the comment:
The weakref is dead but it's still a weakref, and it can be used to
e.g. index a container of existing weakrefs (cf. WeakSet,
WeakKeyDictionary, WeakValueDictionary).
Ah.
I had assumed that since dead weakrefs were unhashable you
Richard Oudkerk shibt...@gmail.com added the comment:
In Python 2.x, when the file object returned by popen() is garbage collected
the process is automatically waited on, collecting the pid of the process.
In Python 3.x a wrapper object is used whose close method wait on the pid.
This close
Richard Oudkerk shibt...@gmail.com added the comment:
A program which depends on the old behaviour would be broken on a
non-refcounted implementation of Python, so I would be inclined to say won't
fix.
However, I think the following patch would restore the old behaviour
diff -r a970054a93fb
Changes by Richard Oudkerk shibt...@gmail.com:
--
nosy: +sbt
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6056
___
___
Python-bugs-list mailing
Richard Oudkerk shibt...@gmail.com added the comment:
ISTM the simplest approach would be to just set self-args in
BaseException.__new__() (like in Georg's patch) but to ignore the possibility
that the user might later set self.args to something stupid wrong:
diff -r 51ac5f06dd04 Objects
Richard Oudkerk shibt...@gmail.com added the comment:
Is it possible that the use of test.support.gc_collect() in test_memoryview
made the difference?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14930
Changes by Richard Oudkerk shibt...@gmail.com:
--
nosy: +sbt
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14501
___
___
Python-bugs-list mailing
Richard Oudkerk shibt...@gmail.com added the comment:
I think env is used for specifying the environment used by the child process
once it has started. env['PATH'] is not used by the parent process to find
program to run.
Having said that, maybe if you used shell=True as well then the shell
Richard Oudkerk shibt...@gmail.com added the comment:
I see that the originally proposed patch is more or less what I suggested
above. Since this has been a critical issue for 5 years, I think such a
minimal patch should be committed even though it is not a complete solution.
It seems to me
Richard Oudkerk shibt...@gmail.com added the comment:
You could just do
Server_1=TestServer(address=(127.0.0.1,5),authkey=bpasskey)
so this is probably a documentation issue. The examples in the documentation
should at least be updated
Richard Oudkerk shibt...@gmail.com added the comment:
Any objection if I commit the last patch before the next beta? This is the one
which on installed Pythons have
get_config_var('srcdir') == os.path.dirname(get_makefile_filename())
on posix systems
Richard Oudkerk shibt...@gmail.com added the comment:
Does get_config_var('srcdir') always return a string or sometimes None?
Always a string.
distutils.support._get_xxmodule_path() is one place which (currently) would
throw an exception if it returned None
Richard Oudkerk shibt...@gmail.com added the comment:
I realize now that the idea of using object.__reduce__(..., 2) would not really
work since many exception classes use non-slot descriptors (unless '__slots__'
attributes were also added as hints of what to serialize).
I think there are two
Richard Oudkerk shibt...@gmail.com added the comment:
Here is a minimal patch against default.
It is a clear improvement on the current situation, even though it still cannot
handle the case
class Error(Exception):
def __init__(self, x):
Exception.__init__(self)
self.x = x
Changes by Richard Oudkerk shibt...@gmail.com:
Added file: http://bugs.python.org/file26537/init_args.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1692335
Richard Oudkerk shibt...@gmail.com added the comment:
ExceptionTests.testAttributes already checks the attributes of unpickled copies
(using all protocols).
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1692335
Richard Oudkerk shibt...@gmail.com added the comment:
BTW, BaseException_init() has the code
Py_XDECREF(self-args);
self-args = args;
Py_INCREF(self-args);
Presumably the Py_XDECREF(self-args) would be better replaced by
Py_CLEAR(self-args
Richard Oudkerk shibt...@gmail.com added the comment:
Or you could simply Py_INCREF(args) before the Py_XDECREF...
But won't self-args point to a broken object while any callbacks triggered by
Py_XDECREF() are run?
An alternative would be
tmp = self-args;
self-args = args
Richard Oudkerk shibt...@gmail.com added the comment:
Patch which adds fix for BaseException_init().
Actually this class of problem seem to be quite common.
BaseException_set_tb() appears to be affected too, as is the code in the
tutorial which introduces setters.
--
Added file
Richard Oudkerk added the comment:
Richard, can the issue be closed?
I guess so (although the change could arguably be back ported).
Pickling of Exception classes is still somewhat dodgy because an example like
class Error(Exception):
def __init__(self, x):
Exception
Changes by Richard Oudkerk shibt...@gmail.com:
--
resolution: - fixed
stage: needs patch - committed/rejected
status: open - closed
type: crash - behavior
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6056
Richard Oudkerk added the comment:
One example is 'srcdir': this value is only useful in the build tree and
there currently is no clean way to signal that you are retrieving a
value that is not useful.
In the particular case of 'srcdir', sysconfig.is_python_build() tells you
whether
Richard Oudkerk added the comment:
But I observe that the same script(with proper modification of file names)
works very well under Linux. After I dive into the source code, I found
Python use execvpe to invoke the child process which _will_ use the PATH
variable to search the executable
Richard Oudkerk added the comment:
What I understand you two as saying is that there seems to be an
undocumented difference in execxxe between unix and windows which has been
carried over to subprocess.
No. There is no difference between the platforms in the behaviour of
os.execvpe
Richard Oudkerk added the comment:
Couldn't the preexec_fn argument of Popen be used instead?
--
nosy: +sbt
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15507
Richard Oudkerk added the comment:
Couldn't the preexec_fn argument of Popen be used instead?
Actually, since Python 3.2 you can just use restore_signals=True.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15507
New submission from Richard Oudkerk:
A patch with docs and tests for the idea I suggested on python-ideas:
http://comments.gmane.org/gmane.comp.python.ideas/15863
To repeat what I wrote there, the current issues with weakref callbacks include:
1. They are rather low level, and working out
Richard Oudkerk added the comment:
I would guess that the process has already terminated (or is being torn down)
but the timeout is not long enough to let the parent join child.
Let's see if increasing the timeout fixes the failures.
--
___
Python
Richard Oudkerk added the comment:
Looks like it is fixed.
--
resolution: - fixed
stage: needs patch - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15525
Richard Oudkerk added the comment:
I don't quite understand the purpose of your suggestions. What can you do
with it help, what you can not do with contextlib.ExitStack, atexit,
__del__ method, weakref.WeakKeyDictionary or weakref.ref? I read the
documentation, but the meaning eludes me
Richard Oudkerk added the comment:
For point 1: global weakref.WeakKeyDictionary is good store for weak refs
with
callbacks.
global weakdict
weakdict[kenny] = weakref.ref(kenny, lambda _: print(you killed kenny!))
That depends on kenny being hashable.
It also surprises me a bit
Richard Oudkerk added the comment:
Updated patch.
get() and put() replaced by peek() and detach(). Added isalive(). Now
finalizer class has no state, i.e. __slots__ == ().
--
Added file: http://bugs.python.org/file26701/finalize.patch
___
Python
Richard Oudkerk added the comment:
In _make_callback, I still think the default error reporting mechanism
should be kept. It can be improved separately.
New patch. This time I have got rid of _make_callback, and just given __call__
an ignored optional argument.
--
Added file: http
Richard Oudkerk added the comment:
In the latest patch, what are broken and priority for?
They are for a subclass used by multiprocessing. But it is premature to worry
about subclassing, so I will take them out.
Also, I would question why atexit is false by default. I would find
Richard Oudkerk added the comment:
Might it be simpler to run doctest over the rst file from the relevant
unittest? (Perhaps with help from test.support.)
--
nosy: +sbt
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15629
Richard Oudkerk added the comment:
the occasional typos can be found by simply run `make doctest` every once
in a while).
But doesn't make doctest attempt to run the doctests using Python 2.x
(because Sphinx does not support Python 3.x
Richard Oudkerk added the comment:
An example from the output of make doctest which fails because Python 2.x is
being used:
**
File library/multiprocessing.rst, line 453, in default
Failed example:
print(p, p.is_alive
Changes by Richard Oudkerk shibt...@gmail.com:
--
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15364
___
___
Python-bugs
Richard Oudkerk added the comment:
I think #15364 is a duplicate of this.
It should be fixed now. Can you check again.
--
nosy: +sbt
resolution: - duplicate
stage: - committed/rejected
status: open - pending
superseder: - sysconfig confused by relative paths
type: - behavior
Changes by Richard Oudkerk shibt...@gmail.com:
--
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15322
___
___
Python-bugs
New submission from Richard Oudkerk:
If the if __name__ == '__main__' idiom is not used on Windows you can get the
recursive starting of new processes.
This is because importing the main module in a child process starts a new child
process as a side effect.
There is a test intended
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/issue15646
Changes by Richard Oudkerk shibt...@gmail.com:
--
resolution: - duplicate
stage: - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15702
Richard Oudkerk added the comment:
Updated patch.
--
Added file: http://bugs.python.org/file26879/finalize.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15528
Richard Oudkerk added the comment:
I have fixed the documentation and examples to say that authentication keys are
byte strings.
--
resolution: - fixed
stage: needs patch - committed/rejected
status: open - closed
___
Python tracker rep
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/issue15412
Richard Oudkerk added the comment:
I think the reason that it is only this buildbot which fails is that the other
Windows buildbots don't use multiple processes. Therefore they don't use a
different dir for each test.
4) change os.startfile() to use ShellExecuteEx and use the hProcess
Richard Oudkerk added the comment:
New patch.
--
Added file: http://bugs.python.org/file26900/finalize.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15528
Richard Oudkerk added the comment:
I don't see why you made has_CancelIoEx part of the module state. Availability
of CancelIoEx only depends on the version of Windows you have, so it will not
change if you reload the module.
BTW, I think you forgot to delete the has_CancelIoEx global
Richard Oudkerk added the comment:
In addition, I plan to actively drop Windows 2000 support post 3.3, so
CancelIO can be presumed to be present.
The function at issue is CancelIoEx() (introduced in Vista) not CancelIo().
I assume WinXP will still be supported
New submission from Richard Oudkerk:
Piping significant amounts of data through a subprocess using
Popen.communicate() is crazily slow on Windows.
The attached program just pushes data through mingw's cat.exe.
Python 3.3:
amount = 1 MB; time taken = 0.07 secs; rate = 13.51 MB/s
amount = 2 MB
Changes by Richard Oudkerk shibt...@gmail.com:
--
keywords: +patch
Added file: http://bugs.python.org/file26953/popen_communicate.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15758
Richard Oudkerk added the comment:
There is a cute way to use operator.attrgetter to produce backwards compatible
pickles using the qualname:
import pickle, copyreg, operator, sys, pickletools, types
class AttrGetter(object):
def __init__(self, name):
self.name = name
def
Richard Oudkerk shibt...@gmail.com added the comment:
I don't think _DummyThread can override __stop(), because of the name
mangling of __private methods. However, the hasattr() approach would
probably work.
Wouldn't a _DummyThread._Thread__stop() method override Thread.__stop()? Like
Richard Oudkerk shibt...@gmail.com added the comment:
Shouldn't test___closure__() also test what happens when the closure is
replaced with None, or a tuple which is too long or too short or contains
non-cell objects?
All of these things seem to be checked when you create a new function using
Richard Oudkerk shibt...@gmail.com added the comment:
The patch causes crashes. If I define
def cell(o):
def f(): o
return f.__closure__[0]
def f():
a = 1
b = 2
def g():
return a + b
return g
g = f()
then I find
g.__closure__ = None; g
Richard Oudkerk shibt...@gmail.com added the comment:
This patch adds a ResourceSharer.stop() method. This is called from
tearDownClass() in the unittest.
--
keywords: +patch
Added file: http://bugs.python.org/file25357/mp_resource_sharer_stop.patch
Richard Oudkerk shibt...@gmail.com added the comment:
New version of patch which does
signal.pthread_sigmask(signal.SIG_BLOCK, range(1, signal.NSIG))
in the thread (is that right?).
It also uses a timeout when trying to join the thread.
--
Added file: http://bugs.python.org
Richard Oudkerk shibt...@gmail.com added the comment:
Warning added to patch.
--
Added file: http://bugs.python.org/file25362/mp_resource_sharer_stop.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14666
Richard Oudkerk shibt...@gmail.com added the comment:
Version of patch which checks invariants in the setter and adds tests.
--
Added file:
http://bugs.python.org/file25363/writable_closure_with_checking.patch
___
Python tracker rep
Richard Oudkerk shibt...@gmail.com added the comment:
the errno codes (EAGAIN etc) are provided only as a compatibility for
posix apps that test errno. On windows, we use the WSA return values
from the api functions and WsaGetLastError().
...
So, the proposed patch is not a change
Richard Oudkerk shibt...@gmail.com added the comment:
New patch which adds timeout to ResourceSharer.stop() which defaults to 0.
When stop() fails it now uses the logger.
pthread_sigmask() only stops this background thread from receiving signals.
Signals will still be delivered to other
Richard Oudkerk shibt...@gmail.com added the comment:
This doesn't change that, and as far as I know, this has worked and
continues to work. errno is supported.
Using your patch, does the following throw an AssertionError?
import os, errno
try:
... os.read(-1, 10)
... except OSError
Richard Oudkerk shibt...@gmail.com added the comment:
I can't work out what is wrong here.
The code does not to account for a partial read of the message from the socket.
The attached patch fixes that, but it does not address the cause of this
failure.
--
keywords: +patch
Added file
Richard Oudkerk shibt...@gmail.com added the comment:
The problems with error numbers seem to be caused by the addition of a new
section in errno.h:
/* POSIX SUPPLEMENT */
#define EADDRINUSE 100
#define EADDRNOTAVAIL 101
...
#define ETXTBSY 139
#define EWOULDBLOCK 140
Richard Oudkerk shibt...@gmail.com added the comment:
According to http://msdn.microsoft.com/en-us/library/5814770t.aspx the
supported errno values in VS2010 are
E2BIG EACCES EAGAIN EBADF ECHILD EDEADLOCK EDOM EEXIST EILSEQ
EINVAL EMFILE ENOENT ENOEXEC ENOMEM ENOSPC ERANGE EXDEV
Richard Oudkerk shibt...@gmail.com added the comment:
There are plenty of other bad exception classes apart from
CalledProcessError, including TimeoutExpired in the same file. In fact I
suspect this is true of the majority of the exception classes in the stdlib
which override __init__. So I
Richard Oudkerk shibt...@gmail.com added the comment:
I have backported the fix for issue #9244 to 2.7. This should fix the hang and
produce a traceback containing a representation of the original error.
--
___
Python tracker rep...@bugs.python.org
Richard Oudkerk shibt...@gmail.com added the comment:
bba131e48852 causes crashes on Windows.
The attached patch fixes the crash and makes test_os pass for me.
However, using PyErr_ExceptionMatches(PyExc_RuntimeError) to check whether to
try again using narrow strings is ugly. Maybe
Richard Oudkerk shibt...@gmail.com added the comment:
TBH I don't understand why it should crash, and therefore how your patch
helps. Trying again using narrow strings should always work; indeed, the
code did that before I touched it. Can you describe how it crashes?
The important part
Richard Oudkerk shibt...@gmail.com added the comment:
Without the check for RuntimeError
os.utime(foo, times=(5,5), ns=(5,5))
raises
TypeError(TypeError: 'str' does not support the buffer interface)
because we have fallen through to the narrow path. The correct error
Richard Oudkerk shibt...@gmail.com added the comment:
Let me recap, just to make sure I have it straight. There are two errors
on Windows:
That's right. The patch looks good and passes for me on Windows.
--
___
Python tracker rep
Richard Oudkerk shibt...@gmail.com added the comment:
There is another problem causing a fatal error in test_posix on Unix.
The attached patch fixes it: *ua-path should be decrefed not ua-path.
--
Added file: http://bugs.python.org/file25452/utime_read_time_arguments.patch
Richard Oudkerk shibt...@gmail.com added the comment:
Looks good to me. You're a core contributor, yes? If not let me know and
I'll commit it.
I will commit.
Though I must admit I'm baffled how I haven't seen that crash. I've run
the unit tests a zillion times on this patch.
Were you
Richard Oudkerk shibt...@gmail.com added the comment:
I'm developing on Linux (64-bit) in case that helps.
I tested it on 32 bit Linux.
I have committed it, but I forgot to put the issue number in the commit message.
--
___
Python tracker rep
Richard Oudkerk shibt...@gmail.com added the comment:
The documentation page for ConnectNamedPipe
(http://msdn.microsoft.com/en-us/library/windows/desktop/aa365146(v=vs.85).aspx)
has a community addition which says that ConnectNamedPipe will appear to
fail with ERROR_NO_DATA (232) if a client
New submission from Richard Oudkerk shibt...@gmail.com:
In version 3.2 and earlier, Process.join() and Connection.poll() treat negative
timeouts as zero timeouts. (Thread.join() does the same.)
In the current 3.3 version, they treat negative timeouts as infinite timeouts.
Also
Richard Oudkerk shibt...@gmail.com added the comment:
I've recently started seeing this failure repeatably on Linux (Ubuntu
Jaunty):
The test is newly enabled. Does repeatably mean you always get the failure?
I have not seen any failures on the Linux buildbots
201 - 300 of 736 matches
Mail list logo
