[issue12641] Remove -mno-cygwin from distutils
Jon added the comment:
I have confirmed on Win7 that the following 32bit MinGW flavors still recognize
-mno-cygwin option and build without error:
(4.5.2) http://tdm-gcc.tdragon.net/download
(4.5.4)
http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Automated%20Builds/
using the mingw-w32-1.0-bin_i686-mingw_20110624.zip download
...by compiling with:
[i686-w64-mingw32-]gcc -Wall -mno-cygwin -o helloworld.exe helloworld.c
...where helloworld.c was:
#include
int main(int argc, char *argv[]) { printf("Hello World!\n"); return 0; }
I have not yet checked the latest mingw.org download from the following, but I
expect that it also recognizes -mno-cygwin. I will check later and report back
if appropriate.
(4.5.2) http://sourceforge.net/projects/mingw/files/
Given Ruben's 4.4 comment, something is odd here. Looks like some gcc source
spelunking as these doc links make no mention of the removal:
http://gcc.gnu.org/gcc-4.6/changes.html
http://gcc.gnu.org/gcc-4.5/changes.html
http://gcc.gnu.org/gcc-4.4/changes.html
and the gcc manual is inconsistent. This summary mentions the option
http://gcc.gnu.org/onlinedocs/gcc-4.6.1/gcc/Option-Summary.html#Option-Summary
but the details sections don't mention the option
http://gcc.gnu.org/onlinedocs/gcc-4.6.1/gcc/i386-and-x86_002d64-Windows-Options.html#i386-and-x86_002d64-Windows-Options
http://gcc.gnu.org/onlinedocs/gcc-4.6.1/gcc/i386-and-x86_002d64-Options.html#i386-and-x86_002d64-Options
Ah, our good friend grep.
--
___
Python tracker
<http://bugs.python.org/issue12641>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12641] Remove -mno-cygwin from distutils
Jon added the comment: should the question be "what's the first mingw gcc version that -mno-cygwin usage unnecessary" rather than finding the first version the option was removed? and, does it matter whether you're building on win for win, or cross compiling for win from nix? sadly, i don't know gcc internals but a post to the mingw and/or mingw-w64 ml's should get the right people weighing in. btw, can distutils do a lightweight configure-like check for feature presence rather than going a gcc version check? -- ___ Python tracker <http://bugs.python.org/issue12641> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12641] Remove -mno-cygwin from distutils
Jon added the comment: >> and, does it matter whether you're building on win for win, or cross >> compiling for win from nix? >I’m afraid I don’t know enough about Windows and MinGW to answer that. If we >can’t be sure about versions and consequences here, I’ll go to the MinGW ML. Ruben's on it :) http://sourceforge.net/mailarchive/message.php?msg_id=27864860 -- ___ Python tracker <http://bugs.python.org/issue12641> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12641] Remove -mno-cygwin from distutils
Jon added the comment: are you ok with a targeted patch similar to what's being discussed at http://sourceforge.net/mailarchive/message.php?msg_id=27895558 assuming the regex search the output of `gcc -dumpspecs` idea is valid? -- ___ Python tracker <http://bugs.python.org/issue12641> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12641] Remove -mno-cygwin from distutils
Jon added the comment: shortly after opening this issue i removed -mno-cygwin from my 2.7.2 install and have had no issues on win7 32bit. but i understand you're hesitation. regardless what you decide, please consider placing a summary note in the source comments as a safety net. if you'd like me to try building a limited set of extensions to help with your decision, let me know. i have the following mingw toolchains on my win7 32bit system: * tdm gcc 4.5.2 - http://tdm-gcc.tdragon.net/ * mingw-w64 prefix-stripped gcc 4.5.4 - http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Automated%20Builds/ * Ruben's gcc 4.6.2 personal build - http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/rubenvb/4.6.2-1/ i'm not speaking for Ruben, but as he maintains https://github.com/rubenvb/MinGW-w64-build-scripts you might try cajoling him if you feel you need more test results ;) re: re.search, understood, thanks...quick-testing. -- ___ Python tracker <http://bugs.python.org/issue12641> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38533] py script runs with python.exe but not pythonw.exe (python console)
New submission from Jon : 3.7.5. Any py script that I run with python.exe or py.exe executes just fine. But if I try to run any py script with pythonW.exe or pyW.exe it will not run. I don't know where the logging for the python executable is located. On the same machine, java.exe and javaW.exe work properly. (jar file runs exactly the same with either executable. Only the cmd/console window is suppressed with "w" exe. I am trying to isolate whether or not python 3.7.5 is to blame or this new windows 10 x64 1809 LTSC machine is to blame. I have tested in both python 3.7.5 x86 and x64 versions. the "W" console version does not run any py scripts. On my previous laptop (win 8.1 x64) and (win2012 r2 x64 server, no problems) with 3.7.4 32 bit. --- How do I have multiple MINOR versions of python together? e.g. 3.7.3, 3.7.4, 3.7.5? Can they be placed in separate folders? -- components: Windows messages: 354982 nosy: 4evermaat, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: py script runs with python.exe but not pythonw.exe (python console) type: behavior versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue38533> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38533] py script runs with python.exe but not pythonw.exe (python console)
Jon added the comment: by the way, just to be sure, I am actually running the python.exe / py.exe / pythonw.exe / pyw.exe from the full file path just to be sure. e.g. %LOCALAPPDATA%\Programs\Python\Launcher\pyw.exe test.py -- ___ Python tracker <https://bugs.python.org/issue38533> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38533] v3.7.5 py script run ok with python.exe but not pythonw.exe (python console)
Jon added the comment: I installed v3.7.4 x86 and scripts work with `pythonw.exe` and `pyw.exe` I also tested v3.7.4 x64 bit and scripts also work ok. So that is some good news. This proves that pythonw (python console) for 3.7.5 is not working for some unknown reasons. It is not related to Win10 (thankfully, as that would be an entirely different beast) Will revert to 3.7.4 and stick with it until further notice. --- That's about 7 hours of my life I will not get back, but I hope it will help someone. -- title: py script runs with python.exe but not pythonw.exe (python console) -> v3.7.5 py script run ok with python.exe but not pythonw.exe (python console) ___ Python tracker <https://bugs.python.org/issue38533> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38533] v3.7.5 py script run ok with python.exe but not pythonw.exe (python console not working)
Change by Jon : -- title: v3.7.5 py script run ok with python.exe but not pythonw.exe (python console) -> v3.7.5 py script run ok with python.exe but not pythonw.exe (python console not working) ___ Python tracker <https://bugs.python.org/issue38533> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38533] v3.7.5 py script run ok with python.exe but not pythonw.exe (python silent console not working)
Change by Jon : -- title: v3.7.5 py script run ok with python.exe but not pythonw.exe (python console not working) -> v3.7.5 py script run ok with python.exe but not pythonw.exe (python silent console not working) ___ Python tracker <https://bugs.python.org/issue38533> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38533] v3.7.5 py script run ok with python.exe but not pythonw.exe (python silent console not working)
Jon added the comment: @paul.moore all scripts failed. it's like pyw.exe does not run at all (or quits shortly after. i have about 5 proprietary scripts. going back to 3.7.4 everything works as before. I do suspect there is something wrong with the way that 3.7.5 was compiled for pythonW.exe python/pw.exe works fine for both 3.7.4 and 3.7.5 (x86 and x64 versions) pythonW/pyW.exe works fine for 3.7.4 but not 3.7.5 (x86 and x64 versions) This is the first time i've ever had this issue. python 3.6.x. I originally thought it was a win10 issue because I am setting up a new computer and using 3.7.5 for the first time. (other computer had 3.7.4). I will ask my programmer to give some sample code. But really any existing script you have should work for testing 3.7.5 pythonw.exe , particularly if it requires a couple of non-core modules to run. Let me know if you are unable to reproduce it. -- ___ Python tracker <https://bugs.python.org/issue38533> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38533] v3.7.5 py script run ok with python.exe but not pythonw.exe (python silent console not working)
Jon added the comment: @eryk. Could I just have separate folder with each python minor version? I would keep it portable and just reference the python/pythonw.exe filepath directly for each version when I run. I could just download the 3.7.5 and drop it anywhere. -- ___ Python tracker <https://bugs.python.org/issue38533> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38533] v3.7.5 py script run ok with python.exe but not pythonw.exe (python silent console not working)
Jon added the comment: BTW, I have win10 x64 v 1809 b 17763.720. -- ___ Python tracker <https://bugs.python.org/issue38533> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38533] v3.7.5 py script run ok with python.exe but not pythonw.exe (python silent console not working)
Jon added the comment: When I have some time. Maybe this weekend. 3.7.4 is working ok right now for production level. So I didn't bother with anything else yet. Might help someone else in the meantime though. Glad to see that someone is taking the complaint seriously :) -- ___ Python tracker <https://bugs.python.org/issue38533> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12641] Remove -mno-cygwin from distutils
Jon added the comment: [Eric] >> This is about mingw, which is the **main free software that builds >> executables on Windows**. You know, for when you don't want to require >> your users to install Visual Studio. > Let me state that I fully sympathize with people who use Windows and > still want to use free software as much as possible, even though some > version of Visual Studio is now available at no cost. Again, the > fact is that many core developers don’t use Windows, and the official > CPython builds use MSVC, so from this viewpoint, MinGW is a niche > platform for CPython. It does not mean that patches are rejected, > just that it’s harder for me to assess them. I'm going to advocate why mingw-based toolchains (mingw.org and mingw-w64) should be considered important platforms for CPython by giving some background info. An important part of this issue has nothing to do with the politics of "free software" and everything to do with the technical benefits of using mingw-based toolchains on Windows. While you may be aware of the technical benefits, the following are important to me: 1a) MSVC forces you to link against a specific CRT version, and I don't get to decide which CRT version via a build setting. To the best of my knowledge the only way to link against another CRT version is to use another MSVC version. Many times it's important for all parts of a codebase to link against the same CRT version to prevent well-known cross-CRT object usage failures. While Mingw toolchains typically link to msvcrt.dll by default, they allow you to specify a CRT version via spec file tweaks. 1b) Often the most practical/stable way to build mixed codebases using CRT functionality is to link everything against msvcrt.dll. Using MSVC, the only way I'm aware of is to use old-and-slow VC6 which is not easily available. Updated and performant mingw toolchains enable one to link against msvcrt.dll and other CRT versions via spec file hackery. 2) While VC++ is a good IDE, many of us would like to simply use the command line compiler tools and not clutter our environment with a huge IDE we never use. MSFT has a poor record on this front, and after many fine years of making the command line tools available as part of the Windows SDK, they've regressed back to their lame ways in Windows 8 by removing the cmd line compiler tools from the SDK and embedding into the IDE similar to the old VC6 days. Enticing as it may be, I'll stop here rather than lurch into sailor-speak rage rant. There are other benefits, but (1a) and (1b) are very important for many real-world usage scenarios on Windows. For example, easily building mercurial with mingw on Windows that work with the official MSVC-built Python. Extend this to other widely used Python and non-Python libraries. Extend this to those building binary libraries on Linux/OSX via mingw for their Windows users. Also, there are other build automation awesomeness things you can do with mingw toolchains. For example, wouldn't it be great if you could download your source software, a complete mingw toolchain, and build the software on Windows in a sandbox using the mingw toolchain? You can with mingw and mingw-w64 toolchains. Nothing to pre-install and highly automated with minimal user intervention. -- ___ Python tracker <http://bugs.python.org/issue12641> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12641] Remove -mno-cygwin from distutils
Jon added the comment: Eric, I'm assuming you are the key decision maker for any fix. As I want to see this issue stay razor focused, where specifically do you need community help? Depending upon your needs, I can test on my win7 32bit notebook with official python 2.7.3. It also has arch 3.7.9 and ubuntu server 12.10 virtualbox vm's. I don't build python from source with mingw and my win8 64bit box isn't ready yet. The win7 box has mingw gcc 4.6.2 32bit and mingw-w64 32bit toolchains, both of which have msys and autohell goodies. I'm swamped these days but will carve out time from somewhere. -- ___ Python tracker <http://bugs.python.org/issue12641> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24187] del statement documentation doesn't mention name binding behaviour
New submission from Jon: The documentation for the del keyword in the language reference doesn't mention the name binding behaviour: https://docs.python.org/3/reference/simple_stmts.html#grammar-token-del_stmt It is mentioned in section 4.1 where it says: "A target occurring in a del statement is also considered bound for this purpose" But it's really not obvious to look there when trying to understand what del does. It would be great if this information were added or a reference made to the other section. -- assignee: docs@python components: Documentation messages: 243163 nosy: docs@python, jc13 priority: normal severity: normal status: open title: del statement documentation doesn't mention name binding behaviour type: enhancement ___ Python tracker <http://bugs.python.org/issue24187> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24187] del statement documentation doesn't mention name binding behaviour
Jon added the comment: Sorry, I think I just misread this section. I was confused by the fact that del binds names like assignment does, so that the following tries to delete a local name and fails: x = 1 def f(): del x f() In fact the documentation does say that there must be global statement in the block for del to delete a global name, so my bad. -- resolution: -> not a bug status: open -> closed ___ Python tracker <http://bugs.python.org/issue24187> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40512] [subinterpreters] Meta issue: per-interpreter GIL
Change by Jon Parise : -- nosy: +jon ___ Python tracker <https://bugs.python.org/issue40512> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1673409] datetime module missing some important methods
Jon Ribbens added the comment: Almost everything you just said about time_t is wrong. time_t is signed, and always has been (otherwise the 'end of time' for 32-bit time_t would be 2106, not 2038). Also, time_t does not end at 2038 because nothing says it must be 32 bits. Also, Python has 'long integers' which do not overflow. Also, I don't understand what you mean about use cases. The "use case" is "dealing with anything which expects standard Unix time_t, for example the Python standard library". The use case I have personally is the program I was working on when I encountered the problem described in this bug report. Also I think symmetry is a darn good argument. Why does fromtimestamp exist if, as you claim, nobody uses time_t? _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1673409> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1673409] datetime module missing some important methods
Jon Ribbens added the comment: > No fractions of a second... If we're expecting floating-point, then everything you said earlier about the limitations of ints was a bit redundant ;-) _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1673409> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1673409] datetime module missing some important methods
Jon Ribbens added the comment: Well, I still think that a convert-to-time_t function is essential, and I don't buy any of the counter-arguments so far. The only argument I can see is "should it return float or integer?" - floats are inaccurate and integers can't represent partial seconds. _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1673409> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1673409] datetime module missing some important methods
Jon Ribbens added the comment: Skip has already provided what amounts to a patch. It just needs to be decided whether to (a) not include it, (b) include it with the floating point part, or (c) include it without the floating point part. I couldn't comment as to how many people need it. I can say that I need it, and anyone else who's used to manipulating dates and times either "in a unixy sort of way" or with libraries that are expecting time_t's will need it. _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1673409> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13345] Invisible Files in Windows 7
New submission from Jon Bryan : Running 32-bit Python in 64-bit Windows 7 Enterprise. I am very much a Python noob. A .dll in c:\Windows\System32 that I need to access can't be found by ctypes.WinDLL(). Upon further investigation I have found that the file, along with many others, doesn't show up in an os.listdir() either. Within IDLE the files don't appear in the drop-down autocomplete list. I don't have this problem on either of the Windows XP machines I've tried it on, but in Win7 I see the same behavior in both 2.7 and 3.2. -- components: IDLE, Windows, ctypes messages: 147052 nosy: jrbryan priority: normal severity: normal status: open title: Invisible Files in Windows 7 type: behavior versions: Python 2.7, Python 3.2 ___ Python tracker <http://bugs.python.org/issue13345> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13345] Invisible Files in Windows 7
Jon Bryan added the comment: Thanks for the suggestions. Since I can put the OEM-supplied DLL in another directory and everything works just fine, I'm not going to spend any more time on it. I assume that it's something to do with file permissions in Win7 that I don't have any inclination to delve into further. And I can always run it on my old laptop if I have to. === Jon -- ___ Python tracker <http://bugs.python.org/issue13345> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13464] HTTPResponse is missing an implementation of readinto
Jon Kuhn added the comment: This is my first contribution to a real open source project. Attached is my patch. Suggestions for improvements are welcome. -- keywords: +patch nosy: +Jon.Kuhn Added file: http://bugs.python.org/file23847/issue13464.patch ___ Python tracker <http://bugs.python.org/issue13464> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13464] HTTPResponse is missing an implementation of readinto
Jon Kuhn added the comment: Thanks for the comments. Attached is an updated patch. In the RawIOBase docs it says "If the object is in non-blocking mode and no bytes are available, None is returned." So I wasn't sure if that meant any time no bytes were available or just when no bytes are available and EOF has not been reached. -- I updated it to return 0 instead of None. I simplified _read_chunked() and renamed it to _readall_chunked() since that is all it does. I added the versionadded tag specifying that it was added in 3.3 since the patch is for the default branch. -- Added file: http://bugs.python.org/file23850/issue13464_r1.patch ___ Python tracker <http://bugs.python.org/issue13464> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue762963] timemodule.c: Python loses current timezone
Changes by Jon Siddle : -- nosy: +jonsiddle ___ Python tracker <http://bugs.python.org/issue762963> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12431] urllib2.Request.get_full_url() broken in newer versions of Python
New submission from Jon Siddle :
Issue8280 fixed an issue where the fragment was being sent to the server (and
returned by get_selector).
Unfortunately the fix means that the "full" URL stored in the Request no longer
includes the fragment either.
This is in contradiction to the documentation which states:
Request.get_full_url()
Return the URL given in the constructor.
Yet:
>>> import urllib2
>>> urllib2.Request("http://host/path#fragment";).get_full_url()
'http://host/path'
The particular use case is a custom scheme handler, which should be able to use
the whole of the opaque part of the URL to operate. Ie, our code wants to do
something like this:
urllib2.Request("foo://opaquestring#opaquestring").get_full_url()
--
messages: 139361
nosy: jonsiddle
priority: normal
severity: normal
status: open
title: urllib2.Request.get_full_url() broken in newer versions of Python
type: behavior
versions: Python 2.7
___
Python tracker
<http://bugs.python.org/issue12431>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7424] segmentation fault in listextend during install
Jon Buller added the comment: I recently upgraded my SparcStation20 to NetBSD-current and thought I would try installing python again. I found that both 2.7.1 and whatever was the most current 2.5 pkgsrc version as of a few months ago built and installed just fine. I'm sorry I can no longer help debug this, but the bug was very repeatable on 2.6 and 2.7 for several years and often happened with 2.5 as well. But I can no longer repeat it. I also can't say if it is a GCC bug, a NetBSD kernel or libc bug, or a python bug. I was sort of expecting it to be a NetBSD bug since I don't remember ever having problems with x86, amd64, or sparc64 NetBSD systems, but I still believe it could be just about anywhere. Jon -- ___ Python tracker <http://bugs.python.org/issue7424> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12924] Missing call to quote_plus() in test_urllib.test_default_quoting()
New submission from Jon Parise : test_default_quoting() runs a number of identical tests on both quote() and quote_plus() (which is most cases have equivalent behavior). However, at the end of the method, there appears to be a missing complementary call to quote_plus() despite there being an assertion call for the quote_plus() case. -- components: Tests files: test_urllib.default_quoting.patch keywords: patch messages: 143663 nosy: jon priority: normal severity: normal status: open title: Missing call to quote_plus() in test_urllib.test_default_quoting() type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file23112/test_urllib.default_quoting.patch ___ Python tracker <http://bugs.python.org/issue12924> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9622] Allow to set profile/trace function globally
Jon Parise added the comment: There are a few places in the patch where you call the global version immediately followed by the local version. For example: +PyEval_SetGlobalTrace(NULL, NULL); PyEval_SetTrace(NULL, NULL); Isn't the local call now redundant given that the global version clears all of the threadstates already? -- nosy: +jon ___ Python tracker <http://bugs.python.org/issue9622> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6394] getppid support in os module on Windows
Jon Anglin added the comment: Here is a unit test for os.getppid on Windows. The test_os.diff file is the diff of the Lib/test/test.os.py file from the py3k svn branch. -- Added file: http://bugs.python.org/file18784/test_os.diff ___ Python tracker <http://bugs.python.org/issue6394> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6394] getppid support in os module on Windows
Jon Anglin added the comment: I have uploaded a new diff file (from the py3k svn trunk) that has all of the changes in Doc/library/os.rst, Modules/posixmodule.c, and Lib/test/test_os.py. It is called 6394.diff. Let me know if I can do anything else to make this happen. -- Added file: http://bugs.python.org/file18785/6394.diff ___ Python tracker <http://bugs.python.org/issue6394> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9752] MSVC Compiler warning in Python\import.c
Jon Anglin added the comment: Windows provides two versions of mkdir in direct.h: int mkdir(const char* dirname) int _mkdir(const char* dirname) The latter is the preferred function because it is conformant to the ISO C++ standard. As you can see, neither function has a mode parameter like the Unix system call. The directory permissions are inherited from the parent directory. I simply defined a macro that expands to the correct version of mkdir for the system that Python is being compiled upon. I found other instances in the Python source where similar things were done so I hope my solution is acceptable. I have tested my solution on 32 and 64 bit builds of Python from the py3k svn trunk. -- keywords: +patch nosy: +janglin Added file: http://bugs.python.org/file18792/9752.diff ___ Python tracker <http://bugs.python.org/issue9752> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9752] MSVC Compiler warning in Python\import.c
Jon Anglin added the comment: Visual Studio ships with the source code for the CRT (\Program Files\Microsoft Visual Studio 9.0\VC\crt\src). I looked up _mkdir. It does just call CreateDirectory(path, NULL). If no error occurs it returns zero. If an error occurs, it then converts the result of GetLastError to an appropriate errno code and returns -1. Thus the following calls are equivalent: _mkdir(dirname); CreateDirectory(dirname, NULL); -- ___ Python tracker <http://bugs.python.org/issue9752> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9752] MSVC Compiler warning in Python\import.c
Jon Anglin added the comment: How about this: see no-macro.diff BTW: should I be using the .patch extension or .diff extension? -- Added file: http://bugs.python.org/file18798/no-macro.diff ___ Python tracker <http://bugs.python.org/issue9752> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9808] Implement os.getlogin on Windows
New submission from Jon Anglin : This is a feature request to implement the os.getlogin function on Windows systems. This may not be a widely used function, but implementing on Windows will bring Python on Windows one step closer to Python on Unix (like) systems. The os_getlogin.diff file contains my proposed patch to add this functionality for Windows. -- components: Library (Lib), Windows files: os_getlogin.diff keywords: patch messages: 115927 nosy: janglin priority: normal severity: normal status: open title: Implement os.getlogin on Windows type: feature request versions: Python 3.2 Added file: http://bugs.python.org/file18808/os_getlogin.diff ___ Python tracker <http://bugs.python.org/issue9808> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9808] Implement os.getlogin on Windows
Jon Anglin added the comment: I can't answer that for the 'LOGNAME' environment variable on non-Windows systems, I was just keying off of what the docs claimed. As for Windows, I just came across this article http://support.microsoft.com/kb/273633 that shows we can not rely on this in the test. I only put those environment variables in the test because I thought this test was a little weak (what else can we do?) user_name = os.getlogin() self.assertNotEqual(0, len(user_name)) Even though %USERNAME% == os.getlogin() MOST of the time. It should be removed from the test. -- ___ Python tracker <http://bugs.python.org/issue9808> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9808] Implement os.getlogin on Windows
Jon Anglin added the comment: Here is an updated patch with the updated test. This test does not use either the LOGNAME or USERNAME environment variables. -- Added file: http://bugs.python.org/file18814/issue9808.diff ___ Python tracker <http://bugs.python.org/issue9808> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9784] _msi.c warnings under 64-bit Windows
Changes by Jon Anglin : -- nosy: +janglin ___ Python tracker <http://bugs.python.org/issue9784> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9783] _elementtree.c warnings under 64-bit Windows
Changes by Jon Anglin : -- nosy: +janglin ___ Python tracker <http://bugs.python.org/issue9783> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9782] _multiprocessing.c warnings under 64-bit Windows
Changes by Jon Anglin : -- nosy: +janglin ___ Python tracker <http://bugs.python.org/issue9782> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9566] Compilation warnings under x64 Windows
Changes by Jon Anglin : -- nosy: +janglin ___ Python tracker <http://bugs.python.org/issue9566> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9614] _pickle is not entirely 64-bit safe
Changes by Jon Anglin : -- nosy: +janglin ___ Python tracker <http://bugs.python.org/issue9614> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9808] Implement os.getlogin on Windows
Jon Anglin added the comment: I went ahead and moved the test skip decorator to the class level as suggested by Brian Curtin, see issue9808-new.diff. -- Added file: http://bugs.python.org/file18886/issue9808-new.diff ___ Python tracker <http://bugs.python.org/issue9808> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9808] Implement os.getlogin on Windows
Jon Anglin added the comment: The _countof(_x_) macro expands to something like this: sizeof(_x_)/sizeof(_x_[0]) This was an attempt by Microsoft to mitigate some buffer overrun issues. I have gotten in the habit of using it as it is less verbose. I have uploaded a new issue9808.diff file that removes the _countof macro. I will leave it up to those with commit privileges which version gets checked in. Personally I like it because it clarifies the programmers intent. Why not introduce it to the Python code base? -- Added file: http://bugs.python.org/file18912/issue9808.diff ___ Python tracker <http://bugs.python.org/issue9808> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9808] Implement os.getlogin on Windows
Changes by Jon Anglin : -- status: open -> closed ___ Python tracker <http://bugs.python.org/issue9808> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9783] _elementtree.c warnings under 64-bit Windows
Jon Anglin added the comment: issue9783.diff provides a patch that will compile clean on 32 and 64 bit Windows systems. I tried to avoid explicit casts where I could, but it was not always possible. I have ported a lot of my company's code to 64 bit (all Windows based). In my experience many warnings are because of programmers using the int type in places where a size_t may be more appropriate. Most of the warnings here are due to mixing int and Py_ssize_t types. -- keywords: +patch Added file: http://bugs.python.org/file18988/issue9783.diff ___ Python tracker <http://bugs.python.org/issue9783> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9784] _msi.c warnings under 64-bit Windows
Jon Anglin added the comment: issue9784.diff contains a patch that compiles clean on 32 and 64 bit Windows. This patch is exactly what Amaury Forgeot d'Arc recommended in msg115750. -- keywords: +patch Added file: http://bugs.python.org/file18989/issue9784.diff ___ Python tracker <http://bugs.python.org/issue9784> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9944] Typo in doc for itertools recipe of consume
New submission from Jon Clements : Very low priority. def consume(iterator, n): "Advance the iterator n-steps ahead. If n is none, consume entirely." # Use functions that consume iterators at C speed. if n is None: # feed the entire iterator into a zero-length deque collections.deque(iterator, maxlen=0) else: # advance to the emtpy slice starting at position n next(islice(iterator, n, n), None) Hardly a show stoppper, and not me worth submitting a patch, but "emtpy" should be "empty". Just thought I'd make note of it before I forgot. -- assignee: d...@python components: Documentation messages: 117339 nosy: d...@python, joncle priority: normal severity: normal status: open title: Typo in doc for itertools recipe of consume versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3 ___ Python tracker <http://bugs.python.org/issue9944> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9784] _msi.c warnings under 64-bit Windows
Jon Anglin added the comment: Martin Lowis do you mean API when you type SDK? If I understand what you are saying, you would rather use the Win32 API instead of the CRT API? It may interest you to know that _open calls CreateFile internally, _read calls ReadFile, _write calls WriteFile, _lseek calls SetFilePointer, and _close calls CloseHandle. There is a bit more to it than that but it is not really relevant to this discussion. What is relevant is that inside _open, CreateFile will return an OS HANDLE type (64 bits in our case) that is mapped to a 32 bit integer CRT file descriptor that is then returned. The other functions such as _read, etc…, will look up the 64 bit OS HANDLE value from the given 32 bit file descriptor and call the corresponding Win32 API function. We could rewrite the functions using the Win32 API directly but we don’t have to. I realize this is a Windows only module but the use of the CRT API is more familiar to a majority of the Python developers (I would guess). I stand by the patch. -- ___ Python tracker <http://bugs.python.org/issue9784> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9784] _msi.c warnings under 64-bit Windows
Jon Anglin added the comment: > I have the long-term plan to eliminate all CRT usage from Python > on Windows. In this case, there is a straight-forward opportunity > to do so. Oh, OK. If that is the plan then I am on board. I will re-code the patch using the Win32 API directly. >> It may interest you to know that _open calls CreateFile internally, > I'm fully aware of that. I meant no disrespect, I just didn't know if you were a "Windows" guy. If you asked me what system call _open (or others) calls on Linux or Mac, I would have no clue. -- ___ Python tracker <http://bugs.python.org/issue9784> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9783] _elementtree.c warnings under 64-bit Windows
Jon Anglin added the comment:
Martin is correct about this patch.
> In cases where we really can't propagate Py_ssize_t to (e.g.
> XML_Parse), we need to check for an int overflow, and raise
> an exception if it does overflow.
Is this an appropriate approach?
int
PySize_AsInt(Py_ssize_t value)
{
if (value > (Py_ssize_t)INT_MAX || value < (Py_ssize_t)INT_MIN) {
PyErr_SetString(PyExc_OverflowError,
"Size value can not be represented as an integer");
}
return (int)value;
}
I would only define this when sizeof(Py_ssize_t) > sizeof(int) of course. In
other cases it would be a macro that just evaluates to value.
I would most likely need an unsigned version as well (although not for this
particular issue).
This code could be used in many C modules. Where in the Python code base should
such functions be placed?
--
___
Python tracker
<http://bugs.python.org/issue9783>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9784] _msi.c warnings under 64-bit Windows
Jon Anglin added the comment: I have uploaded another patch that replaces CRT API calls with Win32 API calls. It compiles cleanly under 32 and 64 bit Windows. Is there a unit test for msilib? I was not able to find one, thus the patch is not fully tested. -- Added file: http://bugs.python.org/file19065/issue9784.diff ___ Python tracker <http://bugs.python.org/issue9784> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10194] Add gc.remap() function to the gc module.
Changes by Jon Parise : -- nosy: +jon ___ Python tracker <http://bugs.python.org/issue10194> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5755] "-Wstrict-prototypes" is valid for Ada/C/ObjC but not for C++"
Changes by Jon Parise : -- nosy: +jon ___ Python tracker <http://bugs.python.org/issue5755> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11251] cmd.Cmd tab completion treats dashes as spaces
New submission from Jon McKenzie : I'm writing a cmd.Cmd module that operates on filenames. As such, I'm attempting to write tab completions that operate similar to bash. However, files that contain dashes (hyphens) appear to exhibit unexpected behavior. It appears that somewhere along the line, dashes are converted into spaces for the purposes of tab completion. So, for example.. (Cmd) edit blah- Should print.. blah-1.0.0.txt blah-2.0.0.txt And.. (Cmd) edit blah-1 Should autocomplete to.. (Cmd) edit blah-1.0.0.txt Instead, the following behavior occurs: (Cmd) edit blah- ..becomes... (Cmd) edit blah-blah ..and thus.. (Cmd) edit blah-blah- ..becomes, in turn.. (Cmd) edit blah-blah-blah My completion function is absolutely standard, as far as I'm able to tell from looking at other examples (see attached) -- files: completion.snip messages: 12 nosy: Jon.McKenzie priority: normal severity: normal status: open title: cmd.Cmd tab completion treats dashes as spaces type: behavior versions: Python 2.6 Added file: http://bugs.python.org/file20801/completion.snip ___ Python tracker <http://bugs.python.org/issue11251> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11251] cmd.Cmd tab completion treats dashes as spaces
Jon McKenzie added the comment: Marked as closed, since I found this was not a bug, but just a readline default. Can set tab completion delimiters with readline.set_completer_delims(string) -- resolution: -> wont fix status: open -> closed ___ Python tracker <http://bugs.python.org/issue11251> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3289] unnecessary call to time and localtime slows time.mktime
New submission from Jon Nelson <[EMAIL PROTECTED]>:
Basically, time.mktime calls time and localtime, and then overwrites
those results. Removing these unnecessary calls results in a fairly
noticeable speedup, lower double-digit percentile improvements for
applications that do time parsing, for example.
The patch below is for 2.5, but should apply to more recent versions.
diff --git a/Modules/timemodule.c b/Modules/timemodule.c
index be02ec2..dad235a 100644
--- a/Modules/timemodule.c
+++ b/Modules/timemodule.c
@@ -599,8 +599,6 @@ time_mktime(PyObject *self, PyObject *tup)
{
struct tm buf;
time_t tt;
- tt = time(&tt);
- buf = *localtime(&tt);
if (!gettmarg(tup, &buf))
return NULL;
tt = mktime(&buf);
--
components: Extension Modules
messages: 69283
nosy: nother_jnelson
severity: normal
status: open
title: unnecessary call to time and localtime slows time.mktime
type: performance
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3289>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6906] Tkinter sets an unicode environment variable on win32
Jon Foster added the comment: This bug also breaks code that uses the subprocess module, e.g.: env = os.environ.copy() env['MY_VARIABLE'] = 'MY_VAL' subprocess.Popen(... , env=env) Fails on Windows 7 with an error that the environment can only contain strings. The offending variables are TK_LIBRARY and TCL_LIBRARY, which have Unicode strings as their values. I'm using Python 2.6.2. (The subprocess module should probably be fixed to use CreateProcessW and handle Unicode, but that's a separate issue). -- nosy: +JonFoster ___ Python tracker <http://bugs.python.org/issue6906> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8078] add more baud constants to termios
New submission from Jon Smirl : termios doesn't have the constants defined for higher baud rates on Linux. According to my bits/termios.h: #define B57600 0010001 #define B115200 0010002 #define B230400 0010003 #define B460800 0010004 #define B50 0010005 #define B576000 0010006 #define B921600 0010007 #define B100 0010010 #define B1152000 0010011 #define B150 0010012 #define B200 0010013 #define B250 0010014 #define B300 0010015 #define B350 0010016 #define B400 0010017 -- messages: 100515 nosy: jonsmirl severity: normal status: open title: add more baud constants to termios type: feature request ___ Python tracker <http://bugs.python.org/issue8078> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7424] segmentation fault in listextend during install
Jon Buller added the comment:
Sorry to not be able to follow up for so long, but I was moving
cross-country.
I was playing with the tests a bit and ended up trying this:
$ ./python -E -tt -d -v -W all ./Lib/test/regrtest.py -l -v -s test_builtin
Which resulted (after quite a bit of output) in this:
# /usr/pkgsrc/lang/python26/work/Python-2.6.4/Lib/tempfile.pyc matches
/usr/pkgsrc/lang/python26/work/Python-2.6.4/Lib/tempfile.py
import tempfile # precompiled from
/usr/pkgsrc/lang/python26/work/Python-2.6.4/Lib/tempfile.pyc
dlopen("/usr/pkgsrc/lang/python26/work/Python-2.6.4/build/lib.netbsd-5.99.24-sparc-2.6/fcntl.so",
2);
import fcntl # dynamically loaded from
/usr/pkgsrc/lang/python26/work/Python-2.6.4/build/lib.netbsd-5.99.24-sparc-2.6/fcntl.so
import thread # builtin
test_builtin
[1] Segmentation fault ./python -E -tt -d -v -W all
./Lib/test/regrtest.py -l -v -s test_builtin
So, is this perhaps a bug either in Python's thread usage, or NetBSD's
thread
library? Is there an easy way to tell python to build without any threads,
even if configure finds the proper system include files and libraries? Is
it as simple as "./configure --without-threads" when starting the build?
(I'm about to try that...)
Jon
--
___
Python tracker
<http://bugs.python.org/issue7424>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7424] segmentation fault in listextend during install
Jon Buller added the comment: "./configure --without-threads" didn't seem to have any effect... :( -- ___ Python tracker <http://bugs.python.org/issue7424> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7424] segmentation fault in listextend during install
Jon Buller added the comment: This is bad. The problem went away and the test completed without the segfault. If you think the output would help track anything down, let me know and I'll save and upload it somewhere. (Or I could hand out an SSH account via IPv6 to the machine... With some effort, I could probably reconfigure my network to get it on one of my 2 IPv4 addresses.) -- ___ Python tracker <http://bugs.python.org/issue7424> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8185] re.findall()
Jon Clements added the comment:
Seems consistent to me:
.match, .search and .finditer return a MatchObject whose .group() return the
*entire matched string*. If you use .group(1) you'll get similar results to
.findall() which returns a list of (possibly of tuples) of the captured
groupings.
This is the findall equivalent (using a non-capturing group):
>>> re.findall('a(?:b)?', 'ab')
['ab']
--
nosy: +joncle
___
Python tracker
<http://bugs.python.org/issue8185>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7424] segmentation fault in listextend during install
Jon Buller added the comment: I found that python 2.4.5 will compile and install on this machine, though I don't know if that helps anyone or not, or how to track this down further. (At least I can run mercurial on that machine again.) On 03/11/10 18:16, Jon Buller wrote: > > Jon Buller added the comment: > > This is bad. The problem went away and the test completed without the > segfault. If you think the output would help track anything down, let > me know and I'll > save and upload it somewhere. (Or I could hand out an SSH account via > IPv6 to the machine... With some effort, I could probably reconfigure > my network to get it > on one of my 2 IPv4 addresses.) > > -- > > ___ > Python tracker > <http://bugs.python.org/issue7424> > ___ -- ___ Python tracker <http://bugs.python.org/issue7424> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1911] webbrowser.open firefox 3 issues
New submission from Jon Wilson:
webbrowser.open('http://example.com')
opens something like:
file:///path/to/home/directory/"http://example.com";
in firefox 3 beta 2. this behavior of firefox will most like not change
in the stable release.
--
components: Extension Modules
messages: 61552
nosy: elessar
severity: normal
status: open
title: webbrowser.open firefox 3 issues
versions: Python 2.5
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1911>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1911] webbrowser.open firefox 3 issues
Jon Wilson added the comment:
I'm running 2.6.23.9 linux kernel fedora 8.
I've gone ahead and downloaded the subversion checkout of the
webbrowser.py file to see the differences. The svn version fixes the
issue, so then I went a hunting as to why.
In the 2.5 version, with a version of firefox running out of my home
directory (but still in my path) webbrowser calles BackgroundBrowser
instead of UnixBrowser.
BackgroundBrowser calls subprocess.Popen(cmdline), where cmdline is a
tuble in form ['/browser/path', '"http://example.com";'], and subprocess
doesn't use/like the double quotes (probably legacy os.popen format)
The difference in the two webbrowser scripts that fixes it is thus:
446a445,455
> # The default Gnome browser
> if _iscommand("gconftool-2"):
> # get the web browser string from gconftool
> gc = 'gconftool-2 -g /desktop/gnome/url-handlers/http/command
2>/dev/n
ull'
> out = os.popen(gc)
> commd = out.read().strip()
> retncode = out.close()
>
> # if successful, register it
> if retncode is None and commd:
> register("gnome", None, BackgroundBrowser(commd.split()))
448,456c457
< # The default GNOME browser
< if "GNOME_DESKTOP_SESSION_ID" in os.environ and
_iscommand("gnome-open"):
< register("gnome-open", None, BackgroundBrowser("gnome-open"))
<
< # The default KDE browser
< if "KDE_FULL_SESSION" in os.environ and _iscommand("kfmclient"):
< register("kfmclient", Konqueror, Konqueror("kfmclient"))
<
< # The Mozilla/Netscape browsers
so it appears to be a problem with gconf that python has to work around.
see: https://bugs.launchpad.net/ubuntu/+source/python2.5/+bug/83974
So as long as it is in trunk 2.5.2 should fix it! (the patch is not in
2.5.1). thanks.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1911>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4249] HTTPResponse instance has no attribute 'code'
New submission from Jon Perez <[EMAIL PROTECTED]>: In http_response in HTTPErrorProcessor, the following line code, msg, hdrs = response.code, response.msg, response.info() results in an error because response.code is not a valid attribute, changing it to response.status works, but is this the correct bug fix? See http://www.linuxquestions.org/questions/linux-newbie-8/problem-with-yum-fedora-9-670586/ Traceback (most recent call last): File "/usr/bin/yum", line 30, in yummain.main(sys.argv[1:]) File "/usr/share/yum/yummain.py", line 233, in main clientStuff.get_package_info_from_servers(serverlist, HeaderInfo) File "/usr/share/yum/clientStuff.py", line 846, in get_package_info_from_servers progress_obj=None) File "/usr/share/yum/clientStuff.py", line 1327, in grab bandwidth, conf.retries, retrycodes, checkfunc) File "/usr/share/yum/urlgrabber.py", line 237, in retrygrab progress_obj, throttle, bandwidth) File "/usr/share/yum/urlgrabber.py", line 314, in urlgrab fo = urllib2.urlopen(url) File "/usr/lib/python2.5/urllib2.py", line 121, in urlopen return _opener.open(url, data) File "/usr/lib/python2.5/urllib2.py", line 380, in open response = meth(req, response) File "/usr/lib/python2.5/urllib2.py", line 487, in http_response code, msg, hdrs = response.code, response.msg, response.info() AttributeError: HTTPResponse instance has no attribute 'code' -- components: Library (Lib) messages: 75454 nosy: jbperz808 severity: normal status: open title: HTTPResponse instance has no attribute 'code' type: behavior versions: Python 2.4, Python 2.5 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4249> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4250] urllib2.py: HTTPResponse instance has no attribute 'code'
New submission from Jon Perez <[EMAIL PROTECTED]>: In http_response() in HTTPErrorProcessor in urllib2.py, the following line code, msg, hdrs = response.code, response.msg, response.info() results in an error because response.code is not a valid attribute, changing it to response.status works, but is this the correct bug fix? See http://www.linuxquestions.org/questions/linux-newbie-8/problem-with-yum-fedora-9-670586/ Traceback (most recent call last): File "/usr/bin/yum", line 30, in yummain.main(sys.argv[1:]) File "/usr/share/yum/yummain.py", line 233, in main clientStuff.get_package_info_from_servers(serverlist, HeaderInfo) File "/usr/share/yum/clientStuff.py", line 846, in get_package_info_from_servers progress_obj=None) File "/usr/share/yum/clientStuff.py", line 1327, in grab bandwidth, conf.retries, retrycodes, checkfunc) File "/usr/share/yum/urlgrabber.py", line 237, in retrygrab progress_obj, throttle, bandwidth) File "/usr/share/yum/urlgrabber.py", line 314, in urlgrab fo = urllib2.urlopen(url) File "/usr/lib/python2.5/urllib2.py", line 121, in urlopen return _opener.open(url, data) File "/usr/lib/python2.5/urllib2.py", line 380, in open response = meth(req, response) File "/usr/lib/python2.5/urllib2.py", line 487, in http_response code, msg, hdrs = response.code, response.msg, response.info() AttributeError: HTTPResponse instance has no attribute 'code' -- components: Library (Lib) messages: 75455 nosy: jbperz808 severity: normal status: open title: urllib2.py: HTTPResponse instance has no attribute 'code' type: behavior versions: Python 2.4, Python 2.5 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4250> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1673409] datetime module missing some important methods
Jon Ribbens added the comment: > A timedelta.toseconds method (or equivalent) makes no sense. > The number of seconds in a day is not fixed (due to leap seconds) and > relying on such a method would introduce subtle bugs. You are misunderstanding what timedelta is. It is a fixed-length period of time. It is stored as a number of (24x3600-second) days, seconds and microseconds. There is no "start date" or "end date", so the concept of leap seconds just does not apply. ___ Python tracker <http://bugs.python.org/issue1673409> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5177] multiprocessing: SocketListener should use SO_REUSEADDR
New submission from Jon Dee : Without this flag it is necessary to wait for e.g. 120s after closing down a 'BaseManager' server before restarting, due to the socket being in the TIME_WAIT state. Example error, which occurs if a server is started, data transmitted down the socket, the server shut down, then restarted: File "/usr/local/lib/python2.6/multiprocessing/connection.py", line 220, in __init__ self._socket.bind(address) File "", line 1, in bind error: [Errno 48] Address already in use I added (locally): self._socket.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) to SocketListener.__init__, and it resolves the issue. -- components: Library (Lib) messages: 81336 nosy: jon_dee severity: normal status: open title: multiprocessing: SocketListener should use SO_REUSEADDR type: behavior versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue5177> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47117] repl segfaults on non utf-8 input
New submission from Jon Åslund : Some bytes that are non utf-8 segfaults python repl in 3.10 and later on linux. Example: $ python3.10 Python 3.10.4 (main, Mar 24 2022, 14:20:44) [GCC 9.4.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> � Segmentation fault (core dumped) It is treated correctly in Python 3.9 and earlier $ python3.9 Python 3.9.12 (main, Mar 24 2022, 14:21:53) [GCC 9.4.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> � File "", line 0 SyntaxError: (unicode error) 'utf-8' codec can't decode byte 0xb6 in position 0: invalid start byte How to reproduce: In Gnome on Ubuntu 20.04 with the Swedish keyboard layout, holding left alt and pressing the ö key enters the byte 0xb6 into the terminal. I have only been able to make it crash the repl. I can't make it crash the parser. For instance trying to eval the byte. -- messages: 415992 nosy: jooon priority: normal severity: normal status: open title: repl segfaults on non utf-8 input type: crash versions: Python 3.10, Python 3.11 ___ Python tracker <https://bugs.python.org/issue47117> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47117] repl segfaults on non utf-8 input
Jon Åslund added the comment: Yes. I think they are the same. I can reproduce the emoji crash. This is much easier to reproduce. No need to have a Swedish keyboard layout. 1. Copy _😀 2. Start python with a non unicode locale. LC_ALL=C python3.10 3. Paste in _😀 4. Press backspace once. It will look like the 2 character wide emoji is replaced by a 1 character wide space. 6. Press return 7. Crash -- ___ Python tracker <https://bugs.python.org/issue47117> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47117] repl segfaults on non utf-8 input
Jon Åslund added the comment: very similar back trace too (gdb) run Starting program: /home/jon/.pyenv/versions/3.10.4/bin/python3.10 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Python 3.10.4 (main, Mar 24 2022, 14:20:44) [GCC 9.4.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> _ Program received signal SIGSEGV, Segmentation fault. __strchr_avx2 () at ../sysdeps/x86_64/multiarch/strchr-avx2.S:57 57 ../sysdeps/x86_64/multiarch/strchr-avx2.S: No such file or directory. (gdb) bt #0 __strchr_avx2 () at ../sysdeps/x86_64/multiarch/strchr-avx2.S:57 #1 0x557d4a7a in get_error_line (lineno=lineno@entry=0, p=, p=) at Parser/pegen.c:443 #2 0x557d541b in _PyPegen_raise_error_known_location (p=0x77885ed0, errtype=0x558fe420 <_PyExc_SyntaxError>, lineno=0, col_offset=0, end_lineno=0, end_col_offset=-1, errmsg=0x558a2dd3 "(%s) %U", va=0x7fffd410) at Parser/pegen.c:499 #3 0x557d5646 in _PyPegen_raise_error (p=p@entry=0x77885ed0, errtype=, errmsg=errmsg@entry=0x558a2dd3 "(%s) %U") at Parser/pegen.c:422 #4 0x557d5839 in raise_decode_error (p=p@entry=0x77885ed0) at Parser/pegen.c:271 #5 0x557d6193 in initialize_token (token_type=60, end=0x0, start=, token=0x77a55d10, p=0x77885ed0) at Parser/pegen.c:720 #6 _PyPegen_fill_token (p=p@entry=0x77885ed0) at Parser/pegen.c:793 #7 0x557fec00 in statement_newline_rule (p=0x77885ed0) at Parser/parser.c:1080 #8 interactive_rule (p=0x77885ed0) at Parser/parser.c:1002 #9 _PyPegen_parse (p=p@entry=0x77885ed0) at Parser/parser.c:34508 #10 0x557d6c60 in _PyPegen_run_parser (p=0x77885ed0) at Parser/pegen.c:1342 #11 0x557d718f in _PyPegen_run_parser_from_file_pointer (fp=fp@entry=0x77e29980 <_IO_2_1_stdin_>, start_rule=start_rule@entry=256, filename_ob=filename_ob@entry=0x77a85670, enc=enc@entry=0x77a7c1a0 "utf-8", ps1=, ps1@entry=0x1e00160 , ps2=ps2@entry=0xe001a0 , flags=0x7fffd7f8, errcode=0x7fffd724, arena=0x7792cc70) at Parser/pegen.c:1448 #12 0x5575661c in _PyParser_ASTFromFile (fp=fp@entry=0x77e29980 <_IO_2_1_stdin_>, filename_ob=filename_ob@entry=0x77a85670, enc=enc@entry=0x77a7c1a0 "utf-8", mode=mode@entry=256, ps1=0x1e00160 , ps1@entry=0x77acf960 ">>> ", ps2=0xe001a0 , ps2@entry=0x77af02e0 "... ", flags=, errcode=, arena=) at Parser/peg_api.c:26 #13 0x556cad97 in PyRun_InteractiveOneObjectEx (fp=fp@entry=0x77e29980 <_IO_2_1_stdin_>, filename=filename@entry=0x77a85670, flags=flags@entry=0x7fffd7f8) at Python/pythonrun.c:257 #14 0x556cba26 in _PyRun_InteractiveLoopObject (fp=fp@entry=0x77e29980 <_IO_2_1_stdin_>, filename=filename@entry=0x77a85670, flags=flags@entry=0x7fffd7f8) at Python/pythonrun.c:148 #15 0x556cc5ce in _PyRun_AnyFileObject (flags=, closeit=, filename=0x77a85670, fp=) at Python/pythonrun.c:84 #16 PyRun_AnyFileExFlags (fp=0x77e29980 <_IO_2_1_stdin_>, filename=filename@entry=0x55802103 "", closeit=closeit@entry=0, flags=flags@entry=0x7fffd7f8) at Python/pythonrun.c:116 #17 0x555bb5c7 in pymain_run_stdin (config=0x55932ce0) at Modules/main.c:502 #18 pymain_run_python (exitcode=exitcode@entry=0x7fffd930) at Modules/main.c:590 #19 0x555bba1f in Py_RunMain () at Modules/main.c:666 #20 pymain_main (args=0x7fffd8f0) at Modules/main.c:696 #21 Py_BytesMain (argc=, argv=) at Modules/main.c:720 #22 0x77c610b3 in __libc_start_main (main=0x555aedb0 , argc=1, argv=0x7fffda58, init=, fini=, rtld_fini=, stack_end=0x7fffda48) at ../csu/libc-start.c:308 #23 0x555ba57e in _start () at ./Include/internal/pycore_pyerrors.h:14 -- ___ Python tracker <https://bugs.python.org/issue47117> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36409] plistlib old API should be removed
Change by Jon Janzen : -- pull_requests: +15288 pull_request: https://github.com/python/cpython/pull/15615 ___ Python tracker <https://bugs.python.org/issue36409> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36409] plistlib old API should be removed
Change by Jon Janzen : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue36409> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38053] Update plistlib documentation
New submission from Jon Janzen : * Update "Mac OS X" to "Apple" since plists are used more widely than just macOS * Remove notes about the new API being added in 3.4 since 3.4 is no longer supported * Re-add the UID class documentation (oops, removed in issue36409) -- assignee: docs@python components: Documentation messages: 351309 nosy: bigfootjon, docs@python priority: normal pull_requests: 15381 severity: normal status: open title: Update plistlib documentation type: enhancement versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue38053> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38053] Update plistlib documentation
Jon Janzen added the comment: >* Remove notes about the new API being added in 3.4 since 3.4 is no longer >supported Per discussion in the PR, this is no longer a goal of this issue -- ___ Python tracker <https://bugs.python.org/issue38053> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38143] plistlib: cleanup PEP8 violations
New submission from Jon Janzen : There are a series of PEP8 violations in plistlib. Most of them are spacing issues, a few naming issues, and also some unused function parameters and unused imports that can be done away with. -- components: Library (Lib) messages: 352221 nosy: bigfootjon, ned.deily, ronaldoussoren priority: normal severity: normal status: open title: plistlib: cleanup PEP8 violations type: enhancement versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue38143> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38143] plistlib: cleanup PEP8 violations
Change by Jon Janzen : -- keywords: +patch pull_requests: +15694 stage: -> patch review pull_request: https://github.com/python/cpython/pull/16074 ___ Python tracker <https://bugs.python.org/issue38143> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25947] Installation problem
Jon Camilleri added the comment: this is your call, sorry. On Tue, Jun 22, 2021 at 4:06 PM Irit Katriel wrote: > > Irit Katriel added the comment: > > Version 3.5 is no longer supported. If you are having issues installing a > current version (3.9+) please create a new issue. > > -- > nosy: +iritkatriel > resolution: -> out of date > stage: -> resolved > status: open -> closed > > ___ > Python tracker > <https://bugs.python.org/issue25947> > ___ > -- Jonathan Camilleri Mobile (MT): ++356 7982 7113 E-mail: camilleri@gmail.com Please consider your environmental responsibility before printing this e-mail. I usually reply to emails within 2 business days. If it's urgent, give me a call. https://worldhappiness.report/ -- ___ Python tracker <https://bugs.python.org/issue25947> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22393] multiprocessing.Pool shouldn't hang forever if a worker process dies unexpectedly
Change by Jon Clucas : -- nosy: +shnizzedy ___ Python tracker <https://bugs.python.org/issue22393> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43805] multiprocessing.Queue hangs when process on other side dies
Change by Jon Clucas : -- nosy: +shnizzedy ___ Python tracker <https://bugs.python.org/issue43805> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45884] datetime.strptime incorrectly handling hours and minutes with bad format string
New submission from Jon Oxtoby :
Running datetime.strptime against a string containing year, month, day but with
a formatter including %H causes a two-digit day to be split across the day and
hour fields of the datetime:
datetime.datetime.strptime('20140812', '%Y%m%d%H')
returns: datetime.datetime(2014, 8, 1, 2, 0)
expected: ValueError: time data '20140812' does not match format '%Y%m%d%H'
datetime.datetime.strptime('2014081201', '%Y%m%d%H%M')
returns: datetime.datetime(2014, 8, 12, 0, 1)
expected: ValueError: time data '2014081201' does not match format '%Y%m%d%H%M'
--
components: Library (Lib)
messages: 406877
nosy: joxtoby27
priority: normal
severity: normal
status: open
title: datetime.strptime incorrectly handling hours and minutes with bad format
string
type: behavior
versions: Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue45884>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45884] datetime.strptime incorrectly handling hours and minutes with bad format string
Jon Oxtoby added the comment: Just noticed the potential for this issue was raised in https://bugs.python.org/msg393688 so it's possible this is not a bug and is the desired behavior, but the documentation doesn't seem to address the issue (unless I'm overlooking it). -- ___ Python tracker <https://bugs.python.org/issue45884> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45884] datetime.strptime incorrectly handling hours and minutes with bad format string
Jon Oxtoby added the comment: I was indeed overlooking the note in the documentation that the leading zero is optional for some formatters when using strptime. Closing. -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue45884> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38861] zipfile: Corrupts filenames containing non-UTF8 characters
Jon Nalley added the comment: I think the Python implementation is adhering to the zip specification. >From the specification v6.3.6 (Revised: April 26, 2019): If general purpose bit 11 is unset, the file name and comment SHOULD conform to the original ZIP character encoding. If general purpose bit 11 is set, the filename and comment MUST support The Unicode Standard, Version 4.1.0 or greater using the character encoding form defined by the UTF-8 storage specification. https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT -- nosy: +jnalley ___ Python tracker <https://bugs.python.org/issue38861> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38861] zipfile: Corrupts filenames containing non-UTF8 characters
Jon Nalley added the comment: Please see a detailed explanation of the behavior here: https://gist.github.com/jnalley/cec21bca2d865758bc5e23654df28bd5 -- ___ Python tracker <https://bugs.python.org/issue38861> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39732] plistlib should export UIDs in XML like Apple does
Change by Jon Janzen : -- nosy: +bigfootjon ___ Python tracker <https://bugs.python.org/issue39732> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42944] random.Random.sample bug when counts is not None
New submission from Jon FRANCO :
Hello,
If I am reading right, random.Random.sample method has a bug if counts is not
None.
Line 482 (of master):
"""
selections = sample(range(total), k=k)
"""
this is calling the module function 'sample' and not the instance method.
IMO this line should be:
"""
selections = self.sample(range(total), k=k)
"""
Python 3.9.1 (default, Dec 11 2020, 14:32:07)
[GCC 7.3.0] :: Anaconda, Inc. on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from random import Random
>>> r = Random()
>>> r.seed('bug')
>>> r.sample(range(50), 5, counts=range(1,51))
[34, 39, 31, 42, 38]
>>> r.seed('bug')
>>> r.sample(range(50), 5, counts=range(1,51))
[39, 11, 3, 12, 29] <====== this should be [34, 39, 31, 42, 38]
>>> r.seed('nobug')
>>> r.sample(range(50), 5)
[0, 30, 23, 17, 49]
>>> r.seed('nobug')
>>> r.sample(range(50), 5)
[0, 30, 23, 17, 49]
Regards,
Jon FRANCO
--
components: Library (Lib)
messages: 385152
nosy: jonfranco, rhettinger
priority: normal
severity: normal
status: open
title: random.Random.sample bug when counts is not None
type: behavior
versions: Python 3.10, Python 3.9
___
Python tracker
<https://bugs.python.org/issue42944>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42944] random.Random.sample bug when counts is not None
Change by Jon FRANCO : -- keywords: +patch pull_requests: +23058 stage: -> patch review pull_request: https://github.com/python/cpython/pull/24235 ___ Python tracker <https://bugs.python.org/issue42944> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42944] random.Random.sample bug when counts is not None
Jon FRANCO added the comment: PR submitted. Let me know if I missed something, this is also my first PR. Regards. -- ___ Python tracker <https://bugs.python.org/issue42944> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13812] multiprocessing package doesn't flush stderr on child exception
New submission from Jon Brandvein :
When a child process exits due to an exception, a traceback is written, but
stderr is not flushed. Thus I see a header like "Process 1:\n", but no
traceback.
I don't have a development environment or any experience with Mecurial, so I'm
afraid there's no patch, but it's a one-liner.
In /Lib/multiprocess/process.py :: Process._bootstrap
except:
exitcode = 1
import traceback
sys.stderr.write('Process %s:\n' % self.name)
sys.stderr.flush()
traceback.print_exc()
Append a "sys.stderr.flush()" to the suite.
It surprised me that flushing was even necessary. I would've thought that the
standard streams would all be closed just before the process terminated,
regardless of exit status. But I observe that unless I explicitly flush stdout
and stderr before terminating, the output is lost entirely, even if the exit is
not abnormal. This isn't the desired behavior, is it?
--
components: Library (Lib)
messages: 151508
nosy: brandj
priority: normal
severity: normal
status: open
title: multiprocessing package doesn't flush stderr on child exception
type: behavior
versions: Python 3.2, Python 3.3, Python 3.4
___
Python tracker
<http://bugs.python.org/issue13812>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13812] multiprocessing package doesn't flush stderr on child exception
Jon Brandvein added the comment: (Er, that should be /Lib/multiprocessing/process.py :: Process._bootstrap of course.) -- ___ Python tracker <http://bugs.python.org/issue13812> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13812] multiprocessing package doesn't flush stderr on child exception
Jon Brandvein added the comment: On Windows, the problem appears under Python 3.2.2 and 3.1.3, but not under 2.7.1. On Linux, I have not reproduced the problem on versions 2.6.3, 2.7.2, 3.1.1, or 3.2.2. So to summarize: - It seems there should be a stderr flush call on the line I indicated, for symmetry with the surrounding code. - Even without this line, it should still be flushed automatically upon child process exit, but this doesn't happen under Windows and Python 3.x. -- ___ Python tracker <http://bugs.python.org/issue13812> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13812] multiprocessing package doesn't flush stderr on child exception
Jon Brandvein added the comment: I've been looking over this package some more, and in particular, /Lib/multiprocessing/forking.py. There's plenty I don't understand, and I do have questions, if you would be willing to indulge me. I see that both the unix and windows codepaths define an "exit" alias for terminating the child process without performing any cleanup. On unix, this is os._exit (though it calls it directly in Popen.__init__() instead of using the alias). On Windows, it is the win32 ExitProcess() function. A quick check confirms that replacing this windows alias with "exit = sys.exit" causes flushing to occur. So my main question is: What's wrong with using sys.exit()? I would speculate it's either because there's shared state between child and parent, or to avoid propagating SystemExit through user code in the case freeze_support() was used. If forking.py is to terminate directly via the OS, I think it's forking.py's responsibility to flush stdout and stderr in main() on the Windows side, the way it does in Popen.__init__() on the unix side. I also want to point out that the sys.exit() in freeze_support() is unreachable due to the exit() in main(). So it no longer surprises me that the output is not being flushed in Python 3 under windows. What surprises me is that it *is* flushed in Python 2. I remember hearing something about differences between 2 and 3 in how they handle buffering, so I'm investigating this for my own curiosity. Incidentally, Python 2 still flushes when I remove newlines from my output text, so line buffering doesn't seem to be impacting my observations. -- ___ Python tracker <http://bugs.python.org/issue13812> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13812] multiprocessing package doesn't flush stderr on child exception
Jon Brandvein added the comment: Some more information: When I write to a new file created by open(), all versions flush correctly. However, if I reassign sys.stdout to that file, Python 3.x does not (again, under Windows). I wonder what it is that causes these other files to flush. (Note: I am testing by calling time.sleep() and inspecting the output file during and after the pause.) -- ___ Python tracker <http://bugs.python.org/issue13812> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13812] multiprocessing package doesn't flush stderr on child exception
Jon Brandvein added the comment: It turns out the file output was flushing due to garbage collection. When I created and held a global reference to it, it ceased to flush. Clearly, reassigning sys.stdout also held a reference to it. So it wasn't any kind of special sys.stdout-specific logic. I tried using os.fsync to determine whether data was being saved in an OS-level buffer. But since the OS may be free to ignore fsync, it's kind of worthless for this purpose. I also found that under Python 2.x, even a low-level exit like os._exit or multiprocessing.win32.ExitProcess, called from within a user-level function in the child, caused flushing. My best guess is that 1. Python 2.x is not buffering data at the Python level. I can't see how it could be and still flush it out when calling _exit(). 2. Python 3.x is buffering at the Python level, and the Python File object needs to be destroyed or explicitly flushed before the hard low-level exit() in forking.py. The solutions I can think of for Python 3.x are: 1. Replace "exit = win32.ExitProcess" with "exit = sys.exit". All outstanding file objects will be destroyed and flushed naturally as the interpreter is torn down. 2. Add an explicit stdout/stderr flush where appropriate in forking.py and process.py, to ensure tracebacks get written and to match the unix behavior. Leave it to the user to worry about flushing their own streams. 3. Continue to use win32.ExitProcess, but add some kind of mechanism for walking through all existing Python File objects and flushing/destroying them. This was a fleeting thought; it really amounts to reimplementing the behavior of destructing the Python interpreter. I'd really like to hear if there are good reasons for why (1) isn't how it's done currently. I'd also like to hear an explanation of Python 2.x's buffering. -- ___ Python tracker <http://bugs.python.org/issue13812> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
