[issue7883] CallTips.py _find_constructor does not work
Bernt Røskar Brenna added the comment: Attached is Lib/test/test_idlelib.py, containing a unit test for the issue. -- Added file: http://bugs.python.org/file24075/test_idlelib.py ___ Python tracker <http://bugs.python.org/issue7883> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7876] unittest docs use deprecated method in code example
New submission from Bernt Røskar Brenna : Suggest change the code example to use assertRaises instead of failUnlessRaises. The docs read: assertRaises(exception[, callable, ...])¶ failUnlessRaises(exception[, callable, ...])¶ with self.failUnlessRaises(some_error_class): do_something() ... Deprecated since version 3.1: failUnlessRaises() -- assignee: georg.brandl components: Documentation messages: 99017 nosy: Bernt.Røskar.Brenna, georg.brandl severity: normal status: open title: unittest docs use deprecated method in code example versions: Python 3.1 ___ Python tracker <http://bugs.python.org/issue7876> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7876] unittest docs use deprecated method in code example
Bernt Røskar Brenna added the comment: Sorry, forgot to check svn, I was looking at the 3.1.1 release tarball. -- ___ Python tracker <http://bugs.python.org/issue7876> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7883] CallTips.py _find_constructor does not work
New submission from Bernt Røskar Brenna : Test case: In IDLE python shell: >>> from http.client import HTTPConnection >>> c = HTTPConnection( Notice that the call tip is an empty parenthesis. This patch works for me: [/tmp/py3k/Lib/idlelib] $ svn diff Index: CallTips.py === --- CallTips.py (revision 78103) +++ CallTips.py (working copy) @@ -116,7 +116,7 @@ def _find_constructor(class_ob): "Find the nearest __init__() in the class tree." try: -return class_ob.__init__.__func__ +return class_ob.__init__ except AttributeError: for base in class_ob.__bases__: init = _find_constructor(base) -- components: IDLE messages: 99043 nosy: Bernt.Røskar.Brenna severity: normal status: open title: CallTips.py _find_constructor does not work type: behavior versions: Python 3.1, Python 3.2 ___ Python tracker <http://bugs.python.org/issue7883> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7884] IDLE 3.1.1 crashes with UnicodeDecodeError when I press Ctrl-Space
New submission from Bernt Røskar Brenna : Platform: Linux Python 3.1.1 built from source. Tk version 8.4, Tcl version 8.4. Idle 2.6.4 (also built from source), works correctly (executes force-open-completions). Test case: - Start idle3 - press Ctrl-Space in the IDLE shell - idle crashes, and a traceback is written to stdout: Traceback (most recent call last): File "/usr/local/bin/idle3", line 6, in main() File "/usr/local/lib/python3.1/idlelib/PyShell.py", line 1420, in main root.mainloop() File "/usr/local/lib/python3.1/tkinter/__init__.py", line 1009, in mainloop self.tk.mainloop(n) UnicodeDecodeError: 'utf8' codec can't decode bytes in position 0-1: illegal encoding -- components: IDLE, Tkinter messages: 99044 nosy: Bernt.Røskar.Brenna severity: normal status: open title: IDLE 3.1.1 crashes with UnicodeDecodeError when I press Ctrl-Space type: crash versions: Python 3.1 ___ Python tracker <http://bugs.python.org/issue7884> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36227] Add default_namespace argument to xml.etree.ElementTree.tostring()
New submission from Bernt Røskar Brenna : default_namespace is often used when serializing ET elements. tostring() is mainly a wrapper around ElementTree.write(), and it is therefore natural that it mirrors write's argument. tostring() already passes encoding, method and short_empty_elements to write. -- components: Library (Lib) messages: 337428 nosy: Bernt.Røskar.Brenna priority: normal severity: normal status: open title: Add default_namespace argument to xml.etree.ElementTree.tostring() type: enhancement versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue36227> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36227] Add default_namespace argument to xml.etree.ElementTree.tostring()
Change by Bernt Røskar Brenna : -- keywords: +patch pull_requests: +12215 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue36227> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36227] Add default_namespace argument to xml.etree.ElementTree.tostring()
Bernt Røskar Brenna added the comment: I will add xml_declaration and push to the existing PR. -- ___ Python tracker <https://bugs.python.org/issue36227> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36227] Add default_namespace argument to xml.etree.ElementTree.tostring()
Bernt Røskar Brenna added the comment: I pushed changes to the PR. I also added xml_declaration and default_namespace to the tostringlist() method. -- ___ Python tracker <https://bugs.python.org/issue36227> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31256] xml.etree.ElementTree: add support for doctype in tostring method
Change by Bernt Røskar Brenna : -- keywords: +patch pull_requests: +12225 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue31256> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31256] xml.etree.ElementTree: add support for doctype in tostring method
Bernt Røskar Brenna added the comment: See also: https://bugs.python.org/issue36227 PR: https://github.com/python/cpython/pull/12225 -- nosy: +Bernt.Røskar.Brenna ___ Python tracker <https://bugs.python.org/issue31256> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36399] multiprocessing: Queue does not work in virtualenv but works fine in main interpreter
New submission from Bernt Røskar Brenna :
When executing mp_queue_example.py in the system interpreter:
D:\dev\eva_v_next>d:\python372\python.exe mp_queue_example.py
main, pid=892, executable=d:\python372\python.exe
process_worker, pid=12848, executable=d:\python372\python.exe
submitting...
submitting 0
submitting 1
submitting 2
Executing job 0
Executing job 1
Executing job 2
When executing mp_queue_example.py in a virtualenv:
D:\dev\eva_v_next>VENV\Scripts\python.exe mp_queue_example.py
main, pid=25888, executable=D:\dev\eva_v_next\VENV\Scripts\python.exe
process_worker, pid=28144, executable=D:\dev\eva_v_next\VENV\Scripts\python.exe
submitting...
submitting 0
submitting 1
submitting 2
## Here it hangs, Ctrl-C gives this:
Process Process-1:
Traceback (most recent call last):
File "D:\dev\eva_v_next\mp_queue_example.py", line 13, in process_worker
inp = input_q.get_nowait()
File "D:\python372\lib\multiprocessing\queues.py", line 126, in get_nowait
return self.get(False)
File "D:\python372\lib\multiprocessing\queues.py", line 100, in get
raise Empty
_queue.Empty
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "D:\python372\lib\multiprocessing\process.py", line 297, in _bootstrap
self.run()
File "D:\python372\lib\multiprocessing\process.py", line 99, in run
self._target(*self._args, **self._kwargs)
File "D:\dev\eva_v_next\mp_queue_example.py", line 13, in process_worker
inp = input_q.get_nowait()
KeyboardInterrupt
Traceback (most recent call last):
File "mp_queue_example.py", line 43, in
main_process_experiment()
File "mp_queue_example.py", line 39, in main_process_experiment
p.join()
File "D:\python372\lib\multiprocessing\process.py", line 140, in join
res = self._popen.wait(timeout)
File "D:\python372\lib\multiprocessing\popen_spawn_win32.py", line 80, in wait
res = _winapi.WaitForSingleObject(int(self._handle), msecs)
KeyboardInterrupt
---
mp_queue_example.py:
import multiprocessing as mp
from queue import Empty
import os
import sys
import time
def process_worker(input_q: mp.Queue):
print(f'process_worker, pid={os.getpid()}, executable={sys.executable}')
while True:
try:
inp = input_q.get_nowait()
if inp == 'STOP':
break
execute_job(inp)
except Empty:
pass
def execute_job(input_args):
print(f'Executing job {input_args}')
def main_process_experiment():
print(f"main, pid={os.getpid()}, executable={sys.executable}")
input_q = mp.Queue()
p = mp.Process(target=process_worker, args=(input_q, ))
p.start()
time.sleep(0.5)
print('submitting...')
for i in range(3):
print(f'submitting {i}')
input_q.put(i)
input_q.put('STOP')
p.join()
if __name__ == '__main__':
main_process_experiment()
--
components: Library (Lib)
files: mp_queue_example.py
messages: 338591
nosy: Bernt.Røskar.Brenna
priority: normal
severity: normal
status: open
title: multiprocessing: Queue does not work in virtualenv but works fine in
main interpreter
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file48228/mp_queue_example.py
___
Python tracker
<https://bugs.python.org/issue36399>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36399] multiprocessing: Queue does not work in virtualenv but works fine in main interpreter
Bernt Røskar Brenna added the comment: I just checked using 3.6. The program does NOT hang when executed from a 3.6 virtualenv. So this is a possible regression (or something could be messed up on my system). D:\dev\eva_v_next>VENV36\Scripts\python.exe mp_queue_example.py main, pid=28956, executable=D:\dev\eva_v_next\VENV36\Scripts\python.exe process_worker, pid=8924, executable=D:\dev\eva_v_next\VENV36\Scripts\python.exe submitting... submitting 0 submitting 1 submitting 2 Executing job 0 Executing job 1 Executing job 2 -- ___ Python tracker <https://bugs.python.org/issue36399> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36399] multiprocessing: Queue does not work in virtualenv but works fine in main interpreter
Bernt Røskar Brenna added the comment: Versions: > VENV\Scripts\python.exe --version Python 3.7.2 > VENV36\Scripts\python.exe --version Python 3.6.8 -- ___ Python tracker <https://bugs.python.org/issue36399> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36399] multiprocessing: Queue does not work in virtualenv but works fine in main interpreter
Bernt Røskar Brenna added the comment: I also checked using 3.8 (built from commit 1f58f4fa6a0e3c60cee8df4a35c8dcf3903acde8), and it works there, so it looks as if 3.7 is the problem. > VENV38\Scripts\python.exe --version Python 3.8.0a2+ > VENV38\Scripts\python.exe mp_queue_example.py main, pid=8284, executable=D:\dev\eva_v_next\VENV38\Scripts\python.exe process_worker, pid=16396, executable=D:\dev\cpython\PCbuild\win32\python.exe submitting... submitting 0 submitting 1 submitting 2 Executing job 0 Executing job 1 Executing job 2 -- ___ Python tracker <https://bugs.python.org/issue36399> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19575] subprocess.Popen with multiple threads: Redirected stdout/stderr files still open after process close
New submission from Bernt Røskar Brenna:
Running the following task using concurrent.futures.ThreadPoolExecutor works
with max_workers == 1 and fails when max_workers > 1 :
def task():
dirname = tempfile.mkdtemp()
f_w = open(os.path.join(dirname, "stdout.txt"), "w")
f_r = open(os.path.join(dirname, "stdout.txt"), "r")
e_w = open(os.path.join(dirname, "stderr.txt"), "w")
e_r = open(os.path.join(dirname, "stderr.txt"), "r")
with subprocess.Popen("dir", shell=True, stdout=f_w, stderr=e_w) as p:
pass
f_w.close()
f_r.close()
e_w.close()
e_r.close()
shutil.rmtree(dirname)
The exception is raised by shutil.rmtree when max_workers > 1: "The process
cannot access the file because it is being used by another process"
See also this Stack Overflow question about what seems to bee a similar
problem:
http://stackoverflow.com/questions/15966418/python-popen-on-windows-with-multithreading-cant-delete-stdout-stderr-logs
The discussion on SO indicates that this might be an XP problem only.
The attached file reproduces the problem on my Windows XP VM.
--
components: Library (Lib), Windows
files: repro.py
messages: 202779
nosy: Bernt.Røskar.Brenna
priority: normal
severity: normal
status: open
title: subprocess.Popen with multiple threads: Redirected stdout/stderr files
still open after process close
versions: Python 3.3
Added file: http://bugs.python.org/file32602/repro.py
___
Python tracker
<http://bugs.python.org/issue19575>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19575] subprocess.Popen with multiple threads: Redirected stdout/stderr files still open after process close
Bernt Røskar Brenna added the comment:
Simpler task method that still reproduces the problem:
def task():
dirname = tempfile.mkdtemp()
f_w = open(os.path.join(dirname, "stdout.txt"), "w")
e_w = open(os.path.join(dirname, "stderr.txt"), "w")
with subprocess.Popen("dir", shell=True, stdout=f_w, stderr=e_w) as p:
pass
f_w.close()
e_w.close()
shutil.rmtree(dirname)
--
___
Python tracker
<http://bugs.python.org/issue19575>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19575] subprocess.Popen with multiple threads: Redirected stdout/stderr files still open after process close
Bernt Røskar Brenna added the comment: No indexing and no virus scanner running. Note that it never fails if running in a single thread. IMO, this indicates that external processes interfering is not the problem. -- ___ Python tracker <http://bugs.python.org/issue19575> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19575] subprocess.Popen with multiple threads: Redirected stdout/stderr files still open after process close
Bernt Røskar Brenna added the comment: Here's an improved repro script. I believe it demonstrates that it is the combination of subprocess.Popen and threading that causes the problem. Here's the output from my Windows XP VM: *** c:\...> c:\Python33\python.exe repro_improved.py Windows-XP-5.1.2600-SP3 Concurrency: 2 Task kind: subprocess_redirfile 3 errors of 10 Concurrency: 1 Task kind: subprocess_redirfile 0 errors of 10 Concurrency: 2 Task kind: subprocess_devnull 5 errors of 10 Concurrency: 1 Task kind: subprocess_devnull 0 errors of 10 Concurrency: 2 Task kind: nosubprocess 0 errors of 10 Concurrency: 1 Task kind: nosubprocess 0 errors of 10 *** Note that: - even when subprocess redirects to DEVNULL there are errors - when no subprocess.Popen is executed, no errors occur (the file is created as normal, but is not used by subprocess.Popen) -- Added file: http://bugs.python.org/file32604/repro_improved.py ___ Python tracker <http://bugs.python.org/issue19575> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19575] subprocess.Popen with multiple threads: Redirected stdout/stderr files still open after process close
Bernt Røskar Brenna added the comment: Another script, another test case. Four different tasks are run: subprocess_redirfile: Popen(stdout=file) subprocess_devnull: Popen(stdout=DEVNULL) subprocess_noredirect: Popen() nosubprocess: No Popen() call Judging from the output it looks as if it is the redirection that triggers this behavior. Here's the output from my Win XP computer: Platform: Windows-XP-5.1.2600-SP3 task_type #threads result subprocess_redirfile 2 4 errors subprocess_redirfile 1 OK subprocess_devnull2 5 errors subprocess_devnull1 OK subprocess_noredirect 2 OK subprocess_noredirect 1 OK nosubprocess 2 OK nosubprocess 1 OK -- Added file: http://bugs.python.org/file32613/testcase3.py ___ Python tracker <http://bugs.python.org/issue19575> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19575] subprocess.Popen with multiple threads: Redirected stdout/stderr files still open after process close
Bernt Røskar Brenna added the comment: Similar result on Windows Server 2008: Platform: Windows-2008ServerR2-6.1.7600 task_type #threads result subprocess_redirfile 2 9 errors subprocess_redirfile 1 OK subprocess_devnull2 9 errors subprocess_devnull1 OK subprocess_noredirect 2 OK subprocess_noredirect 1 OK nosubprocess 2 OK nosubprocess 1 OK -- ___ Python tracker <http://bugs.python.org/issue19575> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19575] subprocess.Popen with multiple threads: Redirected stdout/stderr files still open after process close
Bernt Røskar Brenna added the comment: @neologix: How can it not have anything to do with threads? - It always works with max_workers == 1 - When max_workers == 2, shutil.rmtree sometimes fails -- ___ Python tracker <http://bugs.python.org/issue19575> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19575] subprocess.Popen with multiple threads: Redirected stdout/stderr files still open after process close
Changes by Bernt Røskar Brenna : -- nosy: +astrand ___ Python tracker <http://bugs.python.org/issue19575> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19575] subprocess.Popen with multiple threads: Redirected stdout/stderr files still open after process close
Bernt Røskar Brenna added the comment: @neologix: But how do you explain this: subprocess_devnull2 9 errors subprocess_devnull1 OK subprocess_devnull creates a file, then starts a subprocess (that redirects to DEVNULL, does not use the file), then tries to remove the directory containing the file. When running in parallel, it fails. subprocess_noredirect 2 OK subprocess_noredirect 1 OK subprocess_noredirect creates a file, then starts a subprocess (that does not use the file), then tries to remove the directory containing the file. When running in parallel, it does not fail. -- ___ Python tracker <http://bugs.python.org/issue19575> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19575] subprocess.Popen with multiple threads: Redirected stdout/stderr files still open after process close
Bernt Røskar Brenna added the comment: I just tested on 3.4a0. Observed the following changes: - subprocess_devnull now NEVER fails. - subprocess_redirfile does not fail as often as before, but still fails. I changed the number of tasks to 20 and increased max_workers to 5 to get subprocess_redirfile to fail at least one of twenty times every time I invoked the test script. A typical result on 3.4 looks like this: Platform: Windows-XP-5.1.2600-SP3 task_type #threads result subprocess_redirfile 5 3 errors subprocess_redirfile 1 OK subprocess_devnull5 OK subprocess_devnull1 OK subprocess_noredirect 5 OK subprocess_noredirect 1 OK nosubprocess 5 OK nosubprocess 1 OK -- ___ Python tracker <http://bugs.python.org/issue19575> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19575] subprocess.Popen with multiple threads: Redirected stdout/stderr files still open after process close
Bernt Røskar Brenna added the comment: Increasing max_workers to 5 and running 20 tasks highlighs the 3.3-3.4 difference (code in attached file testscript4.py): Version: 3.4.0a4 (v3.4.0a4:e245b0d7209b, Oct 20 2013, 19:23:45) [MSC v.1600 32 b it (Intel)] Platform: Windows-XP-5.1.2600-SP3 Tasks: 20 task_type #threads result subprocess_redirfile 5 4 errors (of 20) subprocess_redirfile 1 OK subprocess_devnull5 OK subprocess_devnull1 OK subprocess_noredirect 5 OK subprocess_noredirect 1 OK nosubprocess 5 OK nosubprocess 1 OK Version: 3.3.2 (v3.3.2:d047928ae3f6, May 16 2013, 00:03:43) [MSC v.1600 32 bit ( Intel)] Platform: Windows-XP-5.1.2600-SP3 Tasks: 20 task_type #threads result subprocess_redirfile 5 18 errors (of 20) subprocess_redirfile 1 OK subprocess_devnull5 19 errors (of 20) subprocess_devnull1 OK subprocess_noredirect 5 OK subprocess_noredirect 1 OK nosubprocess 5 OK nosubprocess 1 OK -- Added file: http://bugs.python.org/file32685/testscript4.py ___ Python tracker <http://bugs.python.org/issue19575> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19575] subprocess.Popen with multiple threads: Redirected stdout/stderr files still open after process close
Changes by Bernt Røskar Brenna : -- versions: +Python 3.4 ___ Python tracker <http://bugs.python.org/issue19575> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19575] subprocess.Popen with multiple threads: Redirected stdout/stderr files still open after process close
Changes by Bernt Røskar Brenna : -- components: +IO ___ Python tracker <http://bugs.python.org/issue19575> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19575] subprocess.Popen with multiple threads: Redirected stdout/stderr files still open after process close
Bernt Røskar Brenna added the comment: I tested, and locking around the subprocess.Popen call indeed works on Python 3.4. Thanks! Do you have any tips on how to accomplish the same thing on Python 3.3 (locking around Popen did not make any difference on 3.3)? -- ___ Python tracker <http://bugs.python.org/issue19575> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19575] subprocess.Popen with multiple threads: Redirected stdout/stderr files still open after process close
Bernt Røskar Brenna added the comment: Never mind, I figured it: On Python 3.3, the combination of locking around Popen and opening the file that I redirect to using the code below works (code from scons): def open_noinherit(*args, **kwargs): fp = open(*args, **kwargs) win32api.SetHandleInformation(msvcrt.get_osfhandle(fp.fileno()), win32con.HANDLE_FLAG_INHERIT, 0) return fp -- ___ Python tracker <http://bugs.python.org/issue19575> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19575] subprocess.Popen with multiple threads: Redirected stdout/stderr files still open after process close
Bernt Røskar Brenna added the comment: And here's a function that does not require pywin32: def open_noinherit_ctypes(*args, **kwargs): HANDLE_FLAG_INHERIT = 1 import msvcrt from ctypes import windll, WinError fp = open(*args, **kwargs) if not windll.kernel32.SetHandleInformation(msvcrt.get_osfhandle(fp.fileno()), HANDLE_FLAG_INHERIT, 0): raise WinError() return fp -- ___ Python tracker <http://bugs.python.org/issue19575> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20529] Unittest displays ResourceWarning warnings when running tests, it probably should not
New submission from Bernt Røskar Brenna:
Given the following file test_reswarn.py:
import unittest
class TestResourceWarning(unittest.TestCase):
def test_it(self):
self.assertIn("TestResourceWarning", open(__file__).read())
Running the test:
$ python -m unittest test_reswarn.py
./test_reswarn.py:6: ResourceWarning: unclosed file <_io.TextIOWrapper
name='./test_reswarn.py' mode='r' encoding='UTF-8'>
self.assertIn("TestResourceWarning", open(__file__).read())
.
--
Ran 1 test in 0.000s
OK
When running the unit test using unittest, ResourceWarning warnings are
displayed. In my experience using open("filename") without explicitly closing
the file is pretty common and would usually not be an error, since the file
will be closed when the reference goes out of scope (or am I wrong?).
Therefore I believe that unittest should not emit ResourceWarning warnings.
--
components: Library (Lib)
messages: 210377
nosy: Bernt.Røskar.Brenna
priority: normal
severity: normal
status: open
title: Unittest displays ResourceWarning warnings when running tests, it
probably should not
type: behavior
versions: Python 3.3
___
Python tracker
<http://bugs.python.org/issue20529>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20529] Unittest displays ResourceWarning warnings when running tests, it probably should not
Bernt Røskar Brenna added the comment: OK I see. I'll just use: python -W ignore:ResourceWarning -m unittest -- ___ Python tracker <http://bugs.python.org/issue20529> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25461] Unclear language (the word ineffective) in the documentation for os.walk
New submission from Bernt Røskar Brenna: At least for me (non-english speaker), the following is confusing: "Modifying dirnames when topdown is False is ineffective, because in bottom-up mode the directories in dirnames are generated before dirpath itself is generated." I suggest to replace "is ineffective" with "has no effect". Ineffective could also mean: "Has low performance", could it not? -- assignee: docs@python components: Documentation messages: 253338 nosy: Bernt.Røskar.Brenna, docs@python priority: normal severity: normal status: open title: Unclear language (the word ineffective) in the documentation for os.walk type: enhancement versions: Python 2.7, Python 3.5 ___ Python tracker <http://bugs.python.org/issue25461> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25461] Unclear language (the word ineffective) in the documentation for os.walk
Bernt Røskar Brenna added the comment: OK, I'll submit a patch -- ___ Python tracker <http://bugs.python.org/issue25461> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25461] Unclear language (the word ineffective) in the documentation for os.walk
Changes by Bernt Røskar Brenna : -- keywords: +patch Added file: http://bugs.python.org/file40846/os_walk_docs_change_unclear_language.patch ___ Python tracker <http://bugs.python.org/issue25461> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25461] Unclear language (the word ineffective) in the documentation for os.walk
Bernt Røskar Brenna added the comment: I agree your suggestion is better, I did not see it before submitting my first patch. I've added another patch. -- Added file: http://bugs.python.org/file40847/os_walk_docs_change_unclear_language_2.patch ___ Python tracker <http://bugs.python.org/issue25461> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25461] Unclear language (the word ineffective) in the documentation for os.walk
Bernt Røskar Brenna added the comment: A question/comment: In this case (and there are probably other cases like it) - it seems to me that the docstring (in os.py) and the docs (in os.rst) are similar enough that the docstring from the code could be included in the docs (using Sphinx's autodoc). What is the preferred way? Is there a reason to have it the way it is? I notice the .rst docs have some formatting applied, is it considered not OK to put formatting in docstrings? -- ___ Python tracker <http://bugs.python.org/issue25461> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25461] Unclear language (the word ineffective) in the documentation for os.walk
Bernt Røskar Brenna added the comment: Yet another patch, this time including changes to os.walk()'s docstring as well. Ignore the two other files. -- Added file: http://bugs.python.org/file40849/os_walk_doc.patch ___ Python tracker <http://bugs.python.org/issue25461> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
