[ python-Bugs-1338264 ] Memory keeping
Bugs item #1338264, was opened at 2005-10-26 15:37 Message generated for change (Comment added) made by sin_avatar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1338264&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 Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: sin (sin_avatar) Assigned to: Nobody/Anonymous (nobody) Summary: Memory keeping Initial Comment: I execute this code on python 2.4.2 (authentic copy from console): Python 2.4.2 (#1, Oct 26 2005, 14:45:33) [GCC 2.95.4 20020320 [FreeBSD]] on freebsd4 Type "help", "copyright", "credits" or "license" for more information. >>> a = range(1,1000) >>> del a before i type del - i run top and get (see console output below): 16300 sin 2 0 162M 161M poll 0:02 35.76% 9.28% python2.4 after del (console below): 16300 sin 2 0 162M 161M poll 0:03 7.18% 6.05% python2.4 I tried gc too ... but python didn't free memory. I checked this on windows - memory was freed, but interpreter with 0 defined variables "eat" about 75 Mb!. I think this is bug in interpereter core. some text from dmesg for you: Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.8-RELEASE #0: Thu Apr 3 10:53:38 GMT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/ GENERIC Timecounter "i8254" frequency 1193182 Hz CPU: Pentium III/Pentium III Xeon/Celeron (499.15-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x673 Stepping = 3 Features=0x387f9ff real memory = 268369920 (262080K bytes) avail memory = 255901696 (249904K bytes) -- >Comment By: sin (sin_avatar) Date: 2005-10-31 14:06 Message: Logged In: YES user_id=1368129 One more time. >>> a = [1 for i in xrange(1000)] >>> del a This code clear - and this not raise "memory keeping"(!) >>> a = [i for i in xrange(1000)] >>> del a But this code take about 163 Mb on my freeBSD. I can't udestood why you don't care about this? P.S. somebody explain me phrase "a) not a bug (integer freelists)" -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-10-31 11:56 Message: Logged In: YES user_id=341410 Suggested close because and/or: a) not a bug (integer freelists) b) platform specific malloc/free behavior on the list->ob_item member (some platforms will drop to 121M allocated memory after the deletion) c) OP didn't listen when it was suggested they use xrange() instead of range() -- Comment By: sin (sin_avatar) Date: 2005-10-31 11:15 Message: Logged In: YES user_id=1368129 Certainly, i 'am not a C guru, but i uderstood - if interpreter keep more than 100Mb, and not keep useful information - it's suxx. Fore example if i use my script as a part Zope portal - it would be awful. Certainly my script was just example - but if i use mult-thread server wrote on python and create list in each thread - i would take memory from system and i cannot give it back. -- Comment By: Tim Peters (tim_one) Date: 2005-10-28 01:38 Message: Logged In: YES user_id=31435 Space for integer objects in particular lives in an immortal free list of unbounded size, so it's certain in the current implementation that doing range(1000) will hang on to space for 10 million integers forever. If you don't want that, don't do that ;-) Iterating over xrange(1000) instead will consume very little RAM. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-10-28 01:29 Message: Logged In: YES user_id=341410 >From what I understand, whether or not the Python runtime "frees" memory (which can be freed) is generally dependant on platform malloc() and free(). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1338264&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1343671 ] Broken docs for os.removedirs
Bugs item #1343671, was opened at 2005-10-31 12:30 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=1343671&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: None Status: Open Resolution: None Priority: 5 Submitted By: David Kågedal (d_kagedal) Assigned to: Nobody/Anonymous (nobody) Summary: Broken docs for os.removedirs Initial Comment: The documentation for the os.removedirs function is seriously broken. This is from the library reference: "removedirs(path) Removes directories recursively. Works like rmdir() except that, if the leaf directory is successfully removed, directories corresponding to rightmost path segments will be pruned way until either the whole path is consumed or an error is raised (which is ignored, because it generally means that a parent directory is not empty). Throws an error exception if the leaf directory could not be successfully removed. New in version 1.5.2." The first sentence is the only part that makes any sense. This shorter version contains as much information and less misinformation" "removedirs(path) Removes a directory and everything in it recursively. If a file couldn't be removed, the removal is aborted and you might get an exception if you're lucky." The doc string you get when you type "help(os.removedirs)" is different from the one in the library reference, but equally broken. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1343671&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-27 03:08
Message generated for change (Comment added) made by phd
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: None
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: Oleg Broytmann (phd)
Date: 2005-10-31 16: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 seconds, too little
for slow systems, too many for fast. .open() returns a
success/fail status (on systems where it is possible to
obtain one).
The framework still alows you to shoot yourself in the foot,
but you must do it explicitly. Either run
os.system("shotgun-browser &")
yourself or register your own ShotgunBrowser. Thus the new
framework is safe by default but still flexible.
--
Comment By: Greg Couch (gregcouch)
Date: 2005-10-28 22:49
Message:
Logged In: YES
user_id=131838
So you really want to change existing practice and break all
Python GUI programs that invoke webbrowser.open?
And the Elinks example proves my point. What is the point
of it being a UnixBrowser, in the terminal window, if you
can't send remote commands to it (because the Python GUI
application is blocked until the browser exits)? Tty-based
browsers are nice for completeness, but are really a last
resort for a Python application, and imply that no windowing
system is available (i.e, remotely logged in and not
forwarding X connections, so not running GUI applications
either).
--
Comment By: Oleg Broytmann (phd)
Date: 2005-10-28 15:56
Message:
Logged In: YES
user_id=4799
No, I still think it is a bad idea to put a generic Unix
browser to background by default. If you want to do it - do
it explicitly. Start a browser in a background yourself, and
use remote actions from the module to open new windows/tabs.
Or register another browser, with different .open() and/or
._remote().
And, BTW, Elinks is a subclass of UnixBrowser, not
GenericBrowser.
--
Comment By: Greg Couch (gregcouch)
Date: 2005-10-27 21:35
Message:
Logged In: YES
user_id=131838
And I don't want starting up firefox to hang my python GUI
either. So, if you look at the code more closely,
lynx/links/elinks subclass from GenericBrowser not
UnixBrowser, so adding the & to UnixBrowser is the correct
thing to do.
--
Comment By: Oleg Broytmann (phd)
Date: 2005-10-27 19:36
Message:
Logged In: YES
user_id=4799
Yes, _safequote() call seems like a bug. A leftover after
I've merged a half dozens of patches into this one. Should
be removed.
But there should certainly be no '&'. You certainly dont
want to start lynx/links/elinks in the background, do you?!
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1338995&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-417833 ] pydoc HTTP reload failure
Bugs item #417833, was opened at 2001-04-21 09:10 Message generated for change (Comment added) made by rturpin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=417833&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: Garth T Kidd (gtk) Assigned to: Ka-Ping Yee (ping) Summary: pydoc HTTP reload failure Initial Comment: pydoc, when run as a web server, can't cope with reloads of modules which use 'from Package import Module' syntax for imports. To reproduce: * extract the attached DemonstratePydocBug tarchive into your Python 2.1 directory * python -c Lib\pydoc.py -p 8192 * visit http://localhost:8192/DemonstratePydocBug.html The rest of the instructions are there. Demonstrated on Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32. Funnily enough, there's no problem with trying the following under Python interactively: Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> import DemonstratePydocBug.ReloadFails >>> import DemonstratePydocBug.ReloadFails >>> import DemonstratePydocBug.ReloadFails >>> import DemonstratePydocBug.ReloadFails Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> from DemonstratePydocBug import ReloadFails >>> from DemonstratePydocBug import ReloadFails >>> from DemonstratePydocBug import ReloadFails >>> from DemonstratePydocBug import ReloadFails I'm dropping additional debugging code into pydoc.py to see if I can figure out what's going on. -- Comment By: Russell Turpin (rturpin) Date: 2005-10-31 11:16 Message: Logged In: YES user_id=670280 There's a similar bug in Python 2.4. It causes the __import__ function to throw an AttributeError exception during safeimport(). I've patched our local copy of pydoc to fix this. The patch is to the safeimport() function. The patched lines are: # This keeps __import__ from throwing an exception on reloads. # del sys.modules[path] # This is sole original line module = sys.modules[path] # Added this line try: # Added this line reload(module) # Added this line except: # Added this line module = None# Added this line return module# Added this line This replaces the line: del sys.modules[path] -- Comment By: Eddie Parker (eparker) Date: 2004-08-31 16:41 Message: Logged In: YES user_id=991512 This is still current, as of 08/31/2004. Rather annoying, too. :( -- Comment By: Brett Cannon (bcannon) Date: 2003-05-16 18:43 Message: Logged In: YES user_id=357491 Just as an update, this still seeems to be an issue in Python 2.3b1 w/ version 1.82 of pydoc -- Comment By: Garth T Kidd (gtk) Date: 2001-04-21 11:15 Message: Logged In: YES user_id=59803 Using pydoc in the interpreter doesn't tickle any of these bugs, so hopefully I can narrow my focus down to the difference in handling between serve() and help(). Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> import pydoc >>> pydoc.help Welcome to Python 2.1! This is the online help utility. [...] help> modules Please wait a moment while I gather a list of all available modules... [list of modules] Enter any module name to get more help. Or, type "modules spam" to search for modules whose descriptions contain the word "spam". help> DemonstratePydocBug.ReloadFails Help on module DemonstratePydocBug.ReloadFails in DemonstratePydocBug: NAME DemonstratePydocBug.ReloadFails FILE c:\python21\lib\demonstratepydocbug\reloadfails.py [...] help> DemonstratePydocBug.TryThis Help on module DemonstratePydocBug.TryThis in DemonstratePydocBug: NAME DemonstratePydocBug.TryThis [...] -- Comment By: Garth T Kidd (gtk) Date: 2001-04-21 10:09 Message: Logged In: YES user_id=59803 Yet another demonstration case: DemonstratePydocBug/TryThis.py: import DemonstratePydocBug.Target Target = DemonstratePydocBug.Target This gives us a local Target variable, same as 'from DemonstratePydocBug import Target'. Pydoc barfs on this on the very first load. The traceback I hacked into pydoc claims: Traceback (most recent call last): File "C:\P
[ python-Bugs-1338264 ] Memory keeping
Bugs item #1338264, was opened at 2005-10-26 02:37 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1338264&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 Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: sin (sin_avatar) Assigned to: Nobody/Anonymous (nobody) Summary: Memory keeping Initial Comment: I execute this code on python 2.4.2 (authentic copy from console): Python 2.4.2 (#1, Oct 26 2005, 14:45:33) [GCC 2.95.4 20020320 [FreeBSD]] on freebsd4 Type "help", "copyright", "credits" or "license" for more information. >>> a = range(1,1000) >>> del a before i type del - i run top and get (see console output below): 16300 sin 2 0 162M 161M poll 0:02 35.76% 9.28% python2.4 after del (console below): 16300 sin 2 0 162M 161M poll 0:03 7.18% 6.05% python2.4 I tried gc too ... but python didn't free memory. I checked this on windows - memory was freed, but interpreter with 0 defined variables "eat" about 75 Mb!. I think this is bug in interpereter core. some text from dmesg for you: Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.8-RELEASE #0: Thu Apr 3 10:53:38 GMT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/ GENERIC Timecounter "i8254" frequency 1193182 Hz CPU: Pentium III/Pentium III Xeon/Celeron (499.15-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x673 Stepping = 3 Features=0x387f9ff real memory = 268369920 (262080K bytes) avail memory = 255901696 (249904K bytes) -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-10-31 11:11 Message: Logged In: YES user_id=341410 Integers are immutable. That is, each integer with a different value will be a different integer object (some integers with the same value will also be different objects). In CPython, id(obj) is the memory location of that object. >>> a = 9876 >>> id(a) 9121340 >>> a += 1 >>> id(a) 8738760 It is assumed by the CPython runtime, based on significant experience by CPython programmers, that if you are using a large number of integers now, that you are probably going to use a large number of integers in the future. When an integer object is allocated, the object hangs around for as long as it is needed, and when it is no longer needed, it is placed on a list of allocated integer objects which can be re-used, but which are never freed (the integer freelist). This allows Python to allocate blocks of integers at a time when necessary (which speeds up allocations), re-use unused integer objects (which removes additional allocations in the majority of cases), and removes the free() call (on many platforms, free() doesn't work). Integer freelists are not going away, and the behavior you are experiencing is a result of integer freelists (though the 163M rather than 123M memory used is a result of FreeBSD's memory manager not being perfect). As Tim Peters suggested, if you need to iterate through 10 million unique integers, do so via xrange, but don't save them all. If you can't think about how to do such a thing in your application, you can ask users on the comp.lang.python newsgroup, or via the [email protected] mailing list, but remember to include the code you are using now and a description of what you want it to do. -- Comment By: sin (sin_avatar) Date: 2005-10-31 01:06 Message: Logged In: YES user_id=1368129 One more time. >>> a = [1 for i in xrange(1000)] >>> del a This code clear - and this not raise "memory keeping"(!) >>> a = [i for i in xrange(1000)] >>> del a But this code take about 163 Mb on my freeBSD. I can't udestood why you don't care about this? P.S. somebody explain me phrase "a) not a bug (integer freelists)" -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-10-30 22:56 Message: Logged In: YES user_id=341410 Suggested close because and/or: a) not a bug (integer freelists) b) platform specific malloc/free behavior on the list->ob_item member (some platforms will drop to 121M allocated memory after the deletion) c) OP didn't listen when it was suggested they use xrange() instead of range() -- Comment By: sin (sin_avatar) Date: 2005-10-30 22:15 Message: Logged In: YES user_id=1368129 Certainly, i 'am not a C guru, but i uderstood - if interpreter keep more than 100Mb, and not keep useful infor
[ python-Bugs-1338264 ] Memory keeping
Bugs item #1338264, was opened at 2005-10-26 05:37 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1338264&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 Interpreter Core Group: Python 2.4 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: sin (sin_avatar) Assigned to: Nobody/Anonymous (nobody) Summary: Memory keeping Initial Comment: I execute this code on python 2.4.2 (authentic copy from console): Python 2.4.2 (#1, Oct 26 2005, 14:45:33) [GCC 2.95.4 20020320 [FreeBSD]] on freebsd4 Type "help", "copyright", "credits" or "license" for more information. >>> a = range(1,1000) >>> del a before i type del - i run top and get (see console output below): 16300 sin 2 0 162M 161M poll 0:02 35.76% 9.28% python2.4 after del (console below): 16300 sin 2 0 162M 161M poll 0:03 7.18% 6.05% python2.4 I tried gc too ... but python didn't free memory. I checked this on windows - memory was freed, but interpreter with 0 defined variables "eat" about 75 Mb!. I think this is bug in interpereter core. some text from dmesg for you: Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.8-RELEASE #0: Thu Apr 3 10:53:38 GMT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/ GENERIC Timecounter "i8254" frequency 1193182 Hz CPU: Pentium III/Pentium III Xeon/Celeron (499.15-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x673 Stepping = 3 Features=0x387f9ff real memory = 268369920 (262080K bytes) avail memory = 255901696 (249904K bytes) -- >Comment By: Tim Peters (tim_one) Date: 2005-10-31 15:00 Message: Logged In: YES user_id=31435 sin_avatar, it's the number of integer objects _simultaneously alive_ that matters, not the total number of integer objects ever created. Creating a list (or any other in-memory container) containing millions of integers can be a bad idea on many counts. I'm closing this as WontFix, as there are no plans to replace the integer freelist. I think it would be good if an upper bound were placed on its size (as most other internal freelists have), but that's trickier than it sounds and there are no plans to do that either. > I can't udestood why you don't care about this? It's a tradeoff: it's much easier to avoid in real life than it is to change the implementation in a way that would actually help (the int freelist is an important speed optimization for most integer-heavy apps). Changing your coding practices to live with this is your only realistic hope for relief. BTW, the idea that you might really need to create a list with 10 million integers in each thread of a threaded server is too bizarre to argue about ;-) -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-10-31 14:11 Message: Logged In: YES user_id=341410 Integers are immutable. That is, each integer with a different value will be a different integer object (some integers with the same value will also be different objects). In CPython, id(obj) is the memory location of that object. >>> a = 9876 >>> id(a) 9121340 >>> a += 1 >>> id(a) 8738760 It is assumed by the CPython runtime, based on significant experience by CPython programmers, that if you are using a large number of integers now, that you are probably going to use a large number of integers in the future. When an integer object is allocated, the object hangs around for as long as it is needed, and when it is no longer needed, it is placed on a list of allocated integer objects which can be re-used, but which are never freed (the integer freelist). This allows Python to allocate blocks of integers at a time when necessary (which speeds up allocations), re-use unused integer objects (which removes additional allocations in the majority of cases), and removes the free() call (on many platforms, free() doesn't work). Integer freelists are not going away, and the behavior you are experiencing is a result of integer freelists (though the 163M rather than 123M memory used is a result of FreeBSD's memory manager not being perfect). As Tim Peters suggested, if you need to iterate through 10 million unique integers, do so via xrange, but don't save them all. If you can't think about how to do such a thing in your application, you can ask users on the comp.lang.python newsgroup, or via the [email protected] mailing list, but remember to include the code you are using now and a description of what you want it to do. --
[ 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: None
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-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 seconds, too little
for slow systems, too many for fast. .open() returns a
success/fail status (on systems where it is possible to
obtain one).
The framework still alows you to shoot yourself in the foot,
but you must do it explicitly. Either run
os.system("shotgun-browser &")
yourself or register your own ShotgunBrowser. Thus the new
framework is safe by default but still flexible.
--
Comment By: Greg Couch (gregcouch)
Date: 2005-10-28 11:49
Message:
Logged In: YES
user_id=131838
So you really want to change existing practice and break all
Python GUI programs that invoke webbrowser.open?
And the Elinks example proves my point. What is the point
of it being a UnixBrowser, in the terminal window, if you
can't send remote commands to it (because the Python GUI
application is blocked until the browser exits)? Tty-based
browsers are nice for completeness, but are really a last
resort for a Python application, and imply that no windowing
system is available (i.e, remotely logged in and not
forwarding X connections, so not running GUI applications
either).
--
Comment By: Oleg Broytmann (phd)
Date: 2005-10-28 04:56
Message:
Logged In: YES
user_id=4799
No, I still think it is a bad idea to put a generic Unix
browser to background by default. If you want to do it - do
it explicitly. Start a browser in a background yourself, and
use remote actions from the module to open new windows/tabs.
Or register another browser, with different .open() and/or
[ python-Bugs-1344508 ] UNIX mmap leaks file descriptors
Bugs item #1344508, was opened at 2005-11-01 03:46 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=1344508&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.4 Status: Open Resolution: None Priority: 5 Submitted By: Erwin S. Andreasen (drylock) Assigned to: Nobody/Anonymous (nobody) Summary: UNIX mmap leaks file descriptors Initial Comment: The commit from 2.49 to 2.50 in Modules/mmapmodule.c has made mmap under UNIX leak a file descriptor: - m_obj->fd = fd; + m_obj->fd = dup(fd); The FD given is dup'ed in order to allow ftruncation later, but no close of it is done in dealloc/close. A test case attached, using lsof after some mmaps/unmaps to show leak. Version: Python 2.4.2 (#2, Sep 29 2005, 00:23:59) [GCC 4.0.2 (Debian 4.0.1-9)] on linux2 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1344508&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
