[issue16737] Different behaviours in script run directly and via runpy.run_module
Changes by Eric Snow ericsnowcurren...@gmail.com: -- nosy: +eric.snow ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16737 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16748] Make CPython test package discoverable
Changes by Eric Snow ericsnowcurren...@gmail.com: -- nosy: +eric.snow ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16748 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11995] test_pydoc loads all Python modules
Changes by Eric Snow ericsnowcurren...@gmail.com: -- nosy: +eric.snow ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11995 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17037] Add conforms_to_pep399() to test.support
Eric Snow added the comment: The decorator also mitigates the problem described in issue #16835. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17037 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16770] Selection in IDLE often skips first character
Ned Deily added the comment: Using Cocoa Tk 8.5.13 and IDLE from either 2.7.3 and 3.3.0 on OS X 10.8.2, I can reproduce the behavior you report. However, I do not see the behavior when using Python 2.7.3 linked with the older Carbon Tk 8.4. I tried without success to reproduce the behavior using a stripped down version of one of the Tk Text widget demos in Wish 8.5. To me, the most likely cause is either an issue within Tk itself or a Tk 8.5 difference not handled by Tkinter and/or IDLE. In any case, it seems like a rather minor annoyance compared with most IDLE or Tkinter issues. If someone wants to investigate further, please feel free to do so. -- assignee: ned.deily - priority: normal - low resolution: out of date - stage: committed/rejected - ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16770 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17038] multiprocessing only use one core when C module are imported
New submission from HadiM: Hi, This is the first time I report a bug so if I did something wrong please let me know. I also tried to ask on #python and #python-fr before posting here to know if it was a bug or a possible multiprocessing limitation on Linux. So I'm sorry if it's not a bug... The problem appears when a module with .c compiled file is imported (sush as numpy, scipy, pandas, tables, skimage, I did not tested with a custom .c module). Multiprocessing and more specifically imap and map method of Pool class did not distribute processes along all the core but only on one core. This problem does not appears when I don't import a module with .c compiled. I know distributing processes along cores is specific to the OS implementation and not related to Python but I said that to illustrate the behaviour. I should notice that I did not see the bug with a Windows 7, 32 bits (Virtualbox). My laptop run with the latest ubuntu 64bits (tested with both kernel 3.5 and 3.8 last rc). It's a classic Intel(R) Core(TM) i5-2540M CPU @ 2.60GHz with 4 cores. You can try to reproduce the bug with the attached file. You can also find the same file here : http://pastebin.com/jqq9G5Ph Thank you for your time ! -- components: Library (Lib), ctypes files: bug.py messages: 180648 nosy: hadim priority: normal severity: normal status: open title: multiprocessing only use one core when C module are imported type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file28841/bug.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17038 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13454] crash when deleting one pair from tee()
Roundup Robot added the comment: New changeset 4ee8d38398d4 by Serhiy Storchaka in branch '2.7': Optimize the test for issue #13454. http://hg.python.org/cpython/rev/4ee8d38398d4 New changeset d391b2849a51 by Serhiy Storchaka in branch '3.2': Optimize the test for issue #13454. http://hg.python.org/cpython/rev/d391b2849a51 New changeset 2258b4d89c9f by Serhiy Storchaka in branch '3.3': Optimize the test for issue #13454. http://hg.python.org/cpython/rev/2258b4d89c9f New changeset 1f57fb5e1e8e by Serhiy Storchaka in branch 'default': Optimize the test for issue #13454. http://hg.python.org/cpython/rev/1f57fb5e1e8e -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13454 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17038] multiprocessing only use one core when C module are imported
HadiM added the comment: I test to launch bug.py with pypy (import numpypy instead of import numpy) and the bug did not appear. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17038 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1145257] shutil.copystat() may fail...
Neil Muller added the comment: I can't reproduce this bug on windows XP or windows 7 with python 2.7 or python 3.3. Is this still an issue? -- nosy: +Neil Muller ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1145257 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10156] Initialization of globals in unicodeobject.c
Roundup Robot added the comment: New changeset 7c8ad0d02664 by Serhiy Storchaka in branch '2.7': Issue #10156: In the interpreter's initialization phase, unicode globals http://hg.python.org/cpython/rev/7c8ad0d02664 New changeset f7eda8165e6f by Serhiy Storchaka in branch '3.2': Issue #10156: In the interpreter's initialization phase, unicode globals http://hg.python.org/cpython/rev/f7eda8165e6f New changeset 01d4dd412581 by Serhiy Storchaka in branch '3.3': Issue #10156: In the interpreter's initialization phase, unicode globals http://hg.python.org/cpython/rev/01d4dd412581 New changeset cb12d642eed2 by Serhiy Storchaka in branch 'default': Issue #10156: In the interpreter's initialization phase, unicode globals http://hg.python.org/cpython/rev/cb12d642eed2 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10156 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17034] Initialization of globals in stringobject.c and bytesobject.c
Serhiy Storchaka added the comment: And for bytesobject.c in 3.x. -- title: Initialization of globals in stringobject.c - Initialization of globals in stringobject.c and bytesobject.c versions: +Python 3.2, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file28842/bytes_globals.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17034 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10156] Initialization of globals in unicodeobject.c
Serhiy Storchaka added the comment: Committed. Thank you for review, Stefan. Close this issue if the work is finished. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10156 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16235] Add python-config.sh for use during cross compilation.
Roundup Robot added the comment: New changeset c0370730b364 by doko in branch 'default': - Issue #16235: Implement python-config as a shell script. http://hg.python.org/cpython/rev/c0370730b364 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16235 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16235] Add python-config.sh for use during cross compilation.
Matthias Klose added the comment: now committed, using stdin for sed. -- resolution: - fixed stage: patch review - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16235 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16235] Add python-config.sh for use during cross compilation.
Ray Donnelly added the comment: Thank you Matthias! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16235 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15484] CROSS: use _PYTHON_PROJECT_BASE in distutils sysconfig
Roundup Robot added the comment: New changeset f0cde9b6830a by doko in branch '3.3': - Follow-up for issue #15484: In PYTHON_FOR_BUILD, use $(PLATDIR) instead http://hg.python.org/cpython/rev/f0cde9b6830a New changeset 938a045cfe7d by doko in branch 'default': - Follow-up for issue #15484: In PYTHON_FOR_BUILD, use $(PLATDIR) instead http://hg.python.org/cpython/rev/938a045cfe7d -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15484 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17038] multiprocessing only use one core when C module are imported
Charles-François Natali added the comment:
Hello,
So I'm sorry if it's not a bug...
Don't be afraid, we don't byte :-)
Concerning your problem, my guess would be that one of the modules you import
sets the process CPU affinity (maybe as a workaround to mitigate the GIL impact
in multi-threaded code, or whatever) upon import.
And a quick google search returns this:
https://github.com/ipython/ipython/issues/840
To confirm this, you can just do:
strace -e sched_setaffinity python -c import numpy
You can also add
for line in open('/proc/self/status'):
if 'Cpu' in line:
print(line)
Right before and after importing the module, and you'll see that the CPU
affinity has changed.
--
nosy: +neologix
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17038
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17039] socket.SocketIO hides socket timeouts as blocking errors
New submission from Ronny Pfannschmidt: the change to conform with pep 3114 makes socketSocketIO hide Timeouts, since they are also denoted with EAGAIN (which is one of the blocking errors a nonblocking socket will raise) that causes read/readinto return None, when one would expect a Timeout -- messages: 180660 nosy: Ronny.Pfannschmidt priority: normal severity: normal status: open title: socket.SocketIO hides socket timeouts as blocking errors versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17039 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17038] multiprocessing only use one core when C module are imported
HadiM added the comment: Indeed some value change when I print cpu line from /proc/self/status but I don't really understand what that mean... So there is no solution about that ? We cannot use multiprocessing with these modules under Linux ? Do you think I can manually change the CPU affinity or at least block changes made by other modules (without recompiling them of course) ? I guess if it's possible to modify CPU affinity, numpy and other scientific libraries won't be efficient as before, no ? Because the won't share the same cache or something like that, if I get the wikipedia page about cpu affinity. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17038 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3871] cross and native build of python for mingw* hosts
Ray Donnelly added the comment: When I say “our patches” I mean mine and Alexey Pavlov’s jointly maintained patch-set. I hope you don’t mind that I find you saying: I tried some of these patches, but they aren't very organinzed. I really need some docemntaiton to better understand what each patch does and which pairs go together and which don't. ...and then continuing to present a single uber-patch to be mildly funny/ironic? You've already accepted that you should split them up and remove the needless formatting changes to make them more reviewable so I won't labour on this point. ctypes bz2 multiprocessing sqlite3 ssl pyexpat zlib Likewise for ours, but also curses, curses_panel, readline, TKinter, IDLE (and probably more besides) for both Win32, Win64, Mac OS X 32bit and 64bit. The main idea behind our patches is (mostly in common with all patches) that they: 1. Are as atomic as possible in their operation (which as few interdependencies as necessary). 2. Are applied in an obvious ordering. 3. Are named sensibly according to what they do. 4. Build upon - and can reuse updates to - Roumen's uber-patch (and also clean it up a bit; let’s face it Roumen did a lot of the hard work and everyone else is trying to finish it off so we can build releases from it). 5. Enable comprehensive cross-compilation. Given the name of each patch and the fact that they do one thing (the novel ones at least) and that by-and-large they fit on a few screens, I had hoped that they were usefully descriptive. To explain which ones go together: The numbering skips 5 each time for each independent bug-fix or feature - to allow space for later, related modifications. Therefore, where the numbering changes monotonically, the patches are related. This only happens twice, once to address the problem caused by Roumen providing an uber-patch and once due to a block of fixes all related to curses (ncurses and PDCurses are both supported). I assume my addressing of Roumen's uber-patch is what led you to write: However, I'm noticing a ton of descrepancies with these patches. Some are removing pthreads, others are adding them back. There is logic to what you describe as a ton of discrepancies: Roumen's patch is included in it's entirety as 0030-py3k-20121004-MINGW.patch, then I remove one feature of that patch that needed fixing (threading changes) with 0031-py3k-20121004-MINGW-removal-of-pthread-patch.patch, then I add a patch that provides my newer fix, 0032-py3k-20121004-MINGW-ntthreads.patch. The exact same thing happens with the libffi changes. The pthreads stuff needs fixing due to libwinpthread in MinGW-w64 and libffi is broken when targetting a 64bit Windows host. My reason for doing this is so that I can directly drop updated versions from Roumen in over 0030 and it will (in theory at least) still work. He can continue to use a uber-patch if he wishes (though I don't think he does this for new patches). Also by taking this approach, my patch for the threading issues has no dependencies at all on Roumen’s patch, since a previous patch “handled” the dependency by removing that part of it. Everything you said about build environment and the test-suite I agree with. My crucifixion-freedom project includes a .vbs to setup the most basic MSYS and MinGW-w64 environment: https://raw.github.com/mingwandroid/crucifixion-freedom/master/scripts/windows/BootstrapMinGW64.vbs ...this is essential to prevent spending time chasing down issues due to discrepancies between build environments. However, we must go further and add that the patches *cannot* break any other native or cross-compilation, which - as I think Matthias is alluding to - is probably not the case with your patch. This issue is called cross and native build of python for mingw* hosts, so that your patch possibly breaks builds on build-machine is unfortunate (especially so as a build-machine Python is required to run setup.py as part of the cross-build procedure). Even if it doesn't break building for the build-machine it breaks building the cross-MinGW-w64. Each occurrence of /mingw in your patch is probably a part of this problem (you can’t expect cross build systems to be be able to be rooted to /mingw, often you’ll find ~/mingw or /tmp/mingw) You said, It seems some are also compiling and using the mingw version outside of the msys shell, which I'm not certain of the advantages there when u can just use the mscv version, I’m not entirely sure what you mean here; if compiling MinGW Python on a Windows system with my patches, MSYS is 100% a requirement (cmd.exe will never run the configure script). I can only guess this relates to the mingw_posix2win_path stuff in your patch. Forgive me if I’m wrong, but it seems that you are conflating MSYS and MinGW when they are not related (except by frequent proximity). Without wanting to point out the obvious, MinGW-w64 is a sysroot and compiler toolchain for making
[issue17038] multiprocessing only use one core when C module are imported
Charles-François Natali added the comment: Indeed some value change when I print cpu line from /proc/self/status but I don't really understand what that mean... It means that the CPU affinity is changed, so the scheduler binds your process to a subset of the available CPUs. So there is no solution about that ? We cannot use multiprocessing with these modules under Linux ? Do you think I can manually change the CPU affinity or at least block changes made by other modules (without recompiling them of course) ? If you don't want to recompile the offending module (it seems to be GotoBLAS2), you can change the affinity after importing your modules with something like: os.system(taskset -p 0xff %d % os.getpid()) (Python 3.3 exposes the scheduling API natively, see http://docs.python.org/dev/library/os.html#interface-to-the-scheduler) I guess if it's possible to modify CPU affinity, numpy and other scientific libraries won't be efficient as before, no ? Because the won't share the same cache or something like that, if I get the wikipedia page about cpu affinity. Soft affinity is naturally done by the operating system scheduler, so you don't have to worry about cache line bouncing and the like. Hard affinity is only useful in very specific cases. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17038 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17038] multiprocessing only use one core when C module are imported
Changes by Charles-François Natali cf.nat...@gmail.com: -- resolution: - invalid stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17038 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17038] multiprocessing only use one core when C module are imported
HadiM added the comment: Your snippet did the trick ! Thank you for your time. Even if it's not very clean, it's working. Thank again ! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17038 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17010] Windows launcher ignores active virtual environment
Vinay Sajip added the comment: When using an activated virtual environment, there is no need to use py - just use python. Primarily, the launcher looks for a shebang line in a script to determine which interpreter to use for the script. If no shebang line can be found, it will launch the default Python, which is currently the most recent Python 2.x found in the registry. When invoked via py -3 (or with suitable settings in the configuration), it will use the most recent Python 3.x found in the registry. Since venv interpreters are not in the registry, they will never be invoked as the default Python. However, any scripts installed into venvs will have the correct shebang lines, so they will launch with the venv's interpreter. I don't believe this is a bug, as the system is IMO working as designed and as per PEP 397. If the launcher is asked to launch a script which contains a shebang, while a venv is activated, it will run with the interpreter indicated by the shebang, rather than the venv's interpreter. Perhaps one could consider an enhancement whereby if no shebang is found, a different approach is used to find the interpreter - e.g. looking for python on the path before looking in the registry to locate an interpreter. The question arises as to whether this should be tied to a specific condition such as the presence of an environment key PYLAUNCHER_USEPATH. (This is of course orthogonal to whether or not a venv is activated, but would have the desired effect when a venv is activated, without needing to tie the launcher to a virtualenv-specific environment value such as VIRTUAL_ENV.) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17010 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17039] socket.SocketIO hides socket timeouts as blocking errors
Ronny Pfannschmidt added the comment: noticed an error in my testing, sorry for the noise -- resolution: - invalid status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17039 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17040] Document context manager support for shelf objects
New submission from Berker Peksag: Context manager support for shelf objects was added in issue 13896, but not documented. -- assignee: docs@python components: Documentation files: shelve-context-manager-doc.diff keywords: patch messages: 180667 nosy: asvetlov, berker.peksag, docs@python priority: normal severity: normal status: open title: Document context manager support for shelf objects versions: Python 3.4 Added file: http://bugs.python.org/file28843/shelve-context-manager-doc.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17040 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17041] Fix tests for build --without-doc-strings
New submission from Serhiy Storchaka: Some tests failed when Python built without docstrings (--without-doc-strings options). Proposed patch fixes most of tests. Only doctests in test_generators and test_genexps don't fixed. I don't know how to make doctests conditional. [135/372] test_generators ** File /home/serhiy/py/cpython-without-doc-strings/Lib/test/test_generators.py, line ?, in test.test_generators.__test__.email Failed example: print(i.__next__.__doc__) Expected: x.__next__() == next(x) Got: BLANKLINE ** 1 items had failures: 1 of 31 in test.test_generators.__test__.email ***Test Failed*** 1 failures. test test_generators failed -- 1 of 287 doctests failed [137/372/1] test_genexps ** File /home/serhiy/py/cpython-without-doc-strings/Lib/test/test_genexps.py, line ?, in test.test_genexps.__test__.doctests Failed example: print(g.__next__.__doc__) Expected: x.__next__() == next(x) Got: BLANKLINE ** 1 items had failures: 1 of 75 in test.test_genexps.__test__.doctests ***Test Failed*** 1 failures. test test_genexps failed -- 1 of 75 doctests failed -- components: Tests files: tests_without_docstrings.patch keywords: patch messages: 180668 nosy: serhiy.storchaka, skrah priority: normal severity: normal stage: patch review status: open title: Fix tests for build --without-doc-strings type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file28844/tests_without_docstrings.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17041 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17041] Fix tests for build --without-doc-strings
Changes by Serhiy Storchaka storch...@gmail.com: -- nosy: +ezio.melotti, michael.foord, pitrou Added file: http://bugs.python.org/file28845/tests_without_docstrings-2.7.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17041 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16817] test___all__ affects other tests by doing too much importing
Eli Bendersky added the comment: Eric, yes the key code in test_xml_etree that handles this is: def pickleRoundTrip(self, obj, name, dumper, loader): save_m = sys.modules[name] try: sys.modules[name] = dumper temp = pickle.dumps(obj) sys.modules[name] = loader result = pickle.loads(temp) except pickle.PicklingError as pe: # pyET must be second, because pyET may be (equal to) ET. human = dict([(ET, cET), (pyET, pyET)]) raise support.TestFailed(Failed to round-trip %r from %r to %r % (obj, human.get(dumper, dumper), human.get(loader, loader))) from pe finally: sys.modules[name] = save_m return result Because pickle does its own import of ElementTree. The test___all__ problem should be solved by a patch to issue #1674555, but having a separate mechanism in test.support was discussed. I'll take a look at your decorator. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16817 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17041] Fix tests for build --without-doc-strings
Stefan Krah added the comment: I've already committed a decorator in 5c7f92bfe785, but it isn't quite robust. I think the one in issue17041-decorator.diff should do the trick. Also, we then can use support.HAVE_DOCSTRINGS for some doctests. -- Added file: http://bugs.python.org/file28846/issue17041-decorator.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17041 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15359] Sockets support for CAN_BCM
Charles-François Natali added the comment: I've added (some) docs and added checking of the BCM constants to the test_socket module. This version looks good to me. I'll commit it next week (I currently don't have access to my development machine). I would guess that checking each broadcast manager function provided by the kernel isn't required? No, the goal is not to test the kernel implementation. That should be enough for now. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15359 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17037] Add conforms_to_pep399() to test.support
Eli Bendersky added the comment: Nice work, although I worry this is starting to get into too much magic territory. Do you have a real use case for the 'names' argument? -- nosy: +eli.bendersky ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17037 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17037] Add conforms_to_pep399() to test.support
Antoine Pitrou added the comment: I'm not sure what the use case for this is. It looks more obfuscating than revealing to me. -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17037 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17041] Fix tests for build --without-doc-strings
Serhiy Storchaka added the comment:
Oh, I see Stefan already fixed some failures. Here are updated patches.
--
Added file:
http://bugs.python.org/file28847/tests_without_docstrings-2.7_2.patch
Added file:
http://bugs.python.org/file28848/tests_without_docstrings-3.2_2.patch
Added file:
http://bugs.python.org/file28849/tests_without_docstrings-3.3_2.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17041
___diff -r 523f309cf558 Lib/ctypes/test/test_win32.py
--- a/Lib/ctypes/test/test_win32.py Sat Jan 26 13:31:44 2013 +0100
+++ b/Lib/ctypes/test/test_win32.py Sat Jan 26 16:19:23 2013 +0200
@@ -3,6 +3,7 @@
from ctypes import *
from ctypes.test import is_resource_enabled
import unittest, sys
+import sysconfig
import _ctypes_test
@@ -60,7 +61,9 @@
def test_COMError(self):
from _ctypes import COMError
-self.assertEqual(COMError.__doc__, Raised when a COM method call
failed.)
+if sysconfig.get_config_var('WITH_DOC_STRINGS'):
+self.assertEqual(COMError.__doc__,
+ Raised when a COM method call failed.)
ex = COMError(-1, text, (details,))
self.assertEqual(ex.hresult, -1)
diff -r 523f309cf558 Lib/distutils/tests/test_build_ext.py
--- a/Lib/distutils/tests/test_build_ext.py Sat Jan 26 13:31:44 2013 +0100
+++ b/Lib/distutils/tests/test_build_ext.py Sat Jan 26 16:19:23 2013 +0200
@@ -2,6 +2,7 @@
import os
from StringIO import StringIO
import textwrap
+import sysconfig
from distutils.core import Extension, Distribution
from distutils.command.build_ext import build_ext
@@ -77,8 +78,9 @@
self.assertEqual(xx.foo(2, 5), 7)
self.assertEqual(xx.foo(13,15), 28)
self.assertEqual(xx.new().demo(), None)
-doc = 'This is a template module just for instruction.'
-self.assertEqual(xx.__doc__, doc)
+if sysconfig.get_config_var('WITH_DOC_STRINGS'):
+doc = 'This is a template module just for instruction.'
+self.assertEqual(xx.__doc__, doc)
self.assertTrue(isinstance(xx.Null(), xx.Null))
self.assertTrue(isinstance(xx.Str(), xx.Str))
diff -r 523f309cf558 Lib/test/test_functools.py
--- a/Lib/test/test_functools.pySat Jan 26 13:31:44 2013 +0100
+++ b/Lib/test/test_functools.pySat Jan 26 16:19:23 2013 +0200
@@ -196,6 +196,7 @@
self.assertEqual(wrapper.__name__, 'f')
self.assertEqual(wrapper.attr, 'This is also a test')
+@test_support.requires_docstrings
@unittest.skipIf(sys.flags.optimize = 2,
Docstrings are omitted with -O2 and above)
def test_default_update_doc(self):
diff -r 523f309cf558 Lib/test/test_pydoc.py
--- a/Lib/test/test_pydoc.pySat Jan 26 13:31:44 2013 +0100
+++ b/Lib/test/test_pydoc.pySat Jan 26 16:19:23 2013 +0200
@@ -10,12 +10,21 @@
import xml.etree
import test.test_support
from collections import namedtuple
+import sysconfig
from test.script_helper import assert_python_ok
from test.test_support import (
TESTFN, rmtree, reap_children, captured_stdout)
from test import pydoc_mod
+if sysconfig.get_config_var('WITH_DOC_STRINGS'):
+expected_data_docstrings = (
+'dictionary for instance variables (if defined)',
+'list of weak references to the object (if defined)',
+)
+else:
+expected_data_docstrings = ('', '', '', '')
+
expected_text_pattern = \
NAME
@@ -40,11 +49,9 @@
class B(__builtin__.object)
| Data descriptors defined here:
|\x20\x20
- | __dict__
- | dictionary for instance variables (if defined)
+ | __dict__%s
|\x20\x20
- | __weakref__
- | list of weak references to the object (if defined)
+ | __weakref__%s
|\x20\x20
| --
| Data and other attributes defined here:
@@ -75,6 +82,9 @@
Nobody
.strip()
+expected_text_data_docstrings = tuple('\n | ' + s if s else ''
+ for s in expected_data_docstrings)
+
expected_html_pattern = \
table width=100%% cellspacing=0 cellpadding=2 border=0 summary=heading
@@ -121,10 +131,10 @@
trtd bgcolor=#ffc8d8ttnbsp;nbsp;nbsp;/tt/tdtdnbsp;/td
td width=100%%Data descriptors defined here:br
dldtstrong__dict__/strong/dt
-ddttdictionarynbsp;fornbsp;instancenbsp;variablesnbsp;(ifnbsp;defined)/tt/dd
+ddtt%s/tt/dd
/dl
dldtstrong__weakref__/strong/dt
-ddttlistnbsp;ofnbsp;weaknbsp;referencesnbsp;tonbsp;thenbsp;objectnbsp;(ifnbsp;defined)/tt/dd
+ddtt%s/tt/dd
/dl
hr
Data and other attributes defined here:br
@@ -168,6 +178,8 @@
td width=100%%Nobody/td/tr/table
.strip()
+expected_html_data_docstrings = tuple(s.replace(' ', 'nbsp;')
+ for s in expected_data_docstrings)
#
[issue17037] Add conforms_to_pep399() to test.support
Eli Bendersky added the comment: Antoine - I think I can see the use case. ATM, to conform to PEP399, every test _class_ has to be subclassed twice with appropriate assignment to the relevant tested class. This leads to a lot of repetition. As an example, see test_decimal.py, which does this a lot. It would be nice to save programmers from this repetition; however, as I said before, this solution seems very complex. Maybe simpler solutions can be conceived? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17037 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17037] Add conforms_to_pep399() to test.support
Antoine Pitrou added the comment: I'm not sure how the lots of repetition is a problem. The following: class CCoverage(Coverage): decimal = C class PyCoverage(Coverage): decimal = P is quite trivial compared to the actual base test case (the Coverage class). Not only it is quite trivial to *write*, but it is also very easy to *read*, and quite explicit. Python is not Lisp, and we do not like meta-programming that much, when it tends to obscure the code in the name of not repeating yourself. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17037 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17041] Fix tests for build --without-doc-strings
R. David Murray added the comment: Once upon a time (two years ago?) we fixed the tests so that they ran successfully (skipped when appropriate) with -OO set, which omits docstrings. We were checking for the optimization level (sys.flags.optimize) then. It seems like it would make more sense to combine both checks into one decorator. -- nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17041 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17041] Fix tests for build --without-doc-strings
Serhiy Storchaka added the comment:
Patches updated incorporating Stefan's patch.
--
Added file:
http://bugs.python.org/file28850/tests_without_docstrings-2.7_3.patch
Added file:
http://bugs.python.org/file28851/tests_without_docstrings-3.2_3.patch
Added file:
http://bugs.python.org/file28852/tests_without_docstrings-3.3_3.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17041
___diff -r 523f309cf558 Lib/ctypes/test/test_win32.py
--- a/Lib/ctypes/test/test_win32.py Sat Jan 26 13:31:44 2013 +0100
+++ b/Lib/ctypes/test/test_win32.py Sat Jan 26 16:59:23 2013 +0200
@@ -3,6 +3,7 @@
from ctypes import *
from ctypes.test import is_resource_enabled
import unittest, sys
+from test import test_support as support
import _ctypes_test
@@ -60,7 +61,9 @@
def test_COMError(self):
from _ctypes import COMError
-self.assertEqual(COMError.__doc__, Raised when a COM method call
failed.)
+if support.HAVE_DOCSTRINGS:
+self.assertEqual(COMError.__doc__,
+Raised when a COM method call failed.)
ex = COMError(-1, text, (details,))
self.assertEqual(ex.hresult, -1)
diff -r 523f309cf558 Lib/distutils/tests/test_build_ext.py
--- a/Lib/distutils/tests/test_build_ext.py Sat Jan 26 13:31:44 2013 +0100
+++ b/Lib/distutils/tests/test_build_ext.py Sat Jan 26 16:59:23 2013 +0200
@@ -77,8 +77,9 @@
self.assertEqual(xx.foo(2, 5), 7)
self.assertEqual(xx.foo(13,15), 28)
self.assertEqual(xx.new().demo(), None)
-doc = 'This is a template module just for instruction.'
-self.assertEqual(xx.__doc__, doc)
+if test_support.HAVE_DOCSTRINGS:
+doc = 'This is a template module just for instruction.'
+self.assertEqual(xx.__doc__, doc)
self.assertTrue(isinstance(xx.Null(), xx.Null))
self.assertTrue(isinstance(xx.Str(), xx.Str))
diff -r 523f309cf558 Lib/test/test_functools.py
--- a/Lib/test/test_functools.pySat Jan 26 13:31:44 2013 +0100
+++ b/Lib/test/test_functools.pySat Jan 26 16:59:23 2013 +0200
@@ -196,6 +196,7 @@
self.assertEqual(wrapper.__name__, 'f')
self.assertEqual(wrapper.attr, 'This is also a test')
+@test_support.requires_docstrings
@unittest.skipIf(sys.flags.optimize = 2,
Docstrings are omitted with -O2 and above)
def test_default_update_doc(self):
diff -r 523f309cf558 Lib/test/test_pydoc.py
--- a/Lib/test/test_pydoc.pySat Jan 26 13:31:44 2013 +0100
+++ b/Lib/test/test_pydoc.pySat Jan 26 16:59:23 2013 +0200
@@ -10,12 +10,21 @@
import xml.etree
import test.test_support
from collections import namedtuple
+import sysconfig
from test.script_helper import assert_python_ok
from test.test_support import (
TESTFN, rmtree, reap_children, captured_stdout)
from test import pydoc_mod
+if test.test_support.HAVE_DOCSTRINGS:
+expected_data_docstrings = (
+'dictionary for instance variables (if defined)',
+'list of weak references to the object (if defined)',
+)
+else:
+expected_data_docstrings = ('', '', '', '')
+
expected_text_pattern = \
NAME
@@ -40,11 +49,9 @@
class B(__builtin__.object)
| Data descriptors defined here:
|\x20\x20
- | __dict__
- | dictionary for instance variables (if defined)
+ | __dict__%s
|\x20\x20
- | __weakref__
- | list of weak references to the object (if defined)
+ | __weakref__%s
|\x20\x20
| --
| Data and other attributes defined here:
@@ -75,6 +82,9 @@
Nobody
.strip()
+expected_text_data_docstrings = tuple('\n | ' + s if s else ''
+ for s in expected_data_docstrings)
+
expected_html_pattern = \
table width=100%% cellspacing=0 cellpadding=2 border=0 summary=heading
@@ -121,10 +131,10 @@
trtd bgcolor=#ffc8d8ttnbsp;nbsp;nbsp;/tt/tdtdnbsp;/td
td width=100%%Data descriptors defined here:br
dldtstrong__dict__/strong/dt
-ddttdictionarynbsp;fornbsp;instancenbsp;variablesnbsp;(ifnbsp;defined)/tt/dd
+ddtt%s/tt/dd
/dl
dldtstrong__weakref__/strong/dt
-ddttlistnbsp;ofnbsp;weaknbsp;referencesnbsp;tonbsp;thenbsp;objectnbsp;(ifnbsp;defined)/tt/dd
+ddtt%s/tt/dd
/dl
hr
Data and other attributes defined here:br
@@ -168,6 +178,8 @@
td width=100%%Nobody/td/tr/table
.strip()
+expected_html_data_docstrings = tuple(s.replace(' ', 'nbsp;')
+ for s in expected_data_docstrings)
# output pattern for missing module
missing_pattern = no Python documentation found for '%s'
@@ -229,7 +241,9 @@
mod_url = nturl2path.pathname2url(mod_file)
else:
mod_url = mod_file
-expected_html =
[issue17041] Fix tests for build --without-doc-strings
Serhiy Storchaka added the comment: It seems like it would make more sense to combine both checks into one decorator. These are different cases. @unittest.skipIf(sys.flags.optimize = 2) is about docstrings in Python implemented modules, and @support.requires_docstrings is about docstrings in C implemented modules. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17041 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12397] re match object methods have no docstrings
Serhiy Storchaka added the comment: Fixed in issue16443. -- nosy: +serhiy.storchaka resolution: - duplicate stage: - committed/rejected status: open - closed superseder: - Add docstrings to regular expression match objects ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12397 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15731] Mechanism for inheriting docstrings and signatures
Changes by Serhiy Storchaka storch...@gmail.com: -- nosy: +serhiy.storchaka ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15731 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17009] Thread Programming With Python should be removed
Changes by Tshepang Lekhonkhobe tshep...@gmail.com: -- nosy: +tshepang ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17009 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6972] zipfile.ZipFile overwrites files outside destination path
Serhiy Storchaka added the comment: Can anyone review the patch? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6972 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16991] Add OrderedDict written in C
Ezio Melotti added the comment: What's the reason for moving the OrderedDict tests in a separate file? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16991 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4844] ZipFile doesn't range check in _EndRecData()
Changes by Serhiy Storchaka storch...@gmail.com: Removed file: http://bugs.python.org/file28178/zipfile_unpack_check.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4844 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16996] Reuse shutil.which() in webbrowser module
Changes by Tshepang Lekhonkhobe tshep...@gmail.com: -- nosy: +tshepang ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16996 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4844] ZipFile doesn't range check in _EndRecData()
Serhiy Storchaka added the comment: Patch updated. Now the test use io.BytesIO() for input too. A loop limit changed from len() -2 to len(). If there are no objections I'll commit this patch next week. -- assignee: mcherm - serhiy.storchaka Added file: http://bugs.python.org/file28853/zipfile_unpack_check.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4844 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3718] environment variable MACHDEP and python build system
Roumen Petrov added the comment: Matthias Klose wrote: Matthias Klose added the comment: the change to the configure script looks ok. however you could change the README too. This is 5 years old issue. README is not more in repository. As result python lack documentation related to build process. It looks like the changes to the Makefile.pre.in are already applied. No . But you could ignore this part of issue. Roumen -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3718 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17037] Add conforms_to_pep399() to test.support
Eric Snow added the comment: In my case I've been doing PEP 399 for collections.OrderedDict. It struck me that the boilerplate could be stowed away in a decorator. It's more than just adding a couple subclasses. Here's what it covers: * add the test case subclasses, * make sure the original test case does not get used (#16835), * use the relevant names as class attributes rather than globals (e.g. self.OrderedDict vs. OrderedDict), * hack around modules that do their own imports (#16817), * others(?). When adapting existing test cases having a decorator to do this makes the job a snap without having to worry about corner cases. You have to add the decorator and then add the new test names to the test discovery code (at least until we use unittest's test discovery). For new test cases and splitting out test cases it likewise simplifies things. On top of that, if you drop the decorator the test case would still run as-is. Other benefits for both new and existing test cases: * the decorator makes it clear what is going on (or will be made to) via the decorator name, * the requisite boilerplate doesn't have to clutter up the code, * when something like #16817 or #16835 comes up, it's much easier to update the decorator in test.support instead of finding each of the PEP-399-ized tests that is affected and updating them individually. Downsides: * explicit is better than implicit, * relatedly, the solution is more magic/obfuscated that the current boilerplate. You could argue that the magnitude of the problem doesn't warrant a complex decorator, but it doesn't have to be hard to understand. My patch is something I threw together late last night that could certainly be made more clear. More importantly, as more modules get a dual implementation, the above benefits of the decorator become more pronounced. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17037 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17037] Add conforms_to_pep399() to test.support
Eric Snow added the comment: Do you have a real use case for the 'names' argument? My use case was with the tests for OrderedDict. The existing tests don't refer to collections.OrderedDict, but rather to OrderedDict (looked up from the globals). The names argument facilitates the replacement of OrderedDict. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17037 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17041] Fix tests for build --without-doc-strings
Stefan Krah added the comment: Serhiy Storchaka rep...@bugs.python.org wrote: It seems like it would make more sense to combine both checks into one decorator. These are different cases. @unittest.skipIf(sys.flags.optimize = 2) is about docstrings in Python implemented modules, and @support.requires_docstrings is about docstrings in C implemented modules. But they're always used together, aren't they? I kind of like the idea of a single decorator. We could have two different messages compiled without docstrings and docstrings are omitted with -O2 and above, where the first message should get priority if both conditions are true. Given the mood on python-dev concerning --without-doc-strings, I wonder if we should stick to minimal changes and just skip the tests in test_pydoc.py instead of fixing them. Personally I'm happy either way. David, what do you think? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17041 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17003] Unification of read() and readline() argument names
Changes by Tshepang Lekhonkhobe tshep...@gmail.com: -- nosy: +tshepang ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17003 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16991] Add OrderedDict written in C
Eric Snow added the comment: What's the reason for moving the OrderedDict tests in a separate file? Following the precedent of collections.deque and collections.defaultdict: * a big chunk of code * the default implementation will be coming via _collections. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16991 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17005] Add a topological sort algorithm
Changes by Tshepang Lekhonkhobe tshep...@gmail.com: -- nosy: +tshepang ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17005 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16968] Fix test discovery for test_concurrent_futures.py
Chris Jerdonek added the comment: Okay, I think I understand the issue better now. The threading._dangling warning happens because when leaving the saved_test_environment context manager in regrtest: http://hg.python.org/cpython/file/fcdb35b114ab/Lib/test/regrtest.py#l1271 the context manager finds threads still in threading._dangling that weren't there at the beginning. I think the threads are still in there because the tests variable in the code linked to above is holding references to those threads (which isn't surprising given what test_concurrent_futures.py tests). So this is preventing the threads (which are in a WeakSet) from being garbage collected. On my machine, severing those references before leaving the context manager solves the problem. You can do this by adding test = 0 after the test_runner() line, or defining tests inside an inner function as follows: if test_runner is None: def test_runner(): tests = unittest.TestLoader().loadTestsFromModule(the_module) support.run_unittest(tests) test_runner() To be completely sure, we may also need to do something to ensure that the threads are garbage collected before leaving the context manager. Currently, an explicit call to support.gc_collect() happens in threading_cleanup() (which is in turn called by reap_threads(), etc): http://hg.python.org/cpython/file/fcdb35b114ab/Lib/test/support.py#l1665 But I'm not sure if that's late enough in the process to guarantee garbage collection of those threads with the test_runner() change above (since the tests list might still be defined). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16968 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3718] environment variable MACHDEP and python build system
Changes by Gregory P. Smith g...@krypto.org: -- nosy: -gregory.p.smith ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3718 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16991] Add OrderedDict written in C
Ezio Melotti added the comment: These are indeed good reasons. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16991 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10740] sqlite3 module should allow DDL statements in transactions
Changes by Tshepang Lekhonkhobe tshep...@gmail.com: -- nosy: +tshepang ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10740 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15483] CROSS: initialise include and library paths in setup.py
Roumen Petrov added the comment: Matthias Klose added the comment: I don't think this one is still necessary. can it be closed? If is difficult to confirm. In scope of issue title initialization is fixed. Another part of proposed path is to insert at first position current directory if cross build. If this is not acceptable in scope of this then someone could open a new issue to set unconditionally in BLDLIBRARY current directory, i.e. to change configure script. I don't like to touch existing native build so in scope of cross build this patch propose libdir to start with current. Roumen -- Added file: http://bugs.python.org/file28854/0004-CROSS-initialise-include-and-library-paths.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15483 ___From 9fe8bd2e63ad383c795962cea3aa1ff11b493988 Mon Sep 17 00:00:00 2001 From: Roumen Petrov lo...@example.net Date: Mon, 23 Jul 2012 23:31:20 +0300 Subject: [PATCH 04/13] CROSS-initialise include and library paths --- setup.py | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/setup.py b/setup.py index 5d38d29..4a27ba7 100644 --- a/setup.py +++ b/setup.py @@ -500,15 +500,16 @@ class PyBuildExt(build_ext): # lib_dirs and inc_dirs are used to search for files; # if a file is found in one of those directories, it can # be assumed that no additional -I,-L directives are needed. +lib_dirs = self.compiler.library_dirs +inc_dirs = self.compiler.include_dirs if not cross_compiling: -lib_dirs = self.compiler.library_dirs + [ +lib_dirs += [ '/lib64', '/usr/lib64', '/lib', '/usr/lib', ] -inc_dirs = self.compiler.include_dirs + ['/usr/include'] +inc_dirs += ['/usr/include'] else: -lib_dirs = self.compiler.library_dirs[:] -inc_dirs = self.compiler.include_dirs[:] +self.compiler.library_dirs.insert(0, '.') exts = [] missing = [] -- 1.7.12.1 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3718] environment variable MACHDEP and python build system
Roundup Robot added the comment: New changeset 8c49dd8e4d22 by doko in branch '3.3': - Issue #3718: Use AC_ARG_VAR to set MACHDEP in configure.ac. http://hg.python.org/cpython/rev/8c49dd8e4d22 New changeset 6866384d9ccb by doko in branch 'default': - Issue #3718: Use AC_ARG_VAR to set MACHDEP in configure.ac. http://hg.python.org/cpython/rev/6866384d9ccb -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3718 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3718] environment variable MACHDEP and python build system
Matthias Klose added the comment: now checked in the configure change. I think that the cross-build documentation deserves an extra issue. Therefore now closing this issue. -- resolution: - fixed stage: patch review - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3718 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3871] cross and native build of python for mingw* hosts
Matthias Klose added the comment: IMHO, updating these patches to track the latest Python is a pointless goal. sorry, no. it's the *only* way to get these patches upstream. The mingw patches will never see the light of the 3.3 branch. So the best thing to do is to actively submit the patches for trunk. If you do want to maintain your patches, then split your set of patches into those which are upstream (and then pack-ported), and which are not yet upstream. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3871 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3871] cross and native build of python for mingw* hosts
Matthias Klose added the comment: However, we must go further and add that the patches *cannot* break any other native or cross-compilation, which - as I think Matthias is alluding to - is probably not the case with your patch. This issue is called cross and native build of python for mingw* hosts, no, I just didn't check. And I probably won't check. However it's more likely that your patches are accepted if e.g. it doesn't break the normal Windows build and an unrelated build, e.g. for a Linux target. Maybe you could even separate the patches into a patch supporting a native mingw build and a cmingw ross build? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3871 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8865] select.poll is not thread safe
Serhiy Storchaka added the comment: Here is a test made from Charles-François's crasher. Let's go. -- Added file: http://bugs.python.org/file28855/issue8865_test.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8865 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10905] zipfile: fix arcname with leading '///' or '..'
Changes by Serhiy Storchaka storch...@gmail.com: -- stage: - committed/rejected status: pending - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10905 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8865] select.poll is not thread safe
Changes by Serhiy Storchaka storch...@gmail.com: -- stage: test needed - commit review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8865 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17042] Example in C-API memory management doc has confusing order
New submission from Eric Snow: In http://docs.python.org/dev/c-api/memory.html#examples: char *buf1 = PyMem_New(char, BUFSIZ); char *buf2 = (char *) malloc(BUFSIZ); char *buf3 = (char *) PyMem_Malloc(BUFSIZ); ... PyMem_Del(buf3); /* Wrong -- should be PyMem_Free() */ free(buf2); /* Right -- allocated via malloc() */ free(buf1); /* Fatal -- should be PyMem_Del() */ Is there a good reason to have the second set of 3 lines in the opposite order as the first three? At first I missed that they were in a different order and thought there was an error in the example. If there's no good reason for the order, it would be worth fixing. If there is a good reason, a comment in the example would help. Either way I'd be glad to patch it (will go ahead with fixing the ordering later today if no one does it first). -- assignee: docs@python components: Documentation messages: 180697 nosy: docs@python, eric.snow priority: low severity: normal stage: needs patch status: open title: Example in C-API memory management doc has confusing order versions: Python 2.7, Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17042 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17042] Example in C-API memory management doc has confusing order
Stefan Krah added the comment: Please don't change this: It's a common pattern in C to undo memory allocations in the opposite order. -- nosy: +skrah ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17042 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17042] Example in C-API memory management doc has confusing order
Changes by Ezio Melotti ezio.melo...@gmail.com: -- resolution: - rejected stage: needs patch - committed/rejected status: open - closed type: - enhancement ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17042 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16802] fileno argument to socket.socket() undocumented
Changes by Serhiy Storchaka storch...@gmail.com: -- keywords: +easy stage: - needs patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16802 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8821] Range check on unicode repr
Changes by Serhiy Storchaka storch...@gmail.com: -- status: open - pending ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8821 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16096] Get rid of dangerous integer overflow tricks
Serhiy Storchaka added the comment: I withdraw my patches for 2.7 and 3.2 due to the fact that they have no visible effect on supported platforms. Patches for 3.3+ already committed, therefore I close this issue. -- resolution: - fixed stage: - committed/rejected status: open - closed versions: +Python 3.3, Python 3.4 -Python 2.7, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16096 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11204] re module: strange behaviour of space inside {m, n}
Serhiy Storchaka added the comment: Then let's leave all as is. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11204 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3754] cross-compilation support for python build
Roumen Petrov added the comment: Matthias Klose wrote: Matthias Klose added the comment: about py3k-20121004-CROSS.tgz: [SNIP] - 0002-CROSS-restore-graminit.-to-source-directory.patch [SNIP] - 0003-CROSS-restore-importlib-header-to-source-directory-a.patch [SNIP] - 0004-CROSS-restore-AST-to-source-directory.patch [SNIP] All above is related to build out of source tree. Try to keep a build tree for long time. Synchronize source, for instance once in week, and try to rebuild. After updates in those files python (native build) crash. Solutions: a) restore to source tree as before and only for cross build touch files to avoid regeneration. b) after synchronization copy to build tree but now in all cases. Note that a) will allow you to build from readonly source tree . - 0005-CROSS-revert-issue13150-i.e.-python-solution-with-_s.patch A comment like The fix for issue #13150 is bogus and break everything might not the best way to convince maintainers ... This works for me, and IMO should be dropped, or please explain why this doesn't work for you. How old is patch ? Before generated python solution to be moved from source tree to `cat pybuilddir.txt`. So thanks to all that resolve design failure with commit for issue 13150. It seems to me author is not able to rewrite = issue 13547, issue14774, issue16342(?) . Now obsolete by issue15298 (10x Trent). - 0006-CROSS-initialise-include-and-library-paths.patch Afaics, a similar patch is now applied. Can be dropped. [SNIP] - 0009-CROSS-pass-all-top-configure-arguments-to-libffi-con.patch Why is it needed to pass all configure args? - 0010-CROSS-warn-only-if-readelf-is-not-in-host-triplet-fo.patch Why is this needed just for readelf? If you do have a cross toolchain installed, then this should be available with the triplet name, same as for gcc, as, ... May be I'm wrong to use cross build for multilib , i.e. with gcc -m32. In this case does not exist prefixed readelf. - 0011-CROSS-append-gcc-library-search-paths-instead-to-pre.patch Looks ok. Could you mention where this does make a difference, or do you just want to keep the search order as defined by the compiler? issue15485 My multilib compiler list fist paths to 64 libraries the to 32. 64 bit is with all dependent libraries and headers but 32-compatible lack some (tk/tcl for instance). As result 32 bit build find all required dependency, try to link all modules and fail on missing. Distutil library search is limited - just search for library name. - 0012-CROSS-avoid-ncursesw-include-path-hack.patch This would break cross-building in a multiarch environment. Maybe we need a --with-curses-incdir= option. May be (issue15268). - 0013-CROSS-properly-detect-WINDOW-_flags-for-different-nc.patch This should be a separate issue. Not cross specific. issue14598 and issue15484. - 0014-CROSS-use-build-directory-as-root-for-regression-tes.patch why is this necessary? For instance is source tree is readonly . It is important in cross to avoid build defects to update source files. Result is parallel build and test for multiple host. - 0015-CROSS-test-tools-has-to-depend-only-from-location-of.patch Looks ok, but not cross specific. Could you file a separate issue? Unfortunately issue is closed. It was fixed perfectly for about 2 hours. I just revert commit. Same as 14 rule apply. - 0016-CROSS-reload-may-fail-with-operation-on-closed-file-.patch Looks like a separate issue. May be is not same as issue15833 (fixed+closed). May be case is only for regression test if source tree is readonly. Roumen -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3754 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13896] Make shelf instances work with 'with' as context managers
Terry J. Reedy added the comment: The patch did not update the doc. See #17040, with proposed patch. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13896 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3871] cross and native build of python for mingw* hosts
Ray Donnelly added the comment: Re: basing the patches against the latest master branch or targeting released versions, I wasn't clear enough about my thinking. For sure, when trying to get any patches merged, the submitted patch must be re-based (forward ported) and tested against the master branch. But from the perspective of having a project that people can reliably expect to build a working MinGW-w64 Python from (until that elusive fully-merged-day comes), having patches based on the latest released versions seems to me to be the best thing to do (for that goal of course) I'll keep forward porting these patches to each new release, and at those times I'll also submit some of them as issues to bugs.python.org as that's the best way for me to manage my limited spare time. Do you know what the situation is with packaging/distutils2? I think our next good merge opportunity for the bulk of these patches will be when we can target that instead of distutils. Maybe you could even separate the patches into a patch supporting a native mingw build and a cmingw ross build? I'm already doing that: https://github.com/mingwandroid/crucifixion-freedom/tree/master/patches/python/3.3.0 and 0005 are now merged with upstream. you merged today, 0005 was merged also (mostly via Roumen's patches which 2/3 of my patch duplicated). At this stage, the framework for cross compiling Python is mostly merged; other than 0065-cross-dont-add-multiarch-paths-if-cross-compiling.patch The stumbling block for me is that there's no working example of cross-compilation in CPython so it will surely rot. This was what I tried to fix with my next patch, 0010-cross-darwin-feature.patch. I went for darwin instead of MinGW as the amount of changes needed is tiny but it was met with some resistance and hasn't seen any activity for 3 months: http://bugs.python.org/issue16291 I should also clarify, by cross compilation I'm specifically excluding GNU-Linux/GNU-Linux combinations such as x86-GNU-Linux/arm-GNU-Linux as they're not as exhaustive a test-case as cross-compiling between different OSes. Maybe you could even separate the patches into a patch supporting a native mingw build and a cmingw ross build? Not sure if that was directed at me as my set of patches are logically split up I think. Ones with 'mingw' in the name relate to mingw (either cross or native), ones with 'msys' in the name relate to building mingw natively and ones with 'cross' in the name relate to general cross compilation matters; ones with 'hack' in the name generally need improving, rewriting or removing. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3871 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3871] cross and native build of python for mingw* hosts
Roumen Petrov added the comment:
Matthias Klose wrote:
Matthias Klose added the comment:
some random comments about py3k-20121004-MINGW.patch:
- Modules/_ctypes/libffi_msvc/win32.S
Please can you get rid of libffi_msvc and use libffi?
afaics, libffi has support for mingw32.
No python still use custom hack for MSVC. win32.S include this hack and
could be compiled with gcc.
- there seem to be chunks which are unrelated to mingw, like:
@@ -830,15 +926,18 @@ class PyBuildExt(build_ext):
if have_usable_openssl:
# The _hashlib module wraps optimized implementations
# of hash functions from the OpenSSL library.
+# NOTE: _hashlib require only OpenSSL crypto library !
exts.append( Extension('_hashlib', ['_hashopenssl.c'],
depends = ['hashlib.h'],
include_dirs = ssl_incs,
library_dirs = ssl_libs,
- libraries = ['ssl', 'crypto']) )
+ libraries = ['crypto']) )
please file separate issues.
- why setup_info.in. looks like something which could be done with
get_config_var.
Yes and no. get_config_var will use makefile variables (indirectly from
sysconfigdata).
If you add a make macro(variable) then it will be installed.
Setup info is designed to communicate from configure to setup.py without
to expose data to installation.
- why re-reading files in setup.py, and grepping these for config options?
For historical reasons. Before other commits to start to look info some
generated by autotool files.
I think the patch would benefit from splitting it up into several
self-contained chunks.
May be.
I don't know how to group split. If is based on functionality patch
order will be important as more then one patch will update near lines -
for instance pyport.h is difficult to split :(.
cygwinccompiler.py could be rewritten as separate issue, already opened.
did you try to do builds for windows and linux after this patch was applied?
Title is correct. Hosts include native linux, cygwin, mingw and cross
linux-mingw, linux-android ( not published ). All from one and the
same source tree.
Roumen
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3871
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3871] cross and native build of python for mingw* hosts
Giampaolo Rodola' added the comment: This discussion got very long and it's not clear (to me at least) what the status of the patch is and whether it has been accepted for inclusion. Maybe it makes sense to bring this up to python-dev mailing list instead of keep stressing this thread? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3871 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16723] io.TextIOWrapper on urllib.request.urlopen terminates prematurely
Serhiy Storchaka added the comment: Here is a patch which fixes HTTPResponse's end. closed property no longer settled automatically, but only after explicit close(). -- components: +IO, Library (Lib) keywords: +patch nosy: +orsenthil stage: - patch review versions: +Python 3.2, Python 3.4 Added file: http://bugs.python.org/file28856/httpresponse_noclosed.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16723 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3871] cross and native build of python for mingw* hosts
Ray Donnelly added the comment: Roumen, I think it would be really great if you could split py3k-20121004-MINGW.patch up into separate bits. The pthread stuff and libffi stuff being two obvious candidates for atomic parts. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3871 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3871] cross and native build of python for mingw* hosts
Roumen Petrov added the comment: As patch 0005-CROSS-revert-issue13150-i.e.-python-solution-with-_s.patch (CROSS-revert issue13150, i.e. python solution with _sysconfigdata.py instead Makefile) from issue3754 is now obsolete by issue 13547, 14774, 16342, 15298 it is save to switch sysconfigdata with proposed changes in PC/getpathp.c . -- Added file: http://bugs.python.org/file28857/0003-MINGW-implement-exec-prefix-i.e.-use-content-of-pybu.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3871 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17043] Invalid read in test_codecs
New submission from Stefan Krah: Found this in test_codecs running under Valgrind (Python 3.3): test_bug1251300 (test.test_codecs.UnicodeInternalTest) ... ==11511== Invalid read of size 1 ==11511==at 0x44AF37: _PyUnicode_DecodeUnicodeInternal (unicodeobject.c:6133) ==11511==by 0x4DEB5C: unicode_internal_decode (_codecsmodule.c:251) ==11511==by 0x5093F6: PyObject_Call (abstract.c:2082) ==11511==by 0x47D7F2: PyEval_CallObjectWithKeywords (ceval.c:3942) ==11511==by 0x491C38: PyCodec_Decode (codecs.c:403) ==11511==by 0x459D7D: PyUnicode_Decode (unicodeobject.c:3129) ==11511==by 0x45A287: PyUnicode_FromEncodedObject (unicodeobject.c:3023) ==11511==by 0x519A45: bytes_decode (bytesobject.c:2320) ==11511==by 0x484AB8: PyEval_EvalFrameEx (ceval.c:4374) ==11511==by 0x485ACB: PyEval_EvalFrameEx (ceval.c:4150) ==11511==by 0x486779: PyEval_EvalCodeEx (ceval.c:3433) ==11511==by 0x4859CA: PyEval_EvalFrameEx (ceval.c:4160) ==11511== Address 0x984a7e2 is 0 bytes after a block of size 34 alloc'd ==11511==at 0x4C27972: realloc (vg_replace_malloc.c:525) ==11511==by 0x51AC34: _PyBytes_Resize (bytesobject.c:2881) ==11511==by 0x51B1FA: PyBytes_FromObject (bytesobject.c:2732) ==11511==by 0x51C134: bytes_new (bytesobject.c:2594) ==11511==by 0x42A4E4: type_call (typeobject.c:723) ==11511==by 0x5093F6: PyObject_Call (abstract.c:2082) ==11511==by 0x4843D5: PyEval_EvalFrameEx (ceval.c:4282) ==11511==by 0x485ACB: PyEval_EvalFrameEx (ceval.c:4150) ==11511==by 0x486779: PyEval_EvalCodeEx (ceval.c:3433) ==11511==by 0x4859CA: PyEval_EvalFrameEx (ceval.c:4160) ==11511==by 0x486779: PyEval_EvalCodeEx (ceval.c:3433) ==11511==by 0x538EF8: function_call (funcobject.c:633) ==11511== _PyUnicode_DecodeUnicodeInternal (s=0x984a7e0 , size=value optimized out, errors=0x0) at Objects/unicodeobject.c:6133 6133((char *) uch)[2] = s[2]; == ==11511== ==11511== Debugger has detached. Valgrind regains control. We continue. ==11511== Invalid read of size 1 ==11511==at 0x44AF3E: _PyUnicode_DecodeUnicodeInternal (unicodeobject.c:6134) ==11511==by 0x4DEB5C: unicode_internal_decode (_codecsmodule.c:251) ==11511==by 0x5093F6: PyObject_Call (abstract.c:2082) ==11511==by 0x47D7F2: PyEval_CallObjectWithKeywords (ceval.c:3942) ==11511==by 0x491C38: PyCodec_Decode (codecs.c:403) ==11511==by 0x459D7D: PyUnicode_Decode (unicodeobject.c:3129) ==11511==by 0x45A287: PyUnicode_FromEncodedObject (unicodeobject.c:3023) ==11511==by 0x519A45: bytes_decode (bytesobject.c:2320) ==11511==by 0x484AB8: PyEval_EvalFrameEx (ceval.c:4374) ==11511==by 0x485ACB: PyEval_EvalFrameEx (ceval.c:4150) ==11511==by 0x486779: PyEval_EvalCodeEx (ceval.c:3433) ==11511==by 0x4859CA: PyEval_EvalFrameEx (ceval.c:4160) ==11511== Address 0x984a7e3 is 1 bytes after a block of size 34 alloc'd ==11511==at 0x4C27972: realloc (vg_replace_malloc.c:525) ==11511==by 0x51AC34: _PyBytes_Resize (bytesobject.c:2881) ==11511==by 0x51B1FA: PyBytes_FromObject (bytesobject.c:2732) ==11511==by 0x51C134: bytes_new (bytesobject.c:2594) ==11511==by 0x42A4E4: type_call (typeobject.c:723) ==11511==by 0x5093F6: PyObject_Call (abstract.c:2082) ==11511==by 0x4843D5: PyEval_EvalFrameEx (ceval.c:4282) ==11511==by 0x485ACB: PyEval_EvalFrameEx (ceval.c:4150) ==11511==by 0x486779: PyEval_EvalCodeEx (ceval.c:3433) ==11511==by 0x4859CA: PyEval_EvalFrameEx (ceval.c:4160) ==11511==by 0x486779: PyEval_EvalCodeEx (ceval.c:3433) ==11511==by 0x538EF8: function_call (funcobject.c:633) ==11511== Loaded symbols for /usr/lib/gconv/ISO8859-9.so _PyUnicode_DecodeUnicodeInternal (s=0x8295790 , size=value optimized out, errors=0x0) at Objects/unicodeobject.c:6134 6134((char *) uch)[3] = s[3]; -- messages: 180709 nosy: serhiy.storchaka, skrah priority: normal severity: normal status: open title: Invalid read in test_codecs versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17043 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16468] argparse only supports iterable choices
Terry J. Reedy added the comment: I think we have converged on the right solution. The patch looks good as far as it goes, assuming that it passes the current + unwritten new tests. It will also be a good basis for reconsidering what to do with long/infinite iterables in #16418. I think the doc patch should recommend passing a metavar arg with non-iterable choices. With that, using default metavars, whatever they end up being, is fine as long as no exception is raised. So I would make the tests of non-iterable with no metavar passed as general as possible. App writers who do not like the defaults should override them ;-). If I understand correctly, if choices is not iterable and the user enters an invalid choice, the choice part of the error message (passed to ArgumentError) will just be 'invalid choice: value'. Minor nit: .join does not need a temporary list as arg and works fine with genexp: choices_str = sep.join(to_str(choice) for choice in choices) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16468 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17043] Invalid read in test_codecs
Stefan Krah added the comment: Same in test_codeccallbacks: test_badhandlerresults (test.test_codeccallbacks.CodecCallbackTest) ... ==11604== Invalid read of size 1 ==11604==at 0x44AF37: _PyUnicode_DecodeUnicodeInternal (unicodeobject.c:6133) ==11604==by 0x4DEB5C: unicode_internal_decode (_codecsmodule.c:251) ==11604==by 0x5093F6: PyObject_Call (abstract.c:2082) ==11604==by 0x47D7F2: PyEval_CallObjectWithKeywords (ceval.c:3942) ==11604==by 0x491C38: PyCodec_Decode (codecs.c:403) ==11604==by 0x459D7D: PyUnicode_Decode (unicodeobject.c:3129) ==11604==by 0x45A287: PyUnicode_FromEncodedObject (unicodeobject.c:3023) ==11604==by 0x519A45: bytes_decode (bytesobject.c:2320) ==11604==by 0x484AB8: PyEval_EvalFrameEx (ceval.c:4374) ==11604==by 0x485ACB: PyEval_EvalFrameEx (ceval.c:4150) ==11604==by 0x486779: PyEval_EvalCodeEx (ceval.c:3433) ==11604==by 0x4859CA: PyEval_EvalFrameEx (ceval.c:4160) ==11604== Address 0xfa1f8a2 is 0 bytes after a block of size 34 alloc'd ==11604==at 0x4C27972: realloc (vg_replace_malloc.c:525) ==11604==by 0x51AC34: _PyBytes_Resize (bytesobject.c:2881) ==11604==by 0x51C338: PyBytes_DecodeEscape (bytesobject.c:495) ==11604==by 0x56E871: ast_for_expr (ast.c:3837) ==11604==by 0x570562: ast_for_testlist (ast.c:1106) ==11604==by 0x56E859: ast_for_expr (ast.c:1881) ==11604==by 0x570562: ast_for_testlist (ast.c:1106) ==11604==by 0x56E859: ast_for_expr (ast.c:1881) ==11604==by 0x5715C4: ast_for_stmt (ast.c:3302) ==11604==by 0x5724F8: ast_for_suite (ast.c:3086) ==11604==by 0x5715E3: ast_for_stmt (ast.c:3305) ==11604==by 0x5724F8: ast_for_suite (ast.c:3086) _PyUnicode_DecodeUnicodeInternal (s=0xfa1f8a0 , size=value optimized out, errors= 0xf652fa0 test.badhandler) at Objects/unicodeobject.c:6133 6133((char *) uch)[2] = s[2]; [...] _PyUnicode_DecodeUnicodeInternal (s=0xfa1f8a0 , size=value optimized out, errors= 0xf652fa0 test.badhandler) at Objects/unicodeobject.c:6134 6134((char *) uch)[3] = s[3]; -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17043 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16903] subprocess.Popen.communicate with universal_newlines=True doesn't accept strings on 3.2
Serhiy Storchaka added the comment: Here is a patch which adds support of strings in communicate(). It also contains a backported test from changeset 4af2c0687970 which tests this behavior. -- assignee: - serhiy.storchaka keywords: +patch nosy: +asvetlov stage: needs patch - patch review Added file: http://bugs.python.org/file28858/subprocess_communicate_string-3.2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16903 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16770] Selection in IDLE often skips first character
Ned Deily added the comment:
OK, I *did* spend a little more time on this and am now able to reproduce the
behavior solely running the following Tcl code with tclsh:
package require Tk
set w .text
catch {destroy $w}
toplevel $w
text $w.text -setgrid 1 -height 30 -font Courier 20
pack $w.text -expand yes -fill both
$w.text tag configure color1 -foreground red
$w.text insert 0.0
$w.text insert end from color1
$w.text mark set insert 0.0
Using Cocoa Tk 8.5.13, clicking on the r causes the insertion point to move
to after the r and a second click moves the insertion point to before the
r. Using the Apple-supplied Carbon Tk 8.4, the insertion point stays after
the r on the second click. I suspect the color tag has something to do with
it. I suggest if you want to pursue the issue, you should ask on one of the
Tcl mailing lists, like the Mac-specific one (archived here
http://dir.gmane.org/gmane.comp.lang.tcl.mac) or open an issue on the Tk
tracker:
http://sourceforge.net/tracker/?group_id=12997atid=112997
--
resolution: - invalid
stage: - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16770
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17044] Implement PEP 422: Simple class initialisation hook
New submission from Daniel Urban: The attached patch implements PEP 422 -- Simple class initialisation hook (__init_class__). It includes tests, but it doesn't include documentation yet. -- components: Interpreter Core, Library (Lib) files: pep422_1.patch keywords: needs review, patch messages: 180714 nosy: daniel.urban, ncoghlan priority: normal severity: normal stage: patch review status: open title: Implement PEP 422: Simple class initialisation hook type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file28859/pep422_1.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17044 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17044] Implement PEP 422: Simple class initialisation hook
Changes by Ezio Melotti ezio.melo...@gmail.com: -- nosy: +ezio.melotti ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17044 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17037] Add conforms_to_pep399() to test.support
Eli Bendersky added the comment: On Sat, Jan 26, 2013 at 9:10 AM, Eric Snow rep...@bugs.python.org wrote: Eric Snow added the comment: In my case I've been doing PEP 399 for collections.OrderedDict. It struck me that the boilerplate could be stowed away in a decorator. It's more than just adding a couple subclasses. Here's what it covers: * add the test case subclasses, * make sure the original test case does not get used (#16835), PEP 399 dictates that the base class does not inherit from unittest.TestCase, so why would it be used? * use the relevant names as class attributes rather than globals (e.g. self.OrderedDict vs. OrderedDict), Wouldn't it be better to suggest this in PEP 399? Otherwise, the proposed decarator kind-of goes against it. * hack around modules that do their own imports (#16817), Can you clarify how this helps? I though the decorator doesn't (yet?) handle the problem with pickle. * explicit is better than implicit, * relatedly, the solution is more magic/obfuscated that the current boilerplate. You could argue that the magnitude of the problem doesn't warrant a complex decorator, but it doesn't have to be hard to understand. My patch is something I threw together late last night that could certainly be made more clear. More importantly, as more modules get a dual implementation, the above benefits of the decorator become more pronounced. I agree that it can be made clearer, but you are unlikely to lose the metaprogramming magic. My use case was with the tests for OrderedDict. The existing tests don't refer to collections.OrderedDict, but rather to OrderedDict (looked up from the globals). The names argument facilitates the replacement of OrderedDict. Is it possible to just rewrite the tests to use collections.OrderedDict? IMHO this extra 'names' argument adds a lot of magic to the decorator, and if it's just there for a problem that's easy to avoid... -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17037 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17043] Invalid read in test_codecs
Serhiy Storchaka added the comment:
Here are patches for all 4 versions.
--
keywords: +patch
Added file:
http://bugs.python.org/file28860/decodeunicodeinternal_overflow-2.7.patch
Added file:
http://bugs.python.org/file28861/decodeunicodeinternal_overflow-3.2.patch
Added file:
http://bugs.python.org/file28862/decodeunicodeinternal_overflow-3.3.patch
Added file:
http://bugs.python.org/file28863/decodeunicodeinternal_overflow-3.4.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17043
___diff -r 523f309cf558 Objects/unicodeobject.c
--- a/Objects/unicodeobject.c Sat Jan 26 13:31:44 2013 +0100
+++ b/Objects/unicodeobject.c Sun Jan 27 00:05:19 2013 +0200
@@ -3399,37 +3399,34 @@
end = s + size;
while (s end) {
+if (end-s Py_UNICODE_SIZE) {
+endinpos = end-starts;
+reason = truncated input;
+goto error;
+}
memcpy(p, s, sizeof(Py_UNICODE));
+#ifdef Py_UNICODE_WIDE
/* We have to sanity check the raw data, otherwise doom looms for
some malformed UCS-4 data. */
-if (
-#ifdef Py_UNICODE_WIDE
-*p unimax || *p 0 ||
+if (*p unimax || *p 0) {
+endinpos = s - starts + Py_UNICODE_SIZE;
+reason = illegal code point ( 0x10);
+goto error;
+}
#endif
-end-s Py_UNICODE_SIZE
-)
-{
-startinpos = s - starts;
-if (end-s Py_UNICODE_SIZE) {
-endinpos = end-starts;
-reason = truncated input;
-}
-else {
-endinpos = s - starts + Py_UNICODE_SIZE;
-reason = illegal code point ( 0x10);
-}
-outpos = p - PyUnicode_AS_UNICODE(v);
-if (unicode_decode_call_errorhandler(
-errors, errorHandler,
-unicode_internal, reason,
-starts, size, startinpos, endinpos, exc, s,
-v, outpos, p)) {
-goto onError;
-}
-}
-else {
-p++;
-s += Py_UNICODE_SIZE;
+p++;
+s += Py_UNICODE_SIZE;
+continue;
+
+ error:
+startinpos = s - starts;
+outpos = p - PyUnicode_AS_UNICODE(v);
+if (unicode_decode_call_errorhandler(
+errors, errorHandler,
+unicode_internal, reason,
+starts, size, startinpos, endinpos, exc, s,
+v, outpos, p)) {
+goto onError;
}
}
diff -r f7eda8165e6f Objects/unicodeobject.c
--- a/Objects/unicodeobject.c Sat Jan 26 12:14:02 2013 +0200
+++ b/Objects/unicodeobject.c Sat Jan 26 23:55:55 2013 +0200
@@ -4415,37 +4415,34 @@
end = s + size;
while (s end) {
+if (end-s Py_UNICODE_SIZE) {
+endinpos = end-starts;
+reason = truncated input;
+goto error;
+}
memcpy(p, s, sizeof(Py_UNICODE));
+#ifdef Py_UNICODE_WIDE
/* We have to sanity check the raw data, otherwise doom looms for
some malformed UCS-4 data. */
-if (
-#ifdef Py_UNICODE_WIDE
-*p unimax || *p 0 ||
+if (*p unimax || *p 0) {
+endinpos = s - starts + Py_UNICODE_SIZE;
+reason = illegal code point ( 0x10);
+goto error;
+}
#endif
-end-s Py_UNICODE_SIZE
-)
-{
-startinpos = s - starts;
-if (end-s Py_UNICODE_SIZE) {
-endinpos = end-starts;
-reason = truncated input;
-}
-else {
-endinpos = s - starts + Py_UNICODE_SIZE;
-reason = illegal code point ( 0x10);
-}
-outpos = p - PyUnicode_AS_UNICODE(v);
-if (unicode_decode_call_errorhandler(
-errors, errorHandler,
-unicode_internal, reason,
-starts, end, startinpos, endinpos, exc, s,
-v, outpos, p)) {
-goto onError;
-}
-}
-else {
-p++;
-s += Py_UNICODE_SIZE;
+p++;
+s += Py_UNICODE_SIZE;
+continue;
+
+ error:
+startinpos = s - starts;
+outpos = p - PyUnicode_AS_UNICODE(v);
+if (unicode_decode_call_errorhandler(
+errors, errorHandler,
+unicode_internal, reason,
+starts, end, startinpos, endinpos, exc, s,
+v, outpos, p)) {
+goto onError;
}
}
diff -r 8c49dd8e4d22 Objects/unicodeobject.c
--- a/Objects/unicodeobject.c Sat Jan 26 18:57:19 2013 +0100
+++ b/Objects/unicodeobject.c Sat Jan 26 23:50:50 2013 +0200
@@ -6125,6 +6125,11 @@
while (s end) {
Py_UNICODE uch;
[issue17043] Invalid read in test_codecs
Changes by Serhiy Storchaka storch...@gmail.com: -- components: +Interpreter Core, Unicode nosy: +ezio.melotti stage: - patch review type: - behavior versions: +Python 2.7, Python 3.2, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17043 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17041] Fix tests for build --without-doc-strings
Stefan Krah added the comment: The patches are really small, so +1 for committing this before the rc1 for 2.7.4 is released. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17041 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17041] Fix tests for build --without-doc-strings
Stefan Krah added the comment: I left some comments but have no indication that they got mailed. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17041 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17042] Example in C-API memory management doc has confusing order
Eric Snow added the comment: Thanks for clarifying, Stefan. Are you opposed to a comment in the example? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17042 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16468] argparse only supports iterable choices
Chris Jerdonek added the comment:
the choice part of the error message (passed to ArgumentError) will just be
'invalid choice: value'.
That's right. With the patch it looks like this:
p = argparse.ArgumentParser(prog='test.py')
p.add_argument('--foo', choices=c)
p.parse_args(['--foo', 'bad'])
usage: test.py [-h] [--foo FOO]
test.py: error: argument --foo: invalid choice: 'bad'
With that, using default metavars, whatever they end up being
argparse's default metavar is just to capitalize the dest if the argument is
optional, otherwise it is the dest itself (which is always or usually
lower-case):
def _get_default_metavar_for_optional(self, action):
return action.dest.upper()
def _get_default_metavar_for_positional(self, action):
return action.dest
So the patch uses that. You can see the former case in the above usage string.
Also, with the patch the current tests pass, btw.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16468
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10156] Initialization of globals in unicodeobject.c
Stefan Krah added the comment: Buildbots etc. look all good. Thanks for fixing this. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10156 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10156] Initialization of globals in unicodeobject.c
Changes by Stefan Krah stefan-use...@bytereef.org: -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10156 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10156] Initialization of globals in unicodeobject.c
Changes by Stefan Krah stefan-use...@bytereef.org: -- resolution: - fixed stage: patch review - committed/rejected ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10156 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17042] Example in C-API memory management doc has confusing order
Stefan Krah added the comment: Moderately opposed, yes. PyMem_Malloc()/PyMem_Free() and PyMem_New()/PyMem_Del() are already explained in depth above. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17042 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17045] Improve C-API doc for PyTypeObject
New submission from Eric Snow: http://docs.python.org/dev/c-api/typeobj.html I found the the documentation for PyTypeObject to be somewhat harder to use than it need be. In the end I distilled the info down for my own use. I'm comfortable with what I came up with, so I'd like to at least add a condensed version of one or two of the tables I made to the top of the doc, with the slot names linking to each description as it currently exists. Attached is a patch. (I also plan on reformatting the doc source so the lines wrap better--70 columns or so.) As well, I have a couple open questions that I'll address separately: * should tp_del be added? * inheritance of tp_flags... -- files: typeobj-doc.diff keywords: patch messages: 180723 nosy: eric.snow priority: normal severity: normal status: open title: Improve C-API doc for PyTypeObject Added file: http://bugs.python.org/file28864/typeobj-doc.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17045 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
