[issue6671] webbrowser.py doesn't respect xfce default browser
New submission from Aliaksandr Stelmachonak mail.ava...@gmail.com: Currently webbrowser.py only trying to use GNOME and KDE default browser setting. This patch adds launching Xfce default browser if xfce environment detected. -- components: Library (Lib) files: webbrowser.py.patch keywords: patch messages: 91426 nosy: ava1ar severity: normal status: open title: webbrowser.py doesn't respect xfce default browser type: behavior versions: Python 2.6 Added file: http://bugs.python.org/file14678/webbrowser.py.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6671 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6663] re.findall does not always return a list of strings
Changes by Antoine Pitrou pit...@free.fr: -- resolution: - invalid status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6663 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6672] Add Mingw recognition to pyport.h to allow building extensions
New submission from Jan Schlüter python-b...@jan-schlueter.de: This addresses missing statements for recognizing the Mingw compiler in pyport.h, needed to build several extension modules on Windows using Mingw. I will first explain the background, then indicate what needs to be changed and end with some pointers to related work. Pyport.h of Python 2.5 and 2.6 (I do not have other versions to check) addresses an issue with Cygwin's gcc by preventing the declaration of __declspec(dllimport) for function definitions (using the PyAPI_FUNC (RTYPE) makro), relying on the compiler's auto-import definition instead, because the compiler would not otherwise throw an initializer element is not constant error when using e.g. PyObject_GenericGetAttr in a PyTypeObject declaration of a C/C++ extension module (more generally, whenever an imported Python API function is used as a constant). Python 2.6.2 (r262:71605) and Python 2.5.4 (r254:67916) do not check for the Mingw compiler in pyport.h, although Mingw behaves the same as the Cygwin version, at least regarding the __declspec declaration. To fix that, each check for __CYGWIN__ in pyport.h should also check for __MINGW32___ to behave the same way. svn.python.org currently does not reply, so I can not create a patch against the trunk nor check whether this issue has already been addressed. Issue 5046 included a patch to pyport.h fixing this, but it has been rejected due to other suggested changes that were not mature. http://recipes.gobolinux.org/r/?list=Pythonver=3.1- r1file=arm/20061116160247- bf48b-7db78fe2f80b3137ce349cf4314364768555ff50.gz.diff suggests the same change. http://www.indashpc.org/vbullettin/viewtopic.php?p=5003#5003 gives some more background information on how I found and fixed the problem. An internet search for python initializer element is not constant shows that numerous people have been encountering this problem when trying to build a python extension module. -- components: Build messages: 91427 nosy: f0k severity: normal status: open title: Add Mingw recognition to pyport.h to allow building extensions versions: Python 2.5, Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6672 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6673] Py3.1 hangs in coroutine and eats up all memory
New submission from Stefan Behnel sco...@users.sourceforge.net: Here's a simple coroutine that works perfectly in Python 2.6 but seems to let Py3.1 enter an infinite loop that ends up eating all memory. - def printing_sink(): A simple sink that prints the received values. while True: print( (yield) ) def chunker(chunk_size, target): Receives single items and forwards chunks of a fixed size. Usage example: sink = printing_sink() next(sink) cr = chunker(4, sink) next(cr) for i in range(8): ...cr.send(i) [0, 1, 2, 3] [4, 5, 6, 7] cr.close() while True: target.send([ (yield) for i in range(chunk_size) ]) if __name__ == '__main__': import doctest doctest.testmod() - Fails on: Python 3.1 (r31:73572, Jun 28 2009, 21:07:35) [GCC 4.3.2] on linux2 Works on: Python 2.6.2 (r262:71600, Apr 17 2009, 11:29:30) [GCC 4.3.2] on linux2 The problem seems to be the list comprehension. When I replace it with a normal for-loop, it works perfectly. -- components: Interpreter Core messages: 91428 nosy: scoder severity: normal status: open title: Py3.1 hangs in coroutine and eats up all memory type: crash versions: Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6673 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2637] urllib.quote() escapes characters unnecessarily and contrary to docs
Nir Soffer nir...@gmail.com added the comment: Senthil said: The way to handle this issue would be add these characters '%/:=?~#+!$,;'@()*[]' to always_safe list. This is wrong - for example, '=?' are NOT safe when quoting parameters for query string. This will break exiting code that assume the default safe parameters. Other characters may be unsafe in other parts of the url - I did not check which - and I don't have time to check. The current default (safe='/') is the best option - it will work correctly in most case, and in the worst is escaping some characters which are safe in particular use case. Since only the user know the context, the user should add safe characters to the function. If you don't specify anything, the function should be safe as possible for the worst use case. If you want to add characters to the default safe list, you have to make sure that the function will not break for common use cases. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2637 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2637] urllib.quote() escapes characters unnecessarily and contrary to docs
Nir Soffer nir...@gmail.com added the comment: Here is one example of code that would break if the safe parameter is changed in a careless way mentioned here (look for url_encode): http://dev.pocoo.org/projects/werkzeug/browser/werkzeug/urls.py#L112 I'm sure we can find similar code in every web application. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2637 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2637] urllib.quote() escapes characters unnecessarily and contrary to docs
Senthil orsent...@gmail.com added the comment: On Sun, Aug 09, 2009 at 03:40:47PM +, Nir Soffer wrote: for query string. This will break exiting code that assume the default safe parameters. Other characters may be unsafe in other parts of the url - I did not I agree with your comments and I had similar thoughts too. The RFC spec says that different components in URL have have different characters that needs to be quoted. The quote function is documented that it is *intended for path component* and Python Documention provides a usage overview of quote assuming that the developer will know what he/she is doing. It does not deal with the specifics of quote w.r.t to URL components. My comment was biased from the changes made to urllib.urlopen function where we explicitly passed on reserved characters to the safe parameter of quote and we got expected results. this change has been there for few months now without any breakage reports. And that change was not according to any RFC but more based on the practical issues encountered. Yes, I agree that changes to quote function is bound to break the code which relied on the earlier behaviour. I see at least 3 tests in stdlib breaking, which can be modified without any loss in meaning, if we want go with the change. But, I feel it is okay to heed to your objection and leave the function as it is. The need to change it does not have a strong backing in RFC. It is a not a bug, considering the documentation. Only thing to live with will be urlopen's passing of safe characters. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2637 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6673] Py3.1 hangs in coroutine and eats up all memory
Georg Brandl ge...@python.org added the comment: Try list(genexp) instead of [listcomp] in 2.x and see what happens... -- nosy: +georg.brandl ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6673 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6126] Python 3 pdb: shows internal code, breakpoints don't work
Alex Grönholm alex.gronholm+pyt...@nextday.fi added the comment: Why has this not been resolved yet? Not having a working debugger is a severe hindrance to the acceptance of Py3k. -- nosy: +agronholm ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6126 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6126] Python 3 pdb: shows internal code, breakpoints don't work
Georg Brandl ge...@python.org added the comment: Attached patch confirmedly fixes this. Will commit as soon as svn is back up. -- assignee: - georg.brandl keywords: +patch nosy: +georg.brandl Added file: http://bugs.python.org/file14679/pdb-fix.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6126 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6673] Py3.1 hangs in coroutine and eats up all memory
Stefan Behnel sco...@users.sourceforge.net added the comment: Hmm, ok, so this is actually an anticipated bug? And I assume this has been discussed before and was decided to get solved by doing... what? Is it documented somewhere why this happens and what one must avoid to not run into this kind of pitfall? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6673 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6673] Py3.1 hangs in coroutine and eats up all memory
Georg Brandl ge...@python.org added the comment: No idea, actually. I just wanted to point out that it is nothing specific to Python 3. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6673 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
