[ python-Bugs-1368481 ] python.dir still refers to python-whatsnew23
Bugs item #1368481, was opened at 2005-11-28 19:33 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1368481&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Bernhard Herzog (bernhard) Assigned to: Nobody/Anonymous (nobody) Summary: python.dir still refers to python-whatsnew23 Initial Comment: In the tarball with the GNU info version of the documentation, the file python.dir still refers to a node python-whatsnew23 which doesn't exist. It should be python-whatsnew24. This bug is also present in SVN in both release24-maint branch and trunk. -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-02 14:43 Message: Logged In: YES user_id=1188172 Thanks for the report, fixed in rev. 41579, 41580(2.4). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1368481&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1371826 ] distutils is silent about multiple -I/-L/-R
Bugs item #1371826, was opened at 2005-12-02 10:20 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1371826&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: distutils is silent about multiple -I/-L/-R Initial Comment: GCC (actually, most compilers I think) allows you to specify -L, -I and -R multiple times. In contrast, distutils expects on of them with a colon-separated list of directories. It only pays attention to the last one of any of those three flags. I've been bitten by this difference a couple times in recent weeks. It seems that distutils should warn when any of these flags are given multiple times or (better yet) should conform more to common compiler usage and allow them to be given multiple times, collecting all values together in a list. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1371826&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1370197 ] memory leak - ast_error_finish
Bugs item #1370197, was opened at 2005-11-30 11:41
Message generated for change (Comment added) made by jimjjewett
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1370197&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: AST
Status: Open
Resolution: None
Priority: 5
Submitted By: Jim Jewett (jimjjewett)
Assigned to: Nobody/Anonymous (nobody)
Summary: memory leak - ast_error_finish
Initial Comment:
http://svn.python.org/view/python/trunk/Python/ast.c?
rev=41486&view=markup
function ast_error_finish
It first gets the errstr, for a possible early out.
If there is an error string, it is increfed, but it is
not decrefed on the other early outs. (lineno==-1 and
failure to build a tmp.
"""
Py_INCREF(errstr);
lineno = PyInt_AsLong(PyTuple_GetItem(value, 1));
if (lineno == -1)
return;
Py_DECREF(value);
loc = PyErr_ProgramText(filename, lineno);
if (!loc) {
Py_INCREF(Py_None);
loc = Py_None;
}
tmp = Py_BuildValue("(ziOO)", filename, lineno,
Py_None, loc);
Py_DECREF(loc);
if (!tmp)
return;
value = Py_BuildValue("(OO)", errstr, tmp);
Py_DECREF(errstr);
"""
--
>Comment By: Jim Jewett (jimjjewett)
Date: 2005-12-02 14:14
Message:
Logged In: YES
user_id=764593
No, though it took me a *long* time to see why, because the
&value pointer is reused.
As best I understand it, PyErr_Fetch may leave (the initial
value of) value with the only reference to errstr.
There is a Py_DECREF(value) after successfully retrieving a
line number, but before using errstr to build the (new value
of) value for PyErr_Restore.
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2005-12-02 00:22
Message:
Logged In: YES
user_id=33168
ISTM that we don't need the INCREF or DECREF for errstr. Do
you agree?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1370197&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1371937 ] minidom namespace problems
Bugs item #1371937, was opened at 2005-12-02 14:47 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1371937&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: A.M. Kuchling (akuchling) Assigned to: Nobody/Anonymous (nobody) Summary: minidom namespace problems Initial Comment: Noted on c.l.py: the minidom writexml() function doesn't tidy up namespace declarations, so you can output documents that have incorrect namespace declarations. DOM Level 3, appendix B, specifies an algorithm for normalizing namespaces; see http://www.w3.org/TR/DOM-Level-3-Core/namespaces-algorithms.html . minidom probably needs to acquire the normalizeNamespace method, and then writexml() can call it before doing its work. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1371937&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1352621 ] SVN webbrowser.py fix 41419 didn't
Bugs item #1352621, was opened at 2005-11-09 14:26 Message generated for change (Comment added) made by gregcouch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1352621&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Greg Couch (gregcouch) Assigned to: Nobody/Anonymous (nobody) Summary: SVN webbrowser.py fix 41419 didn't Initial Comment: The new fix of setting remote_background to True and adding an & in the "simplier command" case can't work. If remote_background is True, then the first os.system call will always succeed and thus the second one will never be called. So if the web browser isn't already running, it will never start up. As I alluded to in my previous bug submission 1338995, the real fix will involve using the subprocess module -- I will try to find some time to develop and test a patch and submit it. -- >Comment By: Greg Couch (gregcouch) Date: 2005-12-02 18:08 Message: Logged In: YES user_id=131838 See bug #1338995 and patch #1372125 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1352621&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1338995 ] CVS webbrowser.py (1.40) bugs
Bugs item #1338995, was opened at 2005-10-26 16:08
Message generated for change (Comment added) made by gregcouch
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1338995&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Couch (gregcouch)
Assigned to: Nobody/Anonymous (nobody)
Summary: CVS webbrowser.py (1.40) bugs
Initial Comment:
There are two calls to _safequote that are only made on
darwin, aka, Mac OS X. That function is missing.
And the UnixBrowser is missing an & in the "simpler
command" and thus causes python to hang until the
browser is exited (if it wasn't running already).
--
>Comment By: Greg Couch (gregcouch)
Date: 2005-12-02 18:12
Message:
Logged In: YES
user_id=131838
See bug #135261 and patch #1372125. The patch contains
changes to use subprocess.Popen instead of os.system for the
UnixBrowser and fixes my problems with webbrowser.py and
should address Oleg Broytmann concerns as well.
--
Comment By: Oleg Broytmann (phd)
Date: 2005-11-18 12:36
Message:
Logged In: YES
user_id=4799
So it seems the new webbrowser.py is too new. May I suggest
to rename the new module and doc to webbrowser2.py, and
restore the old version of the module and the doc?
--
Comment By: Skip Montanaro (montanaro)
Date: 2005-11-14 20:08
Message:
Logged In: YES
user_id=44345
(Reopening. The webbrowser module still appears broken to me.)
I'm new to this thread, but webbrowser.open() in current SVN
(revision 41445) seems broken to me. This simple statement:
webbrowser.open("somefile.html")
returns True but fails to open the page in my currently running
instance of Safari. Dropping back to Python 2.4.1, it works fine.
I know webbrowser was a huge hack, but at least it appeared to do
basic stuff fine. It would appear that's no longer the case.
--
Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-11-09 13:43
Message:
Logged In: YES
user_id=1188172
Fixed in Revision 41419.
--
Comment By: Greg Couch (gregcouch)
Date: 2005-10-31 14:01
Message:
Logged In: YES
user_id=131838
Breaking applications that use webbrowser does not help
application writers. It would be much more useful to me, as
an application writer, if the webbrowser module gave an
error saying it couldn't contact a web browser, rather than
the new behavior of hanging my application. You have yet to
address this common use case.
Running the webbrowser in the background is a contract that
the webbrowser module can't break and still be called the
webbrowser module. I agree that the 2.4.2 version is a
practical hack that should be fixed, but the CVS webbrower
almost fixes it while breaking existing applications. Since
adding an & is so bad (the web browser is already confirmed
to exist and to be executable), the CVS webbrower could be
changed to use the subprocess module instead of os.system,
and the original webbrowser contract could be preserved.
The wrong display or wrong xhost/xauth permissions are not a
problem because the python GUI application that calls
webbrowser would have failed to start up in the first place
if those problems existed. Starting the web browser in the
background only needs to confirm that the web browser
actually started up.
--
Comment By: Oleg Broytmann (phd)
Date: 2005-10-31 05:11
Message:
Logged In: YES
user_id=4799
Yes, I want.
Current practice of running a browser in the background by
default is deadly broken. The old code of webbrowser.py is
full of dirty hacks. Look at Netscape._remote(). It tries to
start a browser to send a remote command; if that fails it
tries to start the browser in the background, waits an
arbitrary number of seconds (why this? why not less? why not
more?) and without testing if the browser in the background
was started it retries sending the remote command. You can
never know if the browser was started and if the command was
sent becuase .open() does not return a result code.
At the global level the bug is that webbrowser.py doesn't
tri all browsers in the tryorder - it only concentrates on
the first it found in PATH. What if the brwoser cannot be
started (damaged disk image; wrong DISAPLY; wrong
xhost/xauth permissions)?
My patched webbrowser.py is much safer. It runs all browsers
in the tryorder until it finds one that can be started. One
doesn't need to wait a random number of sec
