[issue20505] Remove resolution from selectors and granularity from asyncio
Roundup Robot added the comment: New changeset 75881b85695f by Victor Stinner in branch 'default': Issue #20505: Fix TestLoop, set the clock resolution http://hg.python.org/cpython/rev/75881b85695f -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20505 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20505] Remove resolution from selectors and granularity from asyncio
Charles-François Natali added the comment: Wow, 10 messages in one night... Could you try to gather all your finding at once, because reading so many messages in difficult to follow? GetQueuedCompletionStatus(1 ms)-None took 0.307 ms (monotonic: 0.000 ms) So basically, on Windows, select(1ms) can be non-blocking? If yes, this OS is even more broken than I thought, and using the granularity (in asyncio :-) is fine. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20505 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20505] Remove resolution from selectors and granularity from asyncio
STINNER Victor added the comment:
Victor Since the granularity is back, why not using also the resolution of
the selector in asyncio? :-)
Guido Please, no. This has to stop.
Ok, sorry. If we still have some sporadic failures on UNIX, I think I will
maybe use Charles-François's suggestion: use at least 1 ms for the resolution
in asyncio loop: max(time.get_clock_info('monotonic').resolution, 1e-3).
But it looks like the issue is now fixed again on Windows.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20505
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20505] Remove resolution from selectors and granularity from asyncio
STINNER Victor added the comment: GetQueuedCompletionStatus(1 ms)-None took 0.307 ms (monotonic: 0.000 ms) So basically, on Windows, select(1ms) can be non-blocking? I would not say non-blocking: it's just that select(N milliseconds) waits between N-1 and N milliseconds on Windows when HPET hardware (High Precision Event Timer) is present and enabled. Example: GetQueuedCompletionStatus(10 ms)-None took 9.971 ms (monotonic: 0.000 ms) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20505 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19856] shutil.move() can't move a directory in non-empty directory on Windows
Roundup Robot added the comment: New changeset 51afe7839f8a by Serhiy Storchaka in branch '2.7': Issue #19856: shutil.move() failed to move a directory to other directory http://hg.python.org/cpython/rev/51afe7839f8a New changeset 373ec8711ad0 by Serhiy Storchaka in branch '3.3': Issue #19856: shutil.move() failed to move a directory to other directory http://hg.python.org/cpython/rev/373ec8711ad0 New changeset 41610ad5c755 by Serhiy Storchaka in branch 'default': Issue #19856: shutil.move() failed to move a directory to other directory http://hg.python.org/cpython/rev/41610ad5c755 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19856 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20505] Remove resolution from selectors and granularity from asyncio
STINNER Victor added the comment: Wow, 10 messages in one night... Could you try to gather all your finding at once, because reading so many messages in difficult to follow? It's not easy because I collect informations from various buildbots and different virtual machines. But I planned to try to summarize the overall work done on time in asyncio, select and selectors. The first problem is that clocks and selectors have a different resolution. On Linux, poll() has a resolution of 1 ms, whereas clock_gettime(CLOCK_MONOTONIC) has a resolution better than 1 us (0.3 us according to my last test). On Windows, GetTickCount64() has a resolution of 15.6 ms, whereas GetQueuedCompletionStatus() has a resolution of 1 ms when HPET is enabled. Note: It looks like GetQueuedCompletionStatus() has the same resolution than GetTickCount64() when HPET is disabled. The second problem is that before my changes asyncio expected selector.select(timeout) to take at least timeout seconds, whereas it may take 1 or 2 ms less than timeout. This difference is very small (1 ms), but it's enough to create a busy loop. This busy loop is quite short (1 ms), but it may occur each time than call_at() or call_later() is used (ex: each time syncio.sleep() is used). Theorical resolution of selectors (resolution of the C types): * poll, epoll, GetQueuedCompletionStatus: 1 ms (10^-3) * select: 1 us (10^-6) * kqueue: 1 ns (10^-9) Effective resolution of selectors: * poll, epoll: 1 ms... but may sleep 1 or 2 ms less than the timeout, ex: on Linux, epoll_wait(100) (100 ms) took 99.6 ms according to clock_gettime(CLOCK_MONOTONIC) * GetQueuedCompletionStatus, HPET enabled: 1 ms... but may sleep 1 ms less than the timeout. Example on Windows with HPET enabled, GetQueuedCompletionStatus(10 ms) took 9.971 ms according to the performance counter) * GetQueuedCompletionStatus, HPET disabled: 15.6 ms For select, kqueue, I don't have reliable numbers, but I'm less worried by them since a Python application is usually slower than the resolution of these selectors. Effective resolution of clocks (according to tables in PEP 418): * QueryPerformanceCounter(): 10 ns * clock_gettime(CLOCK_MONOTONIC) on Linux: 322 ns * GetTickCount64(): 15.6 ms To fix the busy loop, poll and epoll selectors have been modified to round the timeout away from zero, instead of rounding towards zero. So a timeout of 1 ns is converted to a timeout of 1 ms instead of 0. On Windows, the clock resolution (15.6 ms) is worse than the resolution of the selector (~1 ms). The problem is that for timeout smaller than 15.6 ms, the clock value is unchanged after the sleep. So asyncio now uses the resolution of the clock to check if a scheduled task should be executed. asyncio now has a unit test scheduling task with very short delay (between 10 ms and 0.1 ns) and counts the number of calls to _run_once() to detect busy loops. The unit test knows that the selector sometimes sleep 1 or 2 ms less than the timeout and tolerates that in its checks. For selectors, select and kqueue still towards zero. I reopened #20320 which has a patch to round aways from zero and so avoids very short busy loop (1 us). If the test_timeout_rounding() test still fail on UNIX even if #20320 is fixed, we should use a more coarse resolution in asyncio event loop (BaseEventLoop._clock_resolution). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20505 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20320] select.select(timeout) and select.kqueue.control(timeout) must round the timeout to the upper bound
STINNER Victor added the comment: According to my last tests, we should still round select and kqueue timeout away from zero. http://bugs.python.org/issue20505#msg210908 -- resolution: invalid - status: closed - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20320 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19856] shutil.move() can't move a directory in non-empty directory on Windows
Changes by Serhiy Storchaka storch...@gmail.com: -- resolution: - fixed stage: patch review - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19856 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20505] Remove resolution from selectors and granularity from asyncio
Roundup Robot added the comment: New changeset 03cb6ddc7040 by Victor Stinner in branch 'default': Issue #20505: Improve debug info in asyncio event loop http://hg.python.org/cpython/rev/03cb6ddc7040 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20505 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20505] Remove resolution from selectors and granularity from asyncio
Roundup Robot added the comment: New changeset 9c1840e8d643 by Victor Stinner in branch 'default': Issue #20505: Oops, only print debug info if selector.select(timeout) took less http://hg.python.org/cpython/rev/9c1840e8d643 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20505 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20505] Remove resolution from selectors and granularity from asyncio
Charles-François Natali added the comment: It's not easy because I collect informations from various buildbots and different virtual machines. But I planned to try to summarize the overall work done on time in asyncio, select and selectors. Thanks for the summary. The first problem is that clocks and selectors have a different resolution. On Linux, poll() has a resolution of 1 ms, whereas clock_gettime(CLOCK_MONOTONIC) has a resolution better than 1 us (0.3 us according to my last test). time() having a better resolution than select() isn't an issue, so we're good. On Windows, GetTickCount64() has a resolution of 15.6 ms, whereas GetQueuedCompletionStatus() has a resolution of 1 ms when HPET is enabled. Note: It looks like GetQueuedCompletionStatus() has the same resolution than GetTickCount64() when HPET is disabled. OK, so basically this means that with HPET, select() does block, but the clock resolution is too low, and reports an inaccurate elapsed time (and sometimes returns 0). So actually, no busy loop occurs even in this case. Wouldn't it be possible to use another clock for asyncio on Windows? I find surprising that we can't get better than 15.6ms with HPET... -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20505 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20505] Remove resolution from selectors and granularity from asyncio
Roundup Robot added the comment: New changeset a631b01d1715 by Victor Stinner in branch 'default': Issue #20505: use also the monotonic time to decide if asyncio debug traces http://hg.python.org/cpython/rev/a631b01d1715 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20505 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20505] Remove resolution from selectors and granularity from asyncio
STINNER Victor added the comment: More debug traces, Windows 7 with HPET enabled: asyncio: IocpProactor.select(10. ms) took 9.486 ms (monotonic=0.000 ms, clock res=15.600 ms) asyncio: IocpProactor.select(0.0010 ms) took 0.942 ms (monotonic=0.000 ms, clock res=15.600 ms) asyncio: IocpProactor.select(0. ms) took 0.553 ms (monotonic=0.000 ms, clock res=15.600 ms) asyncio: IocpProactor.select(0. ms) took 0.517 ms (monotonic=0.000 ms, clock res=15.600 ms) asyncio: SelectSelector.select(0.1000 ms) took 2.276 ms (monotonic=0.000 ms, clock res=15.600 ms) asyncio: SelectSelector.select(1. us) took 30.810 us (monotonic=0.000 us, clock res=15600.100 us) asyncio: SelectSelector.select(0.0100 us) took 30.350 us (monotonic=0.000 us, clock res=15600.100 us) asyncio: SelectSelector.select(0.0001 us) took 28.930 us (monotonic=0.000 us, clock res=15600.100 us) Note: IocpProactor.select() rounds the timeout aways from zero with a resolution of 1 ms, whereas SelectSelector.select() rounds towards zero. It may explain why IocpSelector sleeps at least 500 us, whereas SelectSelector sleeps sometimes 30 us. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20505 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20505] Remove resolution from selectors and granularity from asyncio
STINNER Victor added the comment: Windows 7, HPET disabled: asyncio: IocpProactor.select(100. ms) took 99.871 ms (monotonic=109.000 ms, clock res=15.600 ms) asyncio: IocpProactor.select(10. ms) took 3.779 ms (monotonic=16.000 ms, clock res=15.600 ms) asyncio: SelectSelector.select(100. ms) took 99.608 ms (monotonic=109.000 ms, clock res=15.600 ms) asyncio: SelectSelector.select(10. ms) took 2.830 ms (monotonic=16.000 ms, clock res=15.600 ms) asyncio: SelectSelector.select(1. us) took 42.760 us (monotonic=0.000 us, clock res=15600.100 us) asyncio: SelectSelector.select(0.0100 us) took 42.220 us (monotonic=0.000 us, clock res=15600.100 us) asyncio: SelectSelector.select(0.0001 us) took 41.530 us (monotonic=0.000 us, clock res=15600.100 us) If you only look at the monotonic time, we always get elapsed timeout with IocpProactor, but not with SelectSelector.select(). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20505 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20320] select.select(timeout) and select.kqueue.control(timeout) must round the timeout to the upper bound
STINNER Victor added the comment: Just so it's clear, those bugs are theoretical: whether you pass 1e-7/1e-10 or 0 to select/kqueue is exactly the same (entering/leaving the syscall takes some time)... After many many tests with asyncio (last issue: #20505), I disagree with you. It has a real impact. Can someone please review my new patch? I now think that select.select() should also be fixed in Python 3.4 to be consistent with the new select.poll() and select.epoll.poll() behaviour (timeout rounding). See msg210914 and msg210915 ( http://bugs.python.org/issue20505#msg210914 ): IocpSelector sleeps at least 0.5 ms (of perf counter) even with a timeout of 1 nanosecond, whereas SelectSelector sleeps sometimes 0.030 ms which looks like a non-blocking call. I tested asyncio with the patch to round select timeout away from zero: * With HPET disabled, SelectSelector sleeps at least 15 ms according to the monotonic clock (FYI: at least 2 ms according to the perfomance counter) * With HPET enabled, SelectSelector sleeps at least 15 ms according to the monotonic clock (FYI: at least 6.3 ms according to the perfomance counter) These results are the expected behaviour: selectors should at least one unit of the monotonic time (15.6 ms). -- versions: +Python 3.4 -Python 3.5 Added file: http://bugs.python.org/file34034/time_rouding-2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20320 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20591] Let braces be a constant
New submission from DhilipSiva: Make the braces in the Python/future.c as a constant declared in Include/compile.h -- files: constant_braces.patch keywords: patch messages: 210919 nosy: dhilipsiva priority: normal severity: normal status: open title: Let braces be a constant type: enhancement Added file: http://bugs.python.org/file34036/constant_braces.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20591 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20320] select.select(timeout) and select.kqueue.control(timeout) must round the timeout to the upper bound
Charles-François Natali added the comment: STINNER Victor added the comment: Just so it's clear, those bugs are theoretical: whether you pass 1e-7/1e-10 or 0 to select/kqueue is exactly the same (entering/leaving the syscall takes some time)... After many many tests with asyncio (last issue: #20505), I disagree with you. It has a real impact. And I stand by my claim. Quoting your test results: asyncio: IocpProactor.select(10. ms) took 9.486 ms (monotonic=0.000 ms, clock res=15.600 ms) asyncio: IocpProactor.select(0.0010 ms) took 0.942 ms (monotonic=0.000 ms, clock res=15.600 ms) asyncio: IocpProactor.select(0. ms) took 0.553 ms (monotonic=0.000 ms, clock res=15.600 ms) asyncio: IocpProactor.select(0. ms) took 0.517 ms (monotonic=0.000 ms, clock res=15.600 ms) asyncio: SelectSelector.select(0.1000 ms) took 2.276 ms (monotonic=0.000 ms, clock res=15.600 ms) asyncio: SelectSelector.select(1. us) took 30.810 us (monotonic=0.000 us, clock res=15600.100 us) asyncio: SelectSelector.select(0.0100 us) took 30.350 us (monotonic=0.000 us, clock res=15600.100 us) asyncio: SelectSelector.select(0.0001 us) took 28.930 us (monotonic=0.000 us, clock res=15600.100 us) As one can see, when passed a timeout lower than the resolution, e.g. 0.01 usec, select() takes around 30usec, *which is above the timeout* (0.01usec), which is exactly what I claimed. These results are the expected behaviour: selectors should at least one unit of the monotonic time (15.6 ms). That's just wrong. The expected bahavior is that selector.select() should wait at least the *timeout passed*, not the unit of monotonic time (which doesn't mean anything by the way). Now, rounding away from zero for select/kqueue is fine to me, just to be consistent. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20320 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20558] ECONNRESET value in logging.config is valid with Linux [distros]; not valid with *BSD
Vinay Sajip added the comment: 3.3, 3.4 and default branches will be updated in due course. -- versions: -Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20558 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20558] ECONNRESET value in logging.config is valid with Linux [distros]; not valid with *BSD
Roundup Robot added the comment: New changeset 41e49f1c5bd8 by Vinay Sajip in branch '2.7': Issue #20558: Improved implementation of error handling. http://hg.python.org/cpython/rev/41e49f1c5bd8 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20558 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20593] test_importhooks fails on 3.4
New submission from Terry J. Reedy: installed 3.4.0c1: C:\Programs\Python34.32python -m test test_importhooks [1/1] test_importhooks test test_importhooks failed -- Traceback (most recent call last): File C:\Programs\Python34.32\lib\test\test_importhooks.py, line 241, in testImpWrapper m = __import__(mname, globals(), locals(), [__dummy__]) ImportError: spec missing loader 3.3.4 is ok. -- components: Library (Lib), Tests messages: 210924 nosy: terry.reedy priority: normal severity: normal stage: needs patch status: open title: test_importhooks fails on 3.4 type: behavior versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20593 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20593] test_importhooks fails on 3.4
Changes by Terry J. Reedy tjre...@udel.edu: -- nosy: +brett.cannon ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20593 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20589] pathlib.owner() and pathlib.group() raise ImportError on Windows
Antoine Pitrou added the comment:
But owner() and group() don't return the uid or gid: they return the *name* of
the owner or group (respectively). If you want the uid (resp. gid), just use
st_uid (resp. st_gid) as shown in your example.
Under Unix:
p = Path('setup.py')
p.owner()
'antoine'
p.group()
'antoine'
So if you want to fix the issue under Windows, you need to find a way to grap
the file owner's name (and group, if that makes sense under the Windows
permission model).
In the meantime though, perhaps the ImportError should be fixed to a
NotImplementedError under Windows.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20589
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20155] Regression test test_httpservers fails, hangs on Windows
Terry J. Reedy added the comment: Installed 3.4.0c1 on Windows: test test_httpservers failed -- Traceback (most recent call last): File C:\Programs\Python34.32\lib\test\test_httpservers.py, line 309, in test_invalid_requests self.check_status_and_reason(response, 501) File C:\Programs\Python34.32\lib\test\test_httpservers.py, line 264, in check_status_and_reason self.assertEqual(response.status, status) AssertionError: 200 != 501 I know very little about http server stuff. -- nosy: +terry.reedy versions: +Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20155 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18864] Implementation for PEP 451 (importlib.machinery.ModuleSpec)
Terry J. Reedy added the comment: Failure with 3.4.0c1: [170/394/5] test_importlib test test_importlib failed -- Traceback (most recent call last): File C:\Programs\Python34.32\lib\unittest\case.py, line 57, in testPartExecutor yield File C:\Programs\Python34.32\lib\unittest\case.py, line 574, in run testMethod() File C:\Programs\Python34.32\lib\unittest\loader.py, line 32, in testFailure raise exception ImportError: Failed to import test module: test.test_importlib.source.test_abc_loader Traceback (most recent call last): File C:\Programs\Python34.32\lib\unittest\loader.py, line 312, in _find_tests module = self._get_module_from_name(name) File C:\Programs\Python34.32\lib\unittest\loader.py, line 290, in _get_module_from_name __import__(name) File C:\Programs\Python34.32\lib\test\test_importlib\source\test_abc_loader.py, line 73, in module class PyLoaderMock(abc.PyLoader): AttributeError: 'module' object has no attribute 'PyLoader' On the other hand, the test passes on a fresh debug build. -- nosy: +terry.reedy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18864 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20592] test_frozen fails on 3.4.0rc1, windows
R. David Murray added the comment: It was removed as part of 07229c6104b1 by Eric. Perhaps importlib itself is now considered a sufficient test of freezing a module? (I'm not sure that automatically follows, myself.) So the interesting question is why there is a copy in an installed version of 0c1. Is it possible it is left over from a previous install, or did you start with clean directories? -- nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20592 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20320] select.select(timeout) and select.kqueue.control(timeout) must round the timeout to the upper bound
STINNER Victor added the comment: Now, rounding away from zero for select/kqueue is fine to me, just to be consistent. Did you take a look at time_rouding-2.patch? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20320 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20594] fail to compile posixmodule due to name clash with posix_close
New submission from ncopa:
This happens when building with musl libc:
./Modules/posixmodule.c:7849:1: error: conflicting types for 'posix_close'
posix_close(PyObject *self, PyObject *args)
^
In file included from Include/Python.h:36:0,
from ./Modules/posixmodule.c:28:
/usr/include/unistd.h:38:5: note: previous declaration of 'posix_close' was here
int posix_close(int, int);
^
Makefile:1511: recipe for target 'Modules/posixmodule.o' failed
make: *** [Modules/posixmodule.o] Error 1
make: *** Waiting for unfinished jobs
Apparently 'posix_close' has made it to the POSIX standard so that name should
be avoided in python's posix module.c.
https://sourceware.org/ml/glibc-bugs/2013-12/msg00099.html
Fix is trivial:
--- ./Modules/posixmodule.c.orig
+++ ./Modules/posixmodule.c
@@ -7846,7 +7846,7 @@
Close a file descriptor (for low level IO).);
static PyObject *
-posix_close(PyObject *self, PyObject *args)
+posix_closex(PyObject *self, PyObject *args)
{
int fd, res;
if (!PyArg_ParseTuple(args, i:close, fd))
@@ -11262,7 +11262,7 @@
{open,(PyCFunction)posix_open,\
METH_VARARGS | METH_KEYWORDS,
posix_open__doc__},
-{close, posix_close, METH_VARARGS, posix_close__doc__},
+{close, posix_closex, METH_VARARGS, posix_close__doc__},
{closerange, posix_closerange, METH_VARARGS,
posix_closerange__doc__},
{device_encoding, device_encoding, METH_VARARGS, device_encoding__doc__},
{dup, posix_dup, METH_VARARGS, posix_dup__doc__},
--
components: Build
messages: 210930
nosy: ncopa
priority: normal
severity: normal
status: open
title: fail to compile posixmodule due to name clash with posix_close
type: compile error
versions: Python 2.7, Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20594
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20594] fail to compile posixmodule due to name clash with posix_close
Changes by STINNER Victor victor.stin...@gmail.com: -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20594 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20592] test_frozen fails on 3.4.0rc1, windows
Terry J. Reedy added the comment: Since I normally install the 64-bit versions, but 64 bit 0c1 will not install, I put the 32 bit version in a new .32 (bit) directory. I had the same issue with test_importhooks #20593: present and failed in the installation, missing from the repository. It it also supposed to be gone? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20592 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20592] test_frozen fails on 3.4.0rc1, windows
R. David Murray added the comment: Yes (see 176fe1f8496f). (By the way, I don't know if you can do this in your GUI, but how I found the revision was by doing hg log -r removes(Lib/test/test_importhooks.py) which recipe I found via google.) So, it sounds like something may be wrong with the installer? -- nosy: +loewis ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20592 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20595] C89 compliance issue in Python/getargs.c
New submission from Jeffrey Armstrong: The file Python/getargs.c currently uses an array initializer with a runtime variable, causing compile errors on strict C89 compilers. The variables named freelist in vgetargs1() and vgetargskeywords() both use non-constant initializers. The attached patch should correct the issue for the default branch. -- components: Interpreter Core files: getargs.c.default.patch keywords: patch messages: 210933 nosy: Jeffrey.Armstrong priority: normal severity: normal status: open title: C89 compliance issue in Python/getargs.c type: compile error versions: Python 3.4 Added file: http://bugs.python.org/file34037/getargs.c.default.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20595 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20592] test_frozen fails on 3.4.0rc1, windows
Martin v. Löwis added the comment: The installer doesn't contain a test_frozen file, and I get [1/1] test_frozen test test_frozen crashed -- Traceback (most recent call last): File C:\Python34\lib\test\regrtest.py, line 1271, in runtest_inner the_module = importlib.import_module(abstest) File C:\Python34\lib\importlib\__init__.py, line 104, in import_module return _bootstrap._gcd_import(name[level:], package, level) File frozen importlib._bootstrap, line 2230, in _gcd_import File frozen importlib._bootstrap, line 2213, in _find_and_load File frozen importlib._bootstrap, line 2200, in _find_and_load_unlocked ImportError: No module named 'test.test_frozen' 1 test failed: test_frozen when running Terry's command. Terry, are you sure the installation directory was empty before you started the installation? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20592 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20596] Support for alternate wcstok syntax for Windows compilers
New submission from Jeffrey Armstrong: In two locations, the current interpreter code makes some assumptions concerning the syntax of the wcstok() function based solely on the operating system (Windows, in this case). Compilers other than MSVC may (and do) provide alternative wcstok() syntaxes. The first change in the attached patch changes a preprocessor check in Modules/main.c to determine if we're compiling with MSVC rather than just whether we're compiling with Windows. If so, it uses Windows's basic two-argument wcstok() function as it always has. If the compiler isn't MSVC, the code will now default to the Unix method of converting to ASCII first before tokenizing. This change is more sensible because the code should really be checking for the compiler's wcstok() capabilities, not what operating system Python is being compiled for. The second change in the attached patch adds some new code to PC/getpathp.c to support alternate wcstok() syntax in the find_env_config_value() function. A preprocessor check will now determine if we're compiling for MSVC and, if so, default to the three-argument wcstok_s() function. If the almost-compatible Open Watcom compiler is detected, a three-argument, POSIX-like wcstok() function is used. If another compiler is detected, the original two-argument wcstok() is assumed to be adequate. -- components: Interpreter Core, Windows files: wcstok.default.patch keywords: patch messages: 210935 nosy: Jeffrey.Armstrong priority: normal severity: normal status: open title: Support for alternate wcstok syntax for Windows compilers type: compile error versions: Python 3.4 Added file: http://bugs.python.org/file34038/wcstok.default.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20596 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20597] PATH_MAX already defined on some Windows compilers
New submission from Jeffrey Armstrong: On some Windows compilers, the constant PATH_MAX may already be defined, which will cause compile errors on non-MSVC compilers (notably Open Watcom and MinGW). Rather than assume it is not available and define it in all #ifdef MS_WINDOWS cases, it should first be checked for existence. This patch adds said check to Modules/main.c and Python/pythonrun.c. This patch should not affect any existing platforms (including MSVC builds). -- components: Interpreter Core, Windows files: path_max.default.patch keywords: patch messages: 210936 nosy: Jeffrey.Armstrong priority: normal severity: normal status: open title: PATH_MAX already defined on some Windows compilers type: compile error versions: Python 3.3, Python 3.4 Added file: http://bugs.python.org/file34039/path_max.default.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20597 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20594] [PATCH] fail to compile posixmodule due to name clash with posix_close
Changes by ncopa nc...@alpinelinux.org: -- keywords: +patch title: fail to compile posixmodule due to name clash with posix_close - [PATCH] fail to compile posixmodule due to name clash with posix_close Added file: http://bugs.python.org/file34040/posix_close.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20594 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19494] urllib2.HTTPBasicAuthHandler (or urllib.request.HTTPBasicAuthHandler) doesn't work with GitHub API v3 and similar
Chris Angelico added the comment: Patch doesn't apply to 3.4. Apart from the obvious filename change (Lib/urllib2.py - Lib/urllib/request.py), retry_http_basic_auth is distinctly different in the current version. I think this will need a completely separate patch, separately done and tested against 3.4. -- nosy: +Rosuav ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19494 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19494] urllib2.HTTPBasicAuthHandler (or urllib.request.HTTPBasicAuthHandler) doesn't work with GitHub API v3 and similar
Chris Angelico added the comment: Oops, I was reading off the wrong piece of code. It's not distinctly different, actually; it's just different enough that the patch fails. The only difference is that in 3.4 the headers are Unicode strings (so the content gets encoded and decoded). My bad. Will attach a modified patch file that works on 3.4 (is it considered bad form to provide a diff for a patch file?). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19494 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19494] urllib2.HTTPBasicAuthHandler (or urllib.request.HTTPBasicAuthHandler) doesn't work with GitHub API v3 and similar
Changes by Chris Angelico ros...@gmail.com: Added file: http://bugs.python.org/file34041/0001-Add-an-authorization-header-to-the-initial-request.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19494 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19494] urllib2.HTTPBasicAuthHandler (or urllib.request.HTTPBasicAuthHandler) doesn't work with GitHub API v3 and similar
Changes by Chris Angelico ros...@gmail.com: Added file: http://bugs.python.org/file34042/0001-Add-an-authorization-header-to-the-initial-request.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19494 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19494] urllib2.HTTPBasicAuthHandler (or urllib.request.HTTPBasicAuthHandler) doesn't work with GitHub API v3 and similar
Matej Cepl added the comment: Concerning the compatibility with py3k. Yes, of course, I know that py2k is not compatible, but see http://thread.gmane.org/gmane.comp.python.devel/145473 ... I guess the main idea (http_request method overriding) is the same and it could be ported to py3k more or less trivially. My main intent was just to collect any feedback I can get (and learn a bit about the process of getting the patch to the Python). Thanks a lot for helping. Now, I guess we need to create unit tests, right? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19494 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19494] urllib2.HTTPBasicAuthHandler (or urllib.request.HTTPBasicAuthHandler) doesn't work with GitHub API v3 and similar
Changes by R. David Murray rdmur...@bitdance.com: -- nosy: +orsenthil, r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19494 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19494] urllib2.HTTPBasicAuthHandler (or urllib.request.HTTPBasicAuthHandler) doesn't work with GitHub API v3 and similar
Chris Angelico added the comment: Yeah. I first thought Hey, I could just change the file names in the patch and apply it, but then when it failed, I went looking, found the wrong piece of code, and thought it was completely different. Turned out to be not so different after all :) So now you have a Python 3 patch here as well as a Python 2 one; and if you're actively playing with Py2, you might find that you can apply the Py3 one to 2.7. I suspect, though, that this will be called a feature addition, ergo it won't go into 2.7 (and for 3.x, will be deferred until 3.5). I would advise working with the current 3.x branch, as that's your best bet for acceptance; backporting to 2.7 can come later, if it's accepted for that. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19494 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15227] Fatal Python error: PyEval_RestoreThread: NULL tstate on example script..
Changes by Antoine Pitrou pit...@free.fr: -- nosy: +serhiy.storchaka status: pending - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15227 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20594] [PATCH] fail to compile posixmodule due to name clash with posix_close
Antoine Pitrou added the comment: Thanks for the report! I think this should also make it into 3.4 final. -- nosy: +larry, pitrou priority: normal - high stage: - patch review versions: +Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20594 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20595] C89 compliance issue in Python/getargs.c
Changes by Antoine Pitrou pit...@free.fr: -- nosy: +benjamin.peterson, larry ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20595 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20593] test_importhooks fails on 3.4
Changes by Antoine Pitrou pit...@free.fr: -- priority: normal - critical ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20593 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20594] [PATCH] fail to compile posixmodule due to name clash with posix_close
Larry Hastings added the comment: Yes, this can go in. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20594 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20595] C89 compliance issue in Python/getargs.c
Larry Hastings added the comment: Is this more than a theoretical problem? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20595 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20591] Let braces be a constant
Changes by Antoine Pitrou pit...@free.fr: -- nosy: +benjamin.peterson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20591 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20595] C89 compliance issue in Python/getargs.c
Jeffrey Armstrong added the comment: Depending on your compiler, yes, it is more than a theoretical problem. I am building using the Open Watcom compiler, and it chokes on these initializers due to their non-conformance. I would assume some other obscure, non-GNU/non-MSVC/non-Clang compilers might complain as well. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20595 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20595] C89 compliance issue in Python/getargs.c
Benjamin Peterson added the comment: We ought not advertise C89 compliance and not have it. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20595 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20595] C89 compliance issue in Python/getargs.c
Roundup Robot added the comment: New changeset 417a468ae755 by Benjamin Peterson in branch 'default': remove dynamic initializer lists for c89 compliance (closes #20595) http://hg.python.org/cpython/rev/417a468ae755 -- nosy: +python-dev resolution: - fixed stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20595 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19494] urllib2.HTTPBasicAuthHandler (or urllib.request.HTTPBasicAuthHandler) doesn't work with GitHub API v3 and similar
Matej Cepl added the comment: On Tue, Feb 11, 2014 at 02:14:16PM +, Chris Angelico wrote: I suspect, though, that this will be called a feature addition, ergo it won't go into 2.7 (and for 3.x, will be deferred until 3.5). I would advise working with the current 3.x branch, as that's your best bet for acceptance; backporting to 2.7 can come later, if it's accepted for that. Which was one of the reasons why I send the my message to python-...@python.org I would argue however, that this is not a new feature, just a fix of a bug which has been overlooked for long long time. I don’t think I am changing API, just fixing a bug which made urllib2 fail to login into many sites (yes, they are broken and not following RFC). I am not sure I am right, but I guess it is valuable to discuss it. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19494 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20594] [PATCH] fail to compile posixmodule due to name clash with posix_close
Roundup Robot added the comment: New changeset 1d253360d5a6 by Benjamin Peterson in branch '2.7': avoid name clash with posix_close (closes #20594) http://hg.python.org/cpython/rev/1d253360d5a6 New changeset 021dd3c65198 by Benjamin Peterson in branch '3.3': avoid name clash with posix_close (closes #20594) http://hg.python.org/cpython/rev/021dd3c65198 New changeset 400a8e4599d9 by Benjamin Peterson in branch 'default': merge 3.3 (#20594) http://hg.python.org/cpython/rev/400a8e4599d9 -- nosy: +python-dev resolution: - fixed stage: patch review - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20594 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20591] Let braces be a constant
Benjamin Peterson added the comment: I don't really see the point besides foolish consistency. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20591 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20598] argparse docs: '7'.split() is confusing magic
New submission from Thomas Guettler:
I think the docs of argparse still contain confusing magic:
parser.parse_args('7'.split())
You know what it does and I know it. But a lot of people new to Python, don't
understand what this should be.
Please use:
parser.parse_args(['7'])
Close this ticket, if you don't care for people new to Python.
--
assignee: docs@python
components: Documentation
messages: 210950
nosy: docs@python, guettli
priority: normal
severity: normal
status: open
title: argparse docs: '7'.split() is confusing magic
versions: Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20598
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20598] argparse docs: '7'.split() is confusing magic
STINNER Victor added the comment: I agree that '7'.split() looks strange, an explicit list would be more obvious and simpler: ['7']. 'X --foo Y'.split() can be replaced with ['X', '--foo', 'Y']. argparse examples: http://docs.python.org/dev/library/argparse.html#type -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20598 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20598] argparse docs: '7'.split() is confusing magic
STINNER Victor added the comment: @Thomas Guettler: Would you be interested to propose a patch on the source of the documentation directly? You can find the file here: http://hg.python.org/cpython/file/default/Doc/library/argparse.rst -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20598 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20598] argparse docs: '7'.split() is confusing magic
Benjamin Peterson added the comment: I agree that does look weird. However, it's nicely consistent with the the normal case which has multiple arguments like -foo 3 -l.split(). I think this is an excellent thing for newcomers to try out with the interactive shell. :) -- nosy: +benjamin.peterson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20598 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20598] argparse docs: '7'.split() is confusing magic
Benjamin Peterson added the comment: IMO, keeping the string intact is slightly better because it's easier to read than a commandline with a bunch of quotes and commas in the middle. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20598 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20592] test_frozen fails on 3.4.0rc1, windows
Terry J. Reedy added the comment: Since the installation created a new directory, it had to be empty at the moment of creation. However, this was both after the failed installation of 64-bit .0c1 on top of existing 64 bit .0b3 (in the Python34 directory originally used for 3.4.0a1) and before a subsequent retry and re-failure and re-rollback of the 64-bit version. On the hypothesis that msi got confused in all of this and somehow copied the file from one directory to another (or a cosmis ray hit ;-), I uninstalled both bit versions and deleted both directories and started fresh as far as 3.4 and my C: drive are concerned. After installing in this condition, neither test_frozen nor test_importhooks are present. Sorry for the noise. Next time someone reports inexplicable installation problems on python-list, perhaps I will remember to ask if they started completely fresh, as I just did. -- resolution: - invalid stage: needs patch - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20592 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20593] test_importhooks fails on 3.4
Brett Cannon added the comment: test_importhooks no longer exists. I think your install is broken, Terry. -- resolution: - invalid status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20593 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18864] Implementation for PEP 451 (importlib.machinery.ModuleSpec)
Brett Cannon added the comment: Terry has admitted in other bugs he filed that he didn't use a fresh install location, so the test failure is most likely a red herring. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18864 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20593] test_importhooks fails on 3.4
Terry J. Reedy added the comment: By some glitch, it was present (see msg210956), but after a completely clean install, it is not. -- stage: needs patch - committed/rejected ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20593 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17557] test_getgroups of test_posix can fail on OS X 10.8 if more than 16 groups
Miki Tebeka added the comment: I still see this in 3.4rc1 == FAIL: test_getgroups (test.test_posix.PosixTester) -- Traceback (most recent call last): File /private/tmp/Python-3.4.0rc1/Lib/test/test_posix.py, line 780, in test_getgroups set(posix.getgroups() + [posix.getegid()])) AssertionError: Items in the second set but not the first: 33 100 204 398 399 -- nosy: +tebeka ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17557 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20591] Let braces be a constant
STINNER Victor added the comment: If braces becomes a constant, the joke from __future__ import braces doesn't work anymore, so I'm against such change. Python must be fun :) -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20591 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20598] argparse docs: '7'.split() is confusing magic
STINNER Victor added the comment: IMO, keeping the string intact is slightly better because it's easier to read than a commandline with a bunch of quotes and commas in the middle. Many other argparse examples which use list literals. I don't see quotes in 7 string :-) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20598 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20597] PATH_MAX already defined on some Windows compilers
STINNER Victor added the comment: The patch is simple and looks safe. I'm in favor of applying it on Python 3.3 and 3.4. (Python 2.7 is not affect.) @Larry: ok for Python 3.4? -- nosy: +haypo, larry, loewis, serhiy.storchaka ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20597 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20596] Support for alternate wcstok syntax for Windows compilers
STINNER Victor added the comment: IMO your WCSTOK macro should be called Py_WCSTOK and moved to Include/pyport.h, so you can use it in Modules/main.c (please use Unicode for environment variables on Windows). -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20596 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20585] urllib2 unrelease KQUEUE on Mac OSX 10.9+
Andrew Gross added the comment: Thanks, the workaround fixes my issue. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20585 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19494] urllib2.HTTPBasicAuthHandler (or urllib.request.HTTPBasicAuthHandler) doesn't work with GitHub API v3 and similar
Changes by Terry J. Reedy tjre...@udel.edu: Removed file: http://bugs.python.org/file34042/0001-Add-an-authorization-header-to-the-initial-request.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19494 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20599] test_cleanup() of test_builtin failed
New submission from STINNER Victor: http://buildbot.python.org/all/builders/x86%20XP-4%203.x/builds/10150/steps/test/logs/stdio == FAIL: test_cleanup (test.test_builtin.ShutdownTest) -- Traceback (most recent call last): File D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_builtin.py, line 1621, in test_cleanup self.assertEqual([before, after], out.decode().splitlines()) AssertionError: Lists differ: ['before', 'after'] != [] First list contains 2 additional elements. First extra element 0: before - ['before', 'after'] + [] -- messages: 210965 nosy: haypo, serhiy.storchaka priority: normal severity: normal status: open title: test_cleanup() of test_builtin failed versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20599 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20597] PATH_MAX already defined on some Windows compilers
Larry Hastings added the comment: Let's be a little smarter. PATH_MAX isn't used anymore. Just remove the #defines entirely. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20597 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20600] test_create_server_ssl_verify_failed() failure on PPC64 AIX 3.x buildbot
New submission from STINNER Victor: http://buildbot.python.org/all/builders/PPC64%20AIX%203.x/builds/1694/steps/test/logs/stdio == FAIL: test_create_server_ssl_verify_failed (test.test_asyncio.test_events.PollEventLoopTests) -- ssl.SSLError: A failure in the SSL library occurred (_ssl.c:598) During handling of the above exception, another exception occurred: Traceback (most recent call last): File /home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_asyncio/test_events.py, line 692, in test_create_server_ssl_verify_failed self.loop.run_until_complete(f_c) AssertionError: certificate verify failed does not match A failure in the SSL library occurred (_ssl.c:598) == FAIL: test_create_server_ssl_verify_failed (test.test_asyncio.test_events.SelectEventLoopTests) -- ssl.SSLError: A failure in the SSL library occurred (_ssl.c:598) During handling of the above exception, another exception occurred: Traceback (most recent call last): File /home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_asyncio/test_events.py, line 692, in test_create_server_ssl_verify_failed self.loop.run_until_complete(f_c) AssertionError: certificate verify failed does not match A failure in the SSL library occurred (_ssl.c:598) -- messages: 210967 nosy: gvanrossum, haypo priority: normal severity: normal status: open title: test_create_server_ssl_verify_failed() failure on PPC64 AIX 3.x buildbot versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20600 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20505] Remove resolution from selectors and granularity from asyncio
STINNER Victor added the comment: test_timeout_rounding() pass on all major buildbots. test_asyncio hangs on fails on some buildbots, but there are dedicated issues (like #20495 and #20600). I'm closing this one. I reopened the rounding issue for select and kqueue, please help me to close this last issue! #20505 -- For the record, some debug info on Windows: AMD64 Windows7 SP1 3.x: asyncio: IocpProactor.select(10. ms) took 6.764 ms (monotonic=15.000 ms, clock res=15.600 ms) asyncio: SelectSelector.select(100. ms) took 97.473 ms (monotonic=109.000 ms, clock res=15.600 ms) asyncio: SelectSelector.select(100. ms) took 97.397 ms (monotonic=109.000 ms, clock res=15.600 ms) asyncio: SelectSelector.select(0.9998 us) took 32.643 us (monotonic=0.000 us, clock res=15600.100 us) asyncio: SelectSelector.select(0.0098 us) took 28.419 us (monotonic=0.000 us, clock res=15600.100 us) x86 Windows Server 2003 [SB] 3.x: asyncio: IocpProactor.select(100. ms) took 96.972 ms (monotonic=110.000 ms, clock res=15.625 ms) asyncio: IocpProactor.select(10. ms) took 8.663 ms (monotonic=16.000 ms, clock res=15.625 ms) asyncio: SelectSelector.select(100. ms) took 98.644 ms (monotonic=110.000 ms, clock res=15.625 ms) asyncio: SelectSelector.select(10. ms) took 5.911 ms (monotonic=16.000 ms, clock res=15.625 ms) asyncio: SelectSelector.select(0.9998 us) took 75.635 us (monotonic=0.000 us, clock res=15625.000 us) asyncio: SelectSelector.select(0.0098 us) took 74.903 us (monotonic=0.000 us, clock res=15625.000 us) AMD64 Windows Server 2008 [SB] 3.x: asyncio: IocpProactor.select(100. ms) took 95.484 ms (monotonic=109.000 ms, clock res=15.600 ms) asyncio: IocpProactor.select(10. ms) took 1.819 ms (monotonic=15.000 ms, clock res=15.600 ms) asyncio: SelectSelector.select(100. ms) took 97.741 ms (monotonic=109.000 ms, clock res=15.600 ms) asyncio: SelectSelector.select(10. ms) took 1.536 ms (monotonic=16.000 ms, clock res=15.600 ms) asyncio: SelectSelector.select(0.0100 us) took 46.560 us (monotonic=0.000 us, clock res=15600.100 us) asyncio: SelectSelector.select(0.0001 us) took 46.080 us (monotonic=0.000 us, clock res=15600.100 us) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20505 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20597] PATH_MAX already defined on some Windows compilers
Jeffrey Armstrong added the comment: Here's an additional patch removing PATH_MAX from Modules/main.c and Python/pythonrun.c. This solution works fine for me. -- Added file: http://bugs.python.org/file34044/remove_path_max.default.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20597 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19255] Don't wipe builtins at shutdown
STINNER Victor added the comment: test_cleanup() of test_builtin fails: I opened issue #20599 to track this bug. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19255 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19494] urllib2.HTTPBasicAuthHandler (or urllib.request.HTTPBasicAuthHandler) doesn't work with GitHub API v3 and similar
Terry J. Reedy added the comment: Yes, there should be a test. Is there a Python mirror that a test can reliably expect to continue to exist? Both patches have an unusual email section at the top that is not needed for this tracker, and which I have not seen here before. Is this something idiosyncratic to git? I believe I have read elsewhere the recommendation to use 404 to avoid leading info. So taking that into account seems like a good idea. But I am not sure what the manual claims about urllib.request and I won't make the decision about which versions to apply a patch to. -- nosy: +terry.reedy stage: - test needed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19494 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20599] test_cleanup() of test_builtin failed
STINNER Victor added the comment: It's probably linked to recent changes from issue #19255. -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20599 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20505] Remove resolution from selectors and granularity from asyncio
Roundup Robot added the comment: New changeset 360976a6d8b9 by Victor Stinner in branch 'default': Issue #20505: Remove debug code http://hg.python.org/cpython/rev/360976a6d8b9 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20505 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20495] test_read_pty_output() hangs on FreeBSD 7.2 buildbot
STINNER Victor added the comment: I wonder if we just need to make a matrix of which OS versions and which syscalls can handle PTYs correctly, and either put it in the docs or perhaps even refuse to accept PTYs in add_reader/add_writer... Right now, I think that we don't have enough data to decide on which OS and OS versions such error should be raised. But I agree that it would be nice to raise an error instead of hang, crash, or just behave badly. Until that, here is a patch to skip the test on FreeBSD 8.0. The test hangs on FreeBSD 7.2, test_asyncio pass on FreeBSD 9. The FreeBSD 8 buildbot is offline. test_asyncio is skipped on FreeBSD 6.4. -- keywords: +patch Added file: http://bugs.python.org/file34043/skip_read_pty_freebsd72.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20495 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20505] Remove resolution from selectors and granularity from asyncio
STINNER Victor added the comment: Thanks again Guido and Charles-François for your help on this tricky issue. Sorry for having flood your mail box :-) -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20505 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20600] test_create_server_ssl_verify_failed() failure on PPC64 AIX 3.x buildbot
STINNER Victor added the comment: Platform: AIX-1-00F84C0C4C00-powerpc-32bit big-endian [ 49/389/3] test_ssl test_ssl: testing with 'OpenSSL 1.0.1e 11 Feb 2013' (1, 0, 1, 5, 15) under 'AIX-1-00F84C0C4C00-powerpc-32bit' HAS_SNI = True OP_ALL = 0x-7c01 OP_NO_TLSv1_1 = 0x1000 Oh, there are many failures in test_ssl: == FAIL: test_load_cert_chain (test.test_ssl.ContextTests) -- ssl.SSLError: unknown error (_ssl.c:2496) During handling of the above exception, another exception occurred: Traceback (most recent call last): File /home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_ssl.py, line 733, in test_load_cert_chain ctx.load_cert_chain(BADCERT) AssertionError: PEM lib does not match unknown error (_ssl.c:2496) == FAIL: test_load_verify_locations (test.test_ssl.ContextTests) -- ssl.SSLError: unknown error (_ssl.c:2719) During handling of the above exception, another exception occurred: Traceback (most recent call last): File /home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_ssl.py, line 818, in test_load_verify_locations ctx.load_verify_locations(BADCERT) AssertionError: PEM lib does not match unknown error (_ssl.c:2719) == FAIL: test_connect (test.test_ssl.NetworkedTests) -- ssl.SSLError: A failure in the SSL library occurred (_ssl.c:598) During handling of the above exception, another exception occurred: Traceback (most recent call last): File /home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_ssl.py, line 1140, in test_connect s.connect, (svn.python.org, 443)) AssertionError: certificate verify failed does not match A failure in the SSL library occurred (_ssl.c:598) == FAIL: test_connect_with_context (test.test_ssl.NetworkedTests) -- ssl.SSLError: A failure in the SSL library occurred (_ssl.c:598) During handling of the above exception, another exception occurred: Traceback (most recent call last): File /home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_ssl.py, line 1246, in test_connect_with_context s.connect, (svn.python.org, 443)) AssertionError: certificate verify failed does not match A failure in the SSL library occurred (_ssl.c:598) == FAIL: test_crl_check (test.test_ssl.ThreadedTests) -- ssl.SSLError: A failure in the SSL library occurred (_ssl.c:598) During handling of the above exception, another exception occurred: Traceback (most recent call last): File /home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_ssl.py, line 1977, in test_crl_check s.connect((HOST, server.port)) AssertionError: certificate verify failed does not match A failure in the SSL library occurred (_ssl.c:598) == FAIL: test_default_ciphers (test.test_ssl.ThreadedTests) -- Traceback (most recent call last): File /home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_ssl.py, line 2563, in test_default_ciphers self.assertIn(no shared cipher, str(server.conn_errors[0])) AssertionError: 'no shared cipher' not found in 'A failure in the SSL library occurred (_ssl.c:598)' == FAIL: test_sni_callback_alert (test.test_ssl.ThreadedTests) -- Traceback (most recent call last): File /home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_ssl.py, line 2760, in test_sni_callback_alert self.assertEqual(cm.exception.reason, 'TLSV1_ALERT_ACCESS_DENIED') AssertionError: None != 'TLSV1_ALERT_ACCESS_DENIED' == FAIL: test_sni_callback_raising (test.test_ssl.ThreadedTests) -- Traceback (most recent call last): File /home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_ssl.py, line 2776, in test_sni_callback_raising self.assertEqual(cm.exception.reason, 'SSLV3_ALERT_HANDSHAKE_FAILURE') AssertionError: None != 'SSLV3_ALERT_HANDSHAKE_FAILURE'
[issue20495] test_read_pty_output() hangs on FreeBSD 7.2 buildbot
Guido van Rossum added the comment: LGTM -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20495 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20572] subprocess.Popen.wait() undocumented endtime parameter
Roundup Robot added the comment: New changeset 73793590d97b by Gregory P. Smith in branch 'default': Deprecate Popen.wait()'s undocumented endtime parameter. issue20572. http://hg.python.org/cpython/rev/73793590d97b -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20572 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20572] subprocess.Popen.wait() undocumented endtime parameter
Gregory P. Smith added the comment: documented with a deprecation. that's the best we can do for now. it can be considered for removal in the 3.5 or 3.6 timeframe. i doubt many people used it. -- nosy: +gregory.p.smith resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20572 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20596] Support for alternate wcstok syntax for Windows compilers
Jeffrey Armstrong added the comment: I've replaced the patch with a newer version that defines Py_WCSTOK in Include/pyport.h as Victor suggested. -- Added file: http://bugs.python.org/file34045/wcstok.default.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20596 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20572] subprocess.Popen.wait() undocumented endtime parameter
R. David Murray added the comment: Well, a deprecation warning in the code would be nice in case anybody did use it. Personally I don't see any problem with putting that in 3.4.1 if we don't get to it for 3.4.0. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20572 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20601] tracing and tests that raise an exception in a SIGALRM handler
New submission from Xavier de Gaye: After an alarm handler raises an exception while a tracing function is being invoked and when this exception is not caught by the tracing function, the call_trampoline() function in sysmodule.c returns NULL and its caller, trace_trampoline(), removes the trace function. Therefore, tests that raise an exception in an alarm handler should use the support.no_tracing decorator as it is done in test_io.py at check_reentrant_write(). Patch attached. -- components: Library (Lib) files: no_tracing.diff keywords: patch messages: 210984 nosy: xdegaye priority: normal severity: normal status: open title: tracing and tests that raise an exception in a SIGALRM handler type: behavior versions: Python 3.4 Added file: http://bugs.python.org/file34046/no_tracing.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20601 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20597] PATH_MAX already defined on some Windows compilers
STINNER Victor added the comment: Let's be a little smarter. PATH_MAX isn't used anymore. Just remove the #defines entirely. Oh I remember that I replaced PATH_MAX with MAXPATHLEN or maybe something else when I tried to fix Python compilation issue on our IRIX buildbot :-) remove_path_max.default.patch looks good to me. Larry: can it be applied on Python 3.4? path_max.default.patch is still needed for Python 3.3. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20597 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20597] PATH_MAX already defined on some Windows compilers
STINNER Victor added the comment: I found it: changeset: 87113:159e51e5fc2c branch: 3.3 parent: 87102:46fc4fb2c8c5 user:Victor Stinner victor.stin...@gmail.com date:Fri Nov 15 17:09:24 2013 +0100 files: Python/pythonrun.c description: pythonrun.c: fix Py_GetPythonHome(), use Py_ARRAY_LENGTH() to get the size of the env_home buffer, not PATH_MAX+1. env_home is declared using MAXPATHLEN+1, and PATH_MAX is not declared on IRIX. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20597 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20495] test_read_pty_output() hangs on FreeBSD 7.2 buildbot
Roundup Robot added the comment: New changeset 2ba583191550 by Victor Stinner in branch 'default': Issue #20495: Skip test_read_pty_output() of test_asyncio on FreeBSD older than http://hg.python.org/cpython/rev/2ba583191550 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20495 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20495] test_read_pty_output() hangs on FreeBSD 7.2 buildbot
Changes by STINNER Victor victor.stin...@gmail.com: -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20495 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20587] sqlite3 converter not being called
Kathryn M Kowalski added the comment: Worked on my machine too - but if you add union all AND order by it breaks -- Added file: http://bugs.python.org/file34047/demo2.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20587 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20414] Python 3.4 has two Overlapped types
STINNER Victor added the comment: @Martin, Richard: Could you please review overlapped_dealloc-2.patch? It should be applied on Python 3.4 IMO. -- versions: +Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20414 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19977] Use surrogateescape error handler for sys.stdin and sys.stdout on UNIX for the C locale
STINNER Victor added the comment: Reintroducing moji-bake intentionally doesn't sound like a particularly good idea, wasn't that what python3 was supposed to help prevent? Sometimes practicality beats purity :-( I tried to convince users that their computer was not well configured, they always replied that Python 3 fails where Perl, PHP, Python 2, C, etc. just work. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19977 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19769] test_venv: test_with_pip() failure on AMD64 Windows Server 2008 [SB] 3.x buildbot
STINNER Victor added the comment: I didn't see this error recently, can I close the issue? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19769 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19751] test_sys: sys.hash_info.algorithm failure on SPARC Solaris buildbot
Changes by STINNER Victor victor.stin...@gmail.com: -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19751 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19619] Blacklist base64, hex, ... codecs from bytes.decode() and str.encode()
STINNER Victor added the comment: Is it still something to do? The initial issue looks to be fixed. You may open new issue if you see more things to do? -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19619 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19466] Clear state of threads earlier in Python shutdown
STINNER Victor added the comment: I didn't see test_threading failing anymore recently, so I'm closing the issue. Thanks. -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19466 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
