[issue3068] IDLE - Add an extension configuration dialog
Ned Deily added the comment: Tal, I'm working on something to make that easier. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3068 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19524] ResourceWarning when urlopen() forgets the HTTPConnection object
Changes by Martin Panter vadmium...@gmail.com: Added file: http://bugs.python.org/file35980/test2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19524 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19524] ResourceWarning when urlopen() forgets the HTTPConnection object
Martin Panter added the comment: Added a new test for the invalid response case. Now both tests are included in test2.patch. I separated the actual fix into a separate close3.4.patch (refreshed for the 3.4 branch). This way it is easier for me to make sure the tests work before applying the fix, but it should be easy to combine the patches again if you prefer it that way. -- Added file: http://bugs.python.org/file35981/close3.4.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19524 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21939] IDLE - Test Percolator
Changes by Saimadhav Heblikar saimadhavhebli...@gmail.com: Added file: http://bugs.python.org/file35982/test_percolator-34-v2.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21939 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14285] Traceback wrong on ImportError while executing a package
Martin Panter added the comment: A file called “package/__main__.py” is executed as a script by “python -m package”. See https://docs.python.org/dev/library/__main__.html. I’ve came across this issue myself. You don’t even need the __main__.py file to be doing anything special, as long as the __init__.py raises an ImportError, I think. On Python 3.4 the report is even more convoluted: /sbin/python3: Error while finding spec for 'package.__main__' (class 'ImportError': No module named 'missing_module'); 'package' is a package and cannot be directly executed I dunno what “finding spec” means, and packages _can_ be directly executed if they have a __main__ module, so at least the last bit is definitely wrong. -- nosy: +vadmium versions: +Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14285 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21996] gettarinfo method does not handle files without text string names
New submission from Martin Panter:
It looks like if you pass a “fileobj” argument to “gettarinfo”, it assumes it
can use the “name” as a text string.
import tarfile
with tarfile.open(/dev/null, w) as tar, open(/bin/sh, rb) as file:
tar.gettarinfo(fileobj=file)
...
TarInfo 'bin/sh' at 0x7f13cc937f20
with tarfile.open(/dev/null, w) as tar, open(b/bin/sh, rb) as file:
tar.gettarinfo(fileobj=file)
...
Traceback (most recent call last):
File stdin, line 1, in module
File /media/disk/home/proj/python/cpython/Lib/tarfile.py, line 1767, in
gettarinfo
arcname = arcname.replace(os.sep, /)
TypeError: expected bytes, bytearray or buffer compatible object
with tarfile.open(/dev/null, w) as tar, open(0, rb, closefd=False) as
file: tar.gettarinfo(fileobj=file)
...
Traceback (most recent call last):
File stdin, line 1, in module
File /media/disk/home/proj/python/cpython/Lib/tarfile.py, line 1766, in
gettarinfo
drv, arcname = os.path.splitdrive(arcname)
File Lib/posixpath.py, line 133, in splitdrive
return p[:0], p
TypeError: 'int' object is not subscriptable
In my case, my code always sets the final TarInfo.name attribute later on, so
the initial name does not matter. Perhaps at least the documentation should say
that “fileobj.name” must be a real unencoded file name string unless “arcname”
is also given. My workaround was to add a dummy arcname argument, a bit like
this:
# Explicit dummy name to avoid using file name of bytes
tarinfo = self.tar.gettarinfo(fileobj=file, arcname=)
# . . .
tarinfo.name = {}/{}.format(self.pkgname, name)
--
components: Library (Lib)
messages: 223318
nosy: vadmium
priority: normal
severity: normal
status: open
title: gettarinfo method does not handle files without text string names
versions: Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21996
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21044] tarfile does not handle file .name being an int
Martin Panter added the comment: Opened Issue 21996 for the “gettarinfo” method. Also, Serhiy, I think you may have got me mixed up with someone else. I don’t think I did any patches here, so I probably shouldn’t be credited for them :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21044 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18320] python installation is broken if prefix is overridden on an install target
Martin v. Löwis added the comment: -1 on adding such a test. Some people may rely on the current behaviour, and use that to put the installation into some intermediate location (although DESTDIR would be a better approach for that). Also, how many variables would you want to protect from being changed? People may come up with ideas of changing arbitrary other Makefile variables, and guarding all of them is just not feasible. I propose to close this as won't fix. -- nosy: +loewis ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18320 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21645] asyncio: Race condition in signal handling on FreeBSD
STINNER Victor added the comment:
I ran test_asyncio on my own FreeBSD VM, with the sandbox/issue21645 repository
and I got a new (different) error on signal handling: RuntimeError('reentrant
call inside') when writing into sys.stderr. To be fair: this bug was introduced
by my changes in this repository adding debug traces (logger.error(handle
signal %s % sig)).
IMO the Py_AddPendingCall() function in Python is dangerous: the callback
should be signal-safe but this concept is not defined Python. In the C
language, there is a strict list of allowed functions, in Python it's unclear:
the reentrant call is just an example. It's probably easy to deadlock if you
call the wrong function.
Py_AddPendingCall() injects arbitrary Python code between *any* other Python
bytecode, it's like the evil greenlet with greenthreads.
That's why I consider that it would be safer to call _handle_signal() from the
event loop, not using Py_AddPendingCall():
https://code.google.com/p/tulip/issues/detail?id=192
Output of the new bug on FreeBSD:
---
[1085] C signal_handler: sig_num=20, thread=34380739584
C signal_handler: trip signal (tripped=0)
[1085] trip_signal(20)
trip_signal(20); write()
trip_signal(20); write() - 1
[1085] Py_AddPendingCall(checksignals_witharg), thread=34380739584
--- Logging error ---
Traceback (most recent call last):
File /usr/home/haypo/prog/python/default/Lib/logging/__init__.py, line 980,
in emit
stream.write(self.terminator)
RuntimeError: reentrant call inside _io.BufferedWriter name='stderr'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File /usr/home/haypo/prog/python/default/Lib/logging/__init__.py, line 980,
in emit
stream.write(self.terminator)
File /usr/home/haypo/prog/python/default/Lib/asyncio/unix_events.py, line
95, in _handle_signal
logger.error(handle signal %s % sig)
File /usr/home/haypo/prog/python/default/Lib/logging/__init__.py, line
1302, in error
self._log(ERROR, msg, args, **kwargs)
File /usr/home/haypo/prog/python/default/Lib/logging/__init__.py, line
1408, in _log
self.handle(record)
File /usr/home/haypo/prog/python/default/Lib/logging/__init__.py, line
1418, in handle
self.callHandlers(record)
File /usr/home/haypo/prog/python/default/Lib/logging/__init__.py, line
1480, in callHandlers
hdlr.handle(record)
File /usr/home/haypo/prog/python/default/Lib/logging/__init__.py, line 852,
in handle
self.emit(record)
File /usr/home/haypo/prog/python/default/Lib/logging/__init__.py, line 983,
in emit
self.handleError(record)
File /usr/home/haypo/prog/python/default/Lib/logging/__init__.py, line 904,
in handleError
sys.stderr.write('--- Logging error ---\n')
RuntimeError: reentrant call inside _io.BufferedWriter name='stderr'
Call stack:
File /usr/home/haypo/prog/python/default/Lib/runpy.py, line 170, in
_run_module_as_main
__main__, mod_spec)
File /usr/home/haypo/prog/python/default/Lib/runpy.py, line 85, in _run_code
exec(code, run_globals)
File /usr/home/haypo/prog/python/default/Lib/test/__main__.py, line 3, in
module
regrtest.main_in_temp_cwd()
File /usr/home/haypo/prog/python/default/Lib/test/regrtest.py, line 1562,
in main_in_temp_cwd
main()
File /usr/home/haypo/prog/python/default/Lib/test/regrtest.py, line 763, in
main
match_tests=ns.match_tests)
File /usr/home/haypo/prog/python/default/Lib/test/regrtest.py, line 978, in
runtest
display_failure=not verbose)
File /usr/home/haypo/prog/python/default/Lib/test/regrtest.py, line 1278,
in runtest_inner
test_runner()
File /usr/home/haypo/prog/python/default/Lib/test/test_asyncio/__init__.py,
line 29, in test_main
run_unittest(suite())
File /usr/home/haypo/prog/python/default/Lib/test/support/__init__.py, line
1758, in run_unittest
_run_suite(suite)
File /usr/home/haypo/prog/python/default/Lib/test/support/__init__.py, line
1724, in _run_suite
result = runner.run(suite)
File /usr/home/haypo/prog/python/default/Lib/unittest/runner.py, line 168,
in run
test(result)
File /usr/home/haypo/prog/python/default/Lib/unittest/suite.py, line 87, in
__call__
return self.run(*args, **kwds)
File /usr/home/haypo/prog/python/default/Lib/unittest/suite.py, line 125,
in run
test(result)
File /usr/home/haypo/prog/python/default/Lib/unittest/suite.py, line 87, in
__call__
return self.run(*args, **kwds)
File /usr/home/haypo/prog/python/default/Lib/unittest/suite.py, line 125,
in run
test(result)
File /usr/home/haypo/prog/python/default/Lib/unittest/suite.py, line 87, in
__call__
return self.run(*args, **kwds)
File /usr/home/haypo/prog/python/default/Lib/unittest/suite.py, line 125,
in run
test(result)
File /usr/home/haypo/prog/python/default/Lib/unittest/case.py, line 625, in
__call__
return self.run(*args, **kwds)
File /usr/home/haypo/prog/python/default/Lib/unittest/case.py, line 577, in
[issue21935] Implement AUTH command in smtpd.
Martin v. Löwis added the comment: RFC 4954 states Note: A server implementation MUST implement a configuration in which it does NOT permit any plaintext password mechanisms, unless either the STARTTLS [SMTP-TLS] command has been negotiated or some other mechanism that protects the session from password snooping has been provided. Server sites SHOULD NOT use any configuration which permits a plaintext password mechanism without such a protection mechanism against password snooping. So I'm -1 on this patch, and also on the feature until STARTTLS is implemented (and then this patch needs to be updated to conform to this requirement). -- nosy: +loewis ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21935 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17243] The changes made for issue 4074 should be documented
Martin v. Löwis added the comment: No. There is no responsibility to do anything in an open source project. -- nosy: +loewis ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17243 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18392] Doc: PyObject_Malloc() is not documented
Carol Willing added the comment: Looks as if there is a patch for this on Issue 20064. http://bugs.python.org/issue20064 -- nosy: +willingc ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18392 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3068] IDLE - Add an extension configuration dialog
Tal Einat added the comment: @Ned: Great! Please keep me posted. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3068 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21645] asyncio: Race condition in signal handling on FreeBSD
STINNER Victor added the comment: IMO we must handle signals correctly when there are more than one thread. On Linux, it looks like the C signal handler is always called from the main thread. On FreeBSD, it looks like the C signal handler can be called in any thread, C thread, Python thread holding the GIL, Python thread not holding the GIL. I found why test_read_all_from_pipe_reader() is running with more than one thread. I reproduced the issue on my FreeBSD VM. run_test_server() and run_test_unix_server() functions of test_utils create Python threads, these functions are used in the test_asyncio. The problem is that the PyThreadState_DeleteCurrent() function (called from t_bootstrap() of _threadmodule.c) may yield the CPU to another thread. Other Python threads are running when the line MUTEX_UNLOCK(gil_mutex); is executed in the drop_gil() function, before drop_gil() exits. t_bootstrap() - PyThreadState_DeleteCurrent() - PyEval_ReleaseLock() - drop_gil(NULL) It means that Python threads are not deleted immediatly, but may be deleted later. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21645 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21935] Implement AUTH command in smtpd.
Milan Oberkirch added the comment: My interpretation of this paragraph is the following (English is not my native language so please correct me if I'm wrong): The requirement is to provide a configuration where plain auth is disabled if password snooping would be possible otherwise not to forbid such configurations generally. An admin SHOULD provide security measures to prevent password snooping. Setting enable_AUTH=False is a configuration where plain authentication is not permitted. The admin should provide a STARTTLS (or any other encrypted) tunnel if enabling AUTH (stunnel would be a common solution on Linux). Maybe we should explicitly mention that in the docs? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21935 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20064] PyObject_Malloc is not documented
Mark Lawrence added the comment: As the patch is short can we have a commit review please. Can we also close issue 18392 as a duplicate of this. -- nosy: +BreamoreBoy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20064 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15617] FAIL: test_create_connection (test.test_socket.NetworkConnectionNoServer)
Floris Bruynooghe added the comment: Oops, I've kicked the bruynooghe-solaris-csw buildslave and it should now be building again. A bit disappointed that buildbot/twisted doesn't reconnect automatically though. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15617 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7247] test_fcntl_64_bit from test_fcntl.py fails in Python 2.6.4
Mark Lawrence added the comment: The patch LGTM at a quick glance so can we have a formal review please. -- nosy: +BreamoreBoy versions: +Python 3.5 -Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7247 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15629] Add to regrtest the ability to run Lib and Doc doctests
Mark Lawrence added the comment: It appears, especially from the later messages, that this is not wanted. However noting msg170616 should we close this with #10967 to supersede it? -- nosy: +BreamoreBoy versions: +Python 3.5 -Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15629 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11551] test_dummy_thread.py test coverage improvement
Mark Lawrence added the comment: @Denver are you still interested in working on this as a week or two has passed? :) -- nosy: +BreamoreBoy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11551 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11551] test_dummy_thread.py test coverage improvement
Changes by Brian Curtin br...@python.org: -- nosy: -brian.curtin ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11551 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9949] os.path.realpath on Windows does not follow symbolic links
Changes by Brian Curtin br...@python.org: -- nosy: -brian.curtin ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9949 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10305] Cleanup up ResourceWarnings in multiprocessing
Changes by Brian Curtin br...@python.org: -- nosy: -brian.curtin ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10305 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19756] test_nntplib: sporadic failures, network isses? server down?
Mark Lawrence added the comment: Are these sporadic failures still happening? I've glanced over the logs and only found failures due to recent code changes. -- nosy: +BreamoreBoy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19756 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15411] os.chmod() does not follow symlinks on Windows
Changes by Brian Curtin br...@python.org: -- nosy: -brian.curtin ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15411 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13837] test_shutil fails with symlinks enabled under Windows
Changes by Brian Curtin br...@python.org: -- nosy: -brian.curtin ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13837 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1598] unexpected response in imaplib
R. David Murray added the comment: I'm guessing you do. On the other hand, I fixed a get_response bug a few months ago...it doesn't sound related from the description, but if someone can arrange to test against a Lotus server and can't reproduce the bug, testing again with an older version of imaplib might then reproduce it, and prove that it was fixed. -- assignee: pierslauder - stage: patch review - test needed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1598 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21044] tarfile does not handle file .name being an int
Antoine Pietri added the comment: Also, Serhiy, I think you may have got me mixed up with someone else. I don’t think I did any patches here, so I probably shouldn’t be credited for them :) Yeah, but I don't mind if I'm not in the ACKS file for a one-line patch though :P -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21044 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21935] Implement AUTH command in smtpd.
R. David Murray added the comment: Providing starttls support would be the preferred solution, but that is a Hard Problem. We probably need to rewrite smtpd using asyncio in order to provide starttls. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21935 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15617] FAIL: test_create_connection (test.test_socket.NetworkConnectionNoServer)
R. David Murray added the comment: buildbot does normally reconnect automatically, so something must be wrong somewhere if it didn't. I do seem to remember a bug that caused the slave to occasionally get confused about its current status in certain unusual circumstances...perhaps that bug has not been fixed yet. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15617 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21946] 'python -u' yields trailing carriage return '\r' (Python2 for Windows)
R. David Murray added the comment: This is the documented behavior of the -u option. It puts the streams in binary mode on systems where it matters, which would be windows. That is, universal newline processing is disabled when you use -u. Note that this is no longer an issue in python3: there, -u only affects buffering, and not the binary/text mode (because in python3 there is always a distinction between binary and text mode, regardless of platform). -- nosy: +r.david.murray resolution: - not a bug stage: - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21946 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21044] tarfile does not handle file .name being an int
Zachary Ware added the comment: This change appears to have broken 2.7 on Windows: http://buildbot.python.org/all/builders/x86%20Windows7%202.7/builds/2707/steps/test/logs/stdio -- nosy: +zach.ware resolution: fixed - stage: resolved - commit review status: closed - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21044 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21645] asyncio: Race condition in signal handling on FreeBSD
Guido van Rossum added the comment: I did my meditation. I now understand the race: - main thread is blocked in select() (or poll() etc.) - C-level signal handler is called in thread B and writes a byte to self-pipe - kernel immediately switches threads - main thread wakes up, reads data from self-pipe, goes back to block - C-level signal handles calls Py_AddPendingCall() to schedule Python-level signal handler - however the main thread is already back asleep The intention if the code was that the Py_AddPendingCall() would complete before the thread switch. Perhaps a CPython fix could be to call it before writing a byte to the pipe??? But that would require someone else to meditate more on the C code. I think your patch to Tulip is fine. I wouldn't worry about missing a signal when things are busy -- AFAIK the child process reaper will reap multiple processes. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21645 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16892] Windows bug picking up stdin from a pipe
eryksun added the comment: Doskey is a command-line interface for a subset of the Win32 console API. Macros are implemented as console input aliases by calling AddConsoleAlias. http://msdn.microsoft.com/en-us/library/ms681935 You can load macros from a text file that defines aliases for multiple EXEs: doskey /macrofile=doskey.cfg Create this file from your current macros: doskey /macros:all doskey.cfg You can also use ctypes to add an alias. #!python3 import ctypes import subprocess AddConsoleAliasW = ctypes.windll.kernel32.AddConsoleAliasW AddConsoleAliasW.argtypes = [ctypes.c_wchar_p] * 3 # $db = import builtins;dir(builtins) AddConsoleAliasW($db, import builtins;dir(builtins), python.exe) #subprocess.call(doskey) subprocess.call(stdintest.exe, shell=True) The bug occurs if I uncomment the line to run doskey. When stdin is a file, calling sys.stdin.tell() before and after running doskey shows that it's reading standard input, for whatever reason. That's its prerogative, not a bug. Calling sys.stdin.seek(0) after running doskey works, but that's not a possibility when doskey is run via the cmd shell's AutoRun. By the way, redirection to a file is not a pipe. It actually works for a pipe such as type mytxtfile.txt | testsubproc.py The good news is that you only need to load doskey macros once for a given console window. You can use an AutoRun script that tests and sets an environment variable: @echo off if %AUTORUN_DOSKEY%==No goto end echo %0: setting doskey macros %SystemRoot%\System32\doskey.exe /macrofile=%AppData%\doskey.cfg set AUTORUN_DOSKEY=No :end This should take care of cases where you're redirecting standard input to a file, assuming the shell wasn't started with the /d option to skip AutoRun. On Posix systems /bin/sh -c doesn't execute .profile, .bashrc, etc. So maybe on Windows Popen should use %ComSpec% /d /c. You'd still have this problem with os.system, however. -- nosy: +eryksun ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16892 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21997] Pdb.set_trace debugging does not end correctly in IDLE
New submission from ppperry: In IDLE: def dodebug(): pdb.set_trace() dodebug() --Return-- pyshell#6(2)dodebug()-None (Pdb) s --Return-- pyshell#8(1)module()-None (Pdb) s PDB should exit, but it doesn't c:\python27\lib\idlelib\run.py(308)runcode() - interruptable = False (Pdb)s c:\python27\lib\idlelib\run.py(322)runcode() - flush_stdout() Quitting from this state raises an error: (Pdb)q Traceback (most recent call last): ** IDLE Internal Exception: File C:\Python27\lib\idlelib\run.py, line 100, in main ret = method(*args, **kwargs) File C:\Python27\lib\idlelib\run.py, line 322, in runcode flush_stdout() File C:\Python27\lib\idlelib\run.py, line 322, in runcode flush_stdout() File C:\Python27\lib\bdb.py, line 49, in trace_dispatch return self.dispatch_line(frame) File C:\Python27\lib\bdb.py, line 68, in dispatch_line if self.quitting: raise BdbQuit BdbQuit The same example outside of IDLE: def dodebug(): pdb.set_trace() dodebug() --Return-- stdin(1)dodebug()-None (Pdb) s --Return-- stdin(1)module()-None (Pdb) s [clean pbd exit] Note: this bug does not occur with pdb.run(). OS: Windows XP -- components: IDLE, Library (Lib) messages: 223342 nosy: ppperry priority: normal severity: normal status: open title: Pdb.set_trace debugging does not end correctly in IDLE versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21997 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21645] asyncio: Race condition in signal handling on FreeBSD
STINNER Victor added the comment: The intention if the code was that the Py_AddPendingCall() would complete before the thread switch. In fact I also expected Py_AddPendingCall() to be called *before* writing the signal number into the wakeup fd. I guess that before nobody was relying on the wakeup fd *and* and the callback. Perhaps a CPython fix could be to call it before writing a byte to the pipe??? But that would require someone else to meditate more on the C code. It doesn't work for Tulip which targets Python 3.3. Oh... I just saw that Python 2.7 calls Py_AddPendingCall() and *then* writes \0 into wakeup fd... So Python 2.7 does not have the issue! But yes, we may change the C signal handler in Python 3.5 because it makes more sense to call Py_AddPendingCall() to avoid this specific race condition. I think your patch to Tulip is fine. Good :) I will test it on FreeBSD. If it fixes the issue, I will apply it. We will see if it makes all buildbots happy. I wouldn't worry about missing a signal when things are busy -- AFAIK the child process reaper will reap multiple processes. Well, Py_AddPendingCall() also has a limit which is smaller and it does *not* warn when signals are dropped :-( -- I don't know if it can be useful, but there is also the signal.pthread_sigmask() which can be used to queue pending signals. Unblocking signals will flush the queue. It might help to mitigate burst of signals in a short window I don't know if signal.pthread_sigmask() has a longer queue than Python. And it may be tricky to decide when and where the signals should be blocked and unblocked. If a signal is blocked and the process gets the signal more than once, the signal is only raised once when the signal is unblocked. I don't know if it is an issue or not if asyncio only calls the signal handler once in this case. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21645 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21998] asyncio: a new self-pipe should be created in the child process after fork
New submission from STINNER Victor: It looks like asyncio does not suppport fork() currently: on fork(), the event loop of the parent and the child process share the same self pipe. Example: --- import asyncio, os loop = asyncio.get_event_loop() pid = os.fork() if pid: print(parent, loop._csock.fileno(), loop._ssock.fileno()) else: print(child, loop._csock.fileno(), loop._ssock.fileno()) --- Output: --- parent 6 5 child 6 5 --- I'm not sure that it's revelant to use asyncio with fork, but I wanted to open an issue at least as a reminder. I found the self pipe + fork issue when reading the issue #12060, while working on a fix for the signal handling race condition on FreeBSD: issue #21645. -- components: asyncio messages: 223344 nosy: gvanrossum, haypo, yselivanov priority: normal severity: normal status: open title: asyncio: a new self-pipe should be created in the child process after fork versions: Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21998 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21997] Pdb.set_trace debugging does not end correctly in IDLE
Changes by ppperry maprea...@olum.org: -- type: - behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21997 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21044] tarfile does not handle file .name being an int
Antoine Pietri added the comment: This change does not need to be merged on 2.7 anyway, as the os.fdopen sets the name attribute to 'fdopen' and not to the fd, this check is not required prior to python 3. Still, it would be interesting to investigate why this breaks 2.7 though. -- versions: -Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21044 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21645] asyncio: Race condition in signal handling on FreeBSD
STINNER Victor added the comment: I don't know if it can be useful, but there is also the signal.pthread_sigmask() which can be used to queue pending signals. (...) Oh, I didn't remember that I opened the issue #12060 to discuss real time signals. The summary is that the wakeup fd should be used... Which is nice because it is the choice made by asyncio ;-) FYI I also opened the issue #21998: asyncio: a new self-pipe should be created in the child process after fork which is somehow related to this issue. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21645 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14285] Traceback wrong on ImportError while executing a package
Changes by Berker Peksag berker.pek...@gmail.com: -- nosy: +eric.snow ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14285 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21946] 'python -u' yields trailing carriage return '\r' (Python2 for Windows)
STINNER Victor added the comment: The bug is not on print, but raw_input(). In Python 3, I worked on the following issues to support fully binary standard streams: - #10841: binary stdio - #11272: input() has trailing carriage return on windows, fixed in Python 3.2.1 - #11395: print(s) fails on Windows with long strings, fixed in Python 3.2.1 - #13119: Newline for print() is \n on Windows, and not \r\n as expected, will be fixed in Python 3.2.4 and 3.3 (not released yet) It looks like this issue is the same than #11272: input() removes '\n' but not '\r'. -- resolution: not a bug - status: closed - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21946 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21996] gettarinfo method does not handle files without text string names
Changes by Berker Peksag berker.pek...@gmail.com: -- nosy: +serhiy.storchaka versions: +Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21996 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21999] shlex: bug in posix more handling of empty strings
New submission from Martin Morrison:
Minimal testcase of the problem situation is tokenising (with posix mode on):
''),
Specifically, an empty string, followed by a non-word character, followed by a
non-space character. In this case, the token buffer is empty and due to a
missing check for (self.posix and quoted), an extra token is consumed and
returned in the wrong order:
s = shlex.shlex('')abc, posix=True)
s.get_token()
'abc'
s.get_token()
')'
s.get_token()
I have patches to fix this issue in both default and 2.7. I've also checked
there are no other occurrences of the same typo.
--
files: shlex.default.patch
keywords: patch
messages: 223348
nosy: isoschiz
priority: normal
severity: normal
status: open
title: shlex: bug in posix more handling of empty strings
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file35983/shlex.default.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21999
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21999] shlex: bug in posix more handling of empty strings
Changes by Martin Morrison m...@ensoft.co.uk: Added file: http://bugs.python.org/file35984/shlex.2.7.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21999 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21247] test_asyncio: test_subprocess_send_signal hangs on Fedora builders
Orion Poplawski added the comment: That appears to work. Thanks! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21247 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21645] asyncio: Race condition in signal handling on FreeBSD
Guido van Rossum added the comment: The more esoteric system calls you use the more you end up debugging it on esoteric platforms. :-( On Thu, Jul 17, 2014 at 9:17 AM, STINNER Victor rep...@bugs.python.org wrote: STINNER Victor added the comment: I don't know if it can be useful, but there is also the signal.pthread_sigmask() which can be used to queue pending signals. (...) Oh, I didn't remember that I opened the issue #12060 to discuss real time signals. The summary is that the wakeup fd should be used... Which is nice because it is the choice made by asyncio ;-) FYI I also opened the issue #21998: asyncio: a new self-pipe should be created in the child process after fork which is somehow related to this issue. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21645 ___ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21645 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21907] Update Windows build batch scripts
Ingolf Becker added the comment: A couple of issues: PCbuild/build_pgo.bat: - there a quite a few incorrect which break the call to rmpyc.py - some paths were not cwd-agnostic - all paths should now be whitespace aware - The PGI python.exe requires the pgodb100.dll to be in the PATH when executed. vcvarsall.bat sets the path correctly. PCbuild/build_pgo.bat: - incorrect parameter for vcvarsall.bat for x64: x86_amd64 == x86!! With these changes build_pgo.bat works. -- nosy: +ibecker Added file: http://bugs.python.org/file35985/fix_pgo_vcvarsall.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21907 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21935] Implement AUTH command in smtpd.
Martin v. Löwis added the comment: Milan: Your interpretation of the MUST requirement is correct. However, we still cannot support the SHOULD NOT requirement: A server operator SHOULD NOT accept unencrypted passwords. RFC 2119 explains This phrase, or the phrase NOT RECOMMENDED mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. I cannot see any particular circumstances where unencrypted passwords for smtpd would be acceptable, given that there are perfectly established technologies. So I remain -1 on this patch. A (not recommended) STARTTLS alternative is SMTPS (port 465). I would be -0 if there was an SMTPS implementation in smtpd, and the documentation would discuss that AUTH is best used with SMTPS until STARTTLS is implemented. I don't understand why STARTTLS would require asyncio. Wouldn't wrap_socket solve the problem? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21935 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22000] cross type comparisons clarification
New submission from Jim Jewett: https://docs.python.org/3.5/library/stdtypes.html says Objects of different types, except different numeric types, never compare equal. Despite the location, this seems to strong a statement, because of subclasses and classes which define __eq__. A first attempt at rewording: Existing: Objects of different types, except different numeric types, never compare equal. Furthermore, some types (for example, function objects) support only a degenerate notion of comparison where any two objects of that type are unequal. The , =, and = operators will raise a TypeError exception when comparing a complex number with another built-in numeric type, when the objects are of different types that cannot be compared, or in other cases where there is no defined ordering. Non-identical instances of a class normally compare as non-equal unless the class defines the __eq__() method. Instances of a class cannot be ordered with respect to other instances of the same class, or other types of object, unless the class defines enough of the methods __lt__(), __le__(), __gt__(), and __ge__() (in general, __lt__() and __eq__() are sufficient, if you want the conventional meanings of the comparison operators). The behavior of the is and is not operators cannot be customized; also they can be applied to any two objects and never raise an exception. Two more operations with the same syntactic priority, in and not in, are supported only by sequence types (below). -- The is and is not operators can be applied to any pair of objects, and will never raise an exception. They cannot be customized, as they refer to implementation details. (For example, abc is abc may or may not be true.) Other comparisons refer to an object's meaning, and therefore must be defined by the object's own class. abc == abc is always True, because the str class defines equality that way. The default implementation uses is (object identity) for equality and raises a TypeError for the ordering comparisons. Defining the __eq__ method allows different instances to be equivalent; also defining the __lt__ method allows them to be ordered in the normal way. Some classes will also define __le__, __ne__, __ge__, and __gt__, either for efficiency or to provide unusual behavior. Except for numbers, instances of two different standard classes will be unequal, and will raise a TypeError when compared for ordering. Two more operations with the same syntactic priority, in and not in, are supported only by sequence types (below). -- assignee: docs@python components: Documentation messages: 223353 nosy: Jim.Jewett, docs@python priority: normal severity: normal status: open title: cross type comparisons clarification type: behavior versions: Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22000 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21935] Implement AUTH command in smtpd.
R. David Murray added the comment: I haven't looked at the problem myself. Someone (Giampaolo?) told me that wrap_socket wouldn't work because of the fact that smtpd uses asynchat. As for the 'particular circumstances' clause, I would suggest that one of the primary use cases for smtpd is in testing infrastructure (and that is in fact the motivation for this issue, for stdlib testing), and in that situation unencrypted passwords would not be an issue. However, if wrap_socket/SMTPDS would work, it would make the feature useful beyond the testing arena. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21935 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21907] Update Windows build batch scripts
Zachary Ware added the comment: As you can probably tell, I wasn't on a machine where I could test build_pgo.bat before I committed changes to it (oops). It looks like your patch is reversed, would you mind fixing it? I can tell you it will need to change, though; build.bat needs to use 'x86_amd64' for the argument to vcvarsall.bat for building 64-bit to support cross-compiling on 32-bit Windows. It may work out easiest for build_pgo.bat to just not use build.bat. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21907 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21950] import sqlite3 not running after configure --prefix=/alt/path; make; make install
R. David Murray added the comment: If the headers are missing, you will get a complaint at the end of the make process that it couldn't build the _sqlite module. It should also have tried to import the sqlite3 module and complained if there was an error. So, pre-install, everything looked fine to the build process. Can you attach your 'make install' log? (Berker: a key difference in your test is that OP specified an alternate --prefix) -- nosy: +r.david.murray resolution: works for me - status: closed - open title: import sqlite3 not running - import sqlite3 not running after configure --prefix=/alt/path; make; make install ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21950 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18320] python installation is broken if prefix is overridden on an install target
Ned Deily added the comment: Also, how many variables would you want to protect from being changed? People may come up with ideas of changing arbitrary other Makefile variables, and guarding all of them is just not feasible. I certainly wasn't contemplating guarding *all* of them. I'm concerned about those that are documented and conventionally used in standard Makefiles, e.g. https://www.gnu.org/software/make/manual/make.html#Directory-Variables. Of those, the only ones that appear to be overridable in the Python top-level Makefile are prefix, exec_prefix, and datarootdir (the latter does not seem to be used directly in the top-level Makefile but is used in ctypes libffi Makefile). And prefix is the one that causes the problems. If you really think someone is currently using this productively somehow, even with producing a broken Python, we could just issue a warning. I just think we should not allow people to shoot themselves in the foot so easily without warning: when I do make install, I expect everything to be installed under prefix, not partially under another prefix, and I expect subsequent installations using Distutils to work properly. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18320 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17113] argparse.RawDescriptionHelpFormatter should not delete blank lines
Mark Lawrence added the comment: Can we have this followed up please. -- nosy: +BreamoreBoy, paul.j3 versions: +Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17113 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13819] _warnings settings are process-wide
Mark Lawrence added the comment: Just a gentle reminder. -- nosy: +BreamoreBoy versions: +Python 3.4, Python 3.5 -Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13819 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1598] unexpected response in imaplib
Roy Hyunjin Han added the comment: Is imaplib choking on the IBM-specific X-MIMETrack header? Is Lotus Notes properly formatting the multi-line headers? Can RFC822 headers contain the PIPE | symbol? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1598 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15485] CROSS: append gcc library search paths
Mark Lawrence added the comment: My reading of msg166737 is that the type should be behaviour. The patch is only five lines of actual code so can we have a review please. -- nosy: +BreamoreBoy type: - behavior versions: +Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15485 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22001] containers same does not always mean __eq__.
New submission from Jim Jewett:
https://docs.python.org/3.5/reference/expressions.html#not-in
Containers are permitted to (and generally do) read same as as is or
__eq__), which can be confusing -- particularly in the section defining __eq__.
Several suggested changes:
The values float('NaN') and Decimal('NaN') are special. The are identical to
themselves, x is x but are not equal to themselves, x != x. Additionally,
comparing any value to a not-a-number value will return False. For example,
both 3 float('NaN') and float('NaN') 3 will return False.
-- (the - they; add a comma; add a final sentence) --
The values float('NaN') and Decimal('NaN') are special. They are identical to
themselves, x is x, but are not equal to themselves, x != x. Additionally,
comparing any value to a not-a-number value will return False. For example,
both 3 float('NaN') and float('NaN') 3 will return False. Note, however,
that containers will normally implement item equality as a is b or a==b, so
that [f]==[f] and f in [f] may be true even when f!=f.
also:
Tuples and lists are compared lexicographically using comparison of
corresponding elements. This means that to compare equal, each element must
compare equal and the two sequences must be of the same type and have the same
length.
-- (re-order; add the NaN workaround) --
Tuples and lists are compared lexicographically using comparison of
corresponding elements. This means that to compare equal, two sequences must be
of the same type and have the same length, and each pair of corresponding
elements must be identical or compare equal. (Sequences can assume that
identical elements are equal, despite odd cases like float('NaN').)
I *think* it is OK to leave that caveat out of the mapping case, because have
the same (key, value) pairs would now refer to the above.
--
assignee: docs@python
components: Documentation
messages: 223362
nosy: Jim.Jewett, docs@python
priority: normal
severity: normal
status: open
title: containers same does not always mean __eq__.
type: enhancement
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22001
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21907] Update Windows build batch scripts
Ingolf Becker added the comment: This should now be the correct way. I did not need to touch build.bat indeed. I got confused by all the different combinations! I have removed the calls from build_pgo.bat to build.bat and changed the it to a native x64 build - the PGO requires the code to be run natively, so cross compiling makes no sense. There was also one \ too many in the pginstrument.props file, which caused a path to end on a \\, which broke the build process. -- Added file: http://bugs.python.org/file35986/fix_pgo_vcvarsall_rightway.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21907 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17127] multiprocessing.dummy.Pool does not accept maxtasksperchild argument
Mark Lawrence added the comment: I've confirmed that the behaviour is identical in 3.4.1 on Windows. -- nosy: +BreamoreBoy, jnoller, sbt versions: +Python 3.4, Python 3.5 -Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17127 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17131] subprocess.Popen.terminate can raise exception on Posix
Mark Lawrence added the comment: @Siona sorry about the delay in getting back to you. Can someone try this please as I've only got Windows. -- nosy: +BreamoreBoy versions: +Python 3.4, Python 3.5 -Python 2.6, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17131 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22002] Make full use of test discovery in test subpackages
New submission from Zachary Ware: Here's a patch against 3.4 implementing Serhiy's suggestion in msg223277 and taking it a step further, actually using test discovery in all of the test.test_* subpackages. To reduce duplication, the patch adds a 'load_package_tests' function to test.support, which is then used in each of the subpackages' load_tests function. test_json and test_tools should have no visible changes from this patch. test_asyncio and test_email do have slight differences, but only in verbosity level: pre-patch, `python -m test.test_(asyncio|email)` runs at verbosity=2 (support.run_unittest default); with patch, they run at verbosity=1 (unittest default). test_asyncio also reports one more skipped test on Windows, due to a module that raises SkipTest on import. @Brett: test_importlib sees the most changes, and I'd like to be sure that things are as you expect them to be. It looks like all of the test_suite() stuff is unused leftovers from when test_importlib was importlib.test and that test_importlib has actually been relying on unittest discovery (but bypassing load_tests and thereby not working with `python -m unittest test.test_importlib`), but I'd like confirmation on that. A nice bonus with this patch is that (for example) `python -m test.test_importlib.source` works, testing just the named test_importlib subpackage. -- components: Tests files: package_discovery.diff keywords: patch messages: 223366 nosy: berker.peksag, brett.cannon, ezio.melotti, serhiy.storchaka, zach.ware priority: normal severity: normal stage: patch review status: open title: Make full use of test discovery in test subpackages type: enhancement versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file35987/package_discovery.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22002 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17131] subprocess.Popen.terminate can raise exception on Posix
Changes by Ned Deily n...@acm.org: -- nosy: +gregory.p.smith ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17131 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12970] os.walk() consider some symlinks as dirs instead of non-dirs
Uwe Kleine-König added the comment: I like the function as it is documented, i.e. filenames is a list of the names of the non-directory files in dirpath.. This includes all symlinks (in the followlinks=False cast at least). I'd say not including symlinks to directories but symlinks to files is a magnitude more surprising than treating a symlink to a directory as a file. And if you consider this as a short comming of the documentation this isn't (IMHO) a subtlety. The (my?) intuition says: all entries of a root (apart from . and .. as documented) are included in either dirnames or filenames. Yes, changing behaviour here might break some code, but this applies to all changes. For some usecases it might be right to just skip over symlinks-to-dirs, but if it's not you have to opendir + read all root entries again in the loop to find all symlinks which effectively means reimplementing os.walk. -- nosy: +ukl ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12970 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2091] file accepts 'rU+' as a mode
Francis MB added the comment: On the other hand, the documentation *does* mention that 'U' is for backwards compatibility and shouldn't be used with new code. Shouldn't be some deprecation warning somewhere? -- nosy: +francismb ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2091 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21645] asyncio: Race condition in signal handling on FreeBSD
Roundup Robot added the comment: New changeset c4f053f1b47f by Victor Stinner in branch '3.4': Python issue #21645, Tulip issue 192: Rewrite signal handling http://hg.python.org/cpython/rev/c4f053f1b47f New changeset 2176496951a4 by Victor Stinner in branch 'default': (Merge 3.4) Python issue #21645, Tulip issue 192: Rewrite signal handling http://hg.python.org/cpython/rev/2176496951a4 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21645 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21959] msi product code for 2.7.8150 not in Tools/msi/uuids.py
R. David Murray added the comment: It looks like this issue can be closed? -- nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21959 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17113] argparse.RawDescriptionHelpFormatter should not delete blank lines
paul j3 added the comment:
I suspect fixing this isn't going to be easy.
Extra lines are removed by the top most `formatter` function:
def format_help(self):
help = self._root_section.format_help()
if help:
help = self._long_break_matcher.sub('\n\n', help)
help = help.strip('\n') + '\n'
return help
RawDescriptionHelpFormatter on the other hand just changes one deeply embedded
function:
def _fill_text(self, text, width, indent):
return ''.join(indent + line for line in text.splitlines(keepends=True))
That `format_help` function has no way of distinguishing between '\n' that were
part of the raw text, and which were added while assembling the various parts.
It could be instructive to try this version of format_help and see just how
many \n are being removed:
def format_help(self):
help = self._root_section.format_help()
return help
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17113
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21645] asyncio: Race condition in signal handling on FreeBSD
STINNER Victor added the comment: I commited the patch into Tulip (c149370c8027), Python 3.4 (c4f053f1b47f), Python 3.5 (2176496951a4). I'm now waiting for the buildbot. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21645 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21959] msi product code for 2.7.8150 not in Tools/msi/uuids.py
Steve Dower added the comment: Yes. I don't have permission to close issues. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21959 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21959] msi product code for 2.7.8150 not in Tools/msi/uuids.py
R. David Murray added the comment: Well, that's a bit of an oversight :) Now you do. -- resolution: - fixed stage: - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21959 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17182] signal.default_int_handler should set signal number on the raised exception
Mark Lawrence added the comment: Just a gentle reminder. -- nosy: +BreamoreBoy versions: +Python 3.5 -Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17182 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17148] mingw: nt thread model detection
Mark Lawrence added the comment: Guys I asked on IRC and was advised to add you to the nosy list to see if you can help out on this. Please be aware that there are plenty more where this came from. -- nosy: +BreamoreBoy, loewis, steve.dower, tim.golden, zach.ware versions: +Python 3.5 -Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17148 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21247] test_asyncio: test_subprocess_send_signal hangs on Fedora builders
Roundup Robot added the comment: New changeset 651475d67225 by Victor Stinner in branch '3.4': Issue #21247: Fix a race condition in test_send_signal() of asyncio http://hg.python.org/cpython/rev/651475d67225 New changeset 45e8eb53edbc by Victor Stinner in branch 'default': (Merge 3.4) Issue #21247: Fix a race condition in test_send_signal() of asyncio http://hg.python.org/cpython/rev/45e8eb53edbc -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21247 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21247] test_asyncio: test_subprocess_send_signal hangs on Fedora builders
Changes by STINNER Victor victor.stin...@gmail.com: -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21247 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21247] test_asyncio: test_subprocess_send_signal hangs on Fedora builders
STINNER Victor added the comment: That appears to work. Thanks! Cool, I commited my enhancement of the unit test. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21247 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1598] unexpected response in imaplib
Lita Cho added the comment: I spent the last 2 hours trying to setup a Lotus Server, which is ending up to be a lot more work then I thought in order to test this bug. Is there anyway I can get a test Lotus account on a Lotus Server to test this bug? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1598 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17185] unittest mock create_autospec doesn't correctly replace mocksignature
Mark Lawrence added the comment: Just curiosity why such a name change? -- components: +Tests nosy: +BreamoreBoy title: create_autospec - unittest mock create_autospec doesn't correctly replace mocksignature type: - behavior versions: +Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17185 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17210] documentation of PyUnicode_Format() states wrong argument type requirements
Mark Lawrence added the comment: @Stefan could you provide a patch for this? -- nosy: +BreamoreBoy versions: +Python 3.5 -Python 2.6, Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17210 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17274] distutils silently omits relative symlinks
Mark Lawrence added the comment: @Florian can you provide a patch for this? -- nosy: +BreamoreBoy type: - behavior versions: +Python 2.7, Python 3.4, Python 3.5 -Python 2.6, Python 3.1, Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17274 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22003] BytesIO copy-on-write
New submission from David Wilson: This is a followup to the thread at https://mail.python.org/pipermail/python-dev/2014-July/135543.html , discussing the existing behaviour of BytesIO copying its source object, and how this regresses compared to cStringIO.StringI. The goal of posting the patch on list was to try and stimulate discussion around the approach. The patch itself obviously isn't ready for review, and I'm not in a position to dedicate time to it just now (although in a few weeks I'd love to give it full attention!). Ignoring this quick implementation, are there any general comments around the approach? My only concern is that it might keep large objects alive in a non-intuitive way in certain circumstances, though I can't think of any obvious ones immediately. Also interested in comments on the second half of that thread: a natural extension of this is to do something very similar on the write side: instead of generating a temporary private heap allocation, generate (and freely resize) a private PyBytes object until it is exposed to the user, at which point, _getvalue() returns it, and converts its into an IO_SHARED buffer. There are quite a few interactions with making that work correctly, in particular: * How BytesIO would implement the buffers interface without causing the under-construction Bytes to become readonly * Avoiding redundant copies and resizes -- we can't simply tack 25% slack on the end of the Bytes and then truncate it during getvalue() without likely triggering a copy and move, however with careful measurement of allocator behavior there are various tradeoffs that could be made - e.g. obmalloc won't move a 500 byte allocation if it shrinks by 25%. glibc malloc's rules are a bit more complex though. Could also add a private _PyBytes_SetSize() API to allow truncation to the final size during getvalue() without informing the allocator. Then we'd simply overallocate by up to 10% or 1-2kb, and write off the loss of the slack space. Notably, this approach completely differs from the one documented in http://bugs.python.org/issue15381 .. it's not clear to me which is better. -- components: Library (Lib) files: cow.patch keywords: patch messages: 223383 nosy: dw priority: normal severity: normal status: open title: BytesIO copy-on-write type: performance versions: Python 3.5 Added file: http://bugs.python.org/file35988/cow.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22003 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17286] Make subprocess handling text output with universal_newlines more obious
Mark Lawrence added the comment: @Baptiste can you provide a patch for this? -- nosy: +BreamoreBoy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17286 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22003] BytesIO copy-on-write
David Wilson added the comment: Submitted contributor agreement. Please consider the demo patch licensed under the Apache 2 licence. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22003 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22003] BytesIO copy-on-write
Changes by Antoine Pitrou pit...@free.fr: -- nosy: +benjamin.peterson, hynek, pitrou, stutzbach ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22003 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22003] BytesIO copy-on-write
Antoine Pitrou added the comment: Be careful what happens when the original object is mutable: b = bytearray(babc) bio = io.BytesIO(b) b[:] = bdefghi bio.getvalue() b'abc' I don't know what your patch does in this case. -- nosy: +serhiy.storchaka stage: - needs patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22003 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18320] python installation is broken if prefix is overridden on an install target
cosmicduck added the comment: Hi, this is a problem for all users which have to want to use python on there own home directory. I wonder me, how did some other projects could install python to different directories e.g. OpenCSW it did on /opt/csw/... My most problem is, that I can do many but without root access, which is denied. In this case a installation/build to a different path is very helpfull. The situation was, that python and there most modules are working well also post installed ones. Only the problem with the shebang to the scripts was the major problems which I've fixed by a line change on all scripts. But to build python on a different root path e.g. my home folder, this should be changed simply by make itself and not by hand as I did it. I'm unsure that other problems with my steps exists, but only the shebang problem is found by me. This problem could also exists on later releases than 3.3. So for me it's ok to close this issue for 3.3. But for later releases, e.g. 3.4 it should checked and fixed, please. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18320 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17113] argparse.RawDescriptionHelpFormatter should not delete blank lines
paul j3 added the comment: A user could preserve blank lines by including a space (or more) in each. That is, instead of ending with '\n', end with '\n \n'. epilog = 'Epilog: No wrap text %(prog)s\n\tNext line\n \n' --- I just checked a simple help. The description and epilog get an extra blank line during assembly. If 'epilog=None', there are 2 blank lines, which normally get reduced to one \n. So the philosophy of the formatter is to freely add \n between sections, regardless of whether they are empty (None) or not, and then deal with excess \n at the end. Preserving blank lines during Raw requires rethinking that underlying philosophy. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17113 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18320] python installation is broken if prefix is overridden on an install target
Ned Deily added the comment:
cosmicduck, the recommended and supported way to do this is by specifying the
installation prefix at the configure step, not at the make install step:
./configure --prefix=${HOME}/scripts/tools/python/python-3.3.2
make
make install
If done this way, the installed scripts will have the correct shebang lines and
Distutils will install properly.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18320
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18395] Make _Py_char2wchar() and _Py_wchar2char() public
Changes by Thomas Kluyver tak...@gmail.com: -- nosy: +takluyver ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18395 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17293] uuid.getnode() MAC address on AIX
Mark Lawrence added the comment: @Aivars sorry about the delay in getting back to you. -- nosy: +BreamoreBoy, David.Edelsohn type: - behavior versions: +Python 3.4, Python 3.5 -Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17293 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17308] Dialog.py crashes when putty Window resized
Mark Lawrence added the comment: I'm sorry but this site is for reporting bugs on Python itself, not on third party packages. -- nosy: +BreamoreBoy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17308 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17362] enable-new-dtags only for GNU ELF linker
Mark Lawrence added the comment: Can someone comment on this please as I haven't got a clue, sorry :( -- nosy: +BreamoreBoy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17362 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18395] Make _Py_char2wchar() and _Py_wchar2char() public
Josh Rosenberg added the comment: How often do people need to convert to do platform independent locale encoding before Python is initialized? Encouraging use of platform dependent wchar_t's seems like a bad idea when PyUnicode abstracts away the difference ever since 3.3 released. -- nosy: +josh.rosenberg ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18395 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17127] multiprocessing.dummy.Pool does not accept maxtasksperchild argument
Josh Rosenberg added the comment: Note: To my knowledge there is little or no benefit to using maxtasksperchild when the implementation is using threads. Cleaning up worker processes intermittently will guarantee that memory, handles, etc., are returned to the OS. But memory and handles allocated in a thread are not freed when the thread exits (with the exception of explicitly thread local stuff, which isn't common); it's all using the same heap, and memory allocated by thread 1 is indistinguishable from memory allocated by thread 2. It's not a bad idea to keep the interface consistent, but I'm not sure it's a good idea to offer and implement a behavior that isn't actually accomplishing anything. Anyone else have any thoughts? -- nosy: +josh.rosenberg ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17127 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17127] multiprocessing.dummy.Pool does not accept maxtasksperchild argument
Josh Rosenberg added the comment: Actually, now that I think about, most thread local stuff wouldn't be freed automatically either, since it's still allocated from a common pool of memory, and interleaved allocations would still prevent memory blocks from being returned to the OS. As far as behavior goes, assuming you aren't explicitly checking thread IDs (which should be meaningless to worker threads anyway; the tasks are assigned arbitrarily), clearing out the thread local storage when a thread exits would be equivalent to ending one worker thread and starting a new one. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17127 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18395] Make _Py_char2wchar() and _Py_wchar2char() public
Thomas Kluyver added the comment: You seem to need wchar_t to call Py_Main and Py_SetProgramName. I think there's an example in the docs which is wrong, because it appears to pass a char* to Py_SetProgramName: https://docs.python.org/3.4/extending/embedding.html#very-high-level-embedding -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18395 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21997] Pdb.set_trace debugging does not end correctly in IDLE
Changes by ppperry maprea...@olum.org: -- hgrepos: +264 nosy: +georg.brandl, terry.reedy -ppperry ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21997 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21997] Pdb.set_trace debugging does not end correctly in IDLE
Changes by ppperry maprea...@olum.org: -- hgrepos: -264 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21997 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17308] Dialog.py crashes when putty Window resized
Changes by Berker Peksag berker.pek...@gmail.com: -- resolution: - third party stage: - resolved status: open - closed type: crash - behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17308 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
