[ python-Bugs-1256669 ] Significant memory leak with PyImport_ReloadModule
Bugs item #1256669, was opened at 2005-08-11 14:49 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1256669&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: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ben Held (bheld) Assigned to: Nobody/Anonymous (nobody) Summary: Significant memory leak with PyImport_ReloadModule Initial Comment: Having recently upgraded to Python 2.4, I am having a large memory leak with the following code built with VC++ 6.0: PyObject *pName, *pModule; Py_Initialize(); pName = PyString_FromString(argv[1]); pModule = PyImport_Import(pName); Py_DECREF(pName); PyObject* pModule2 = PyImport_ReloadModule(pModule); Py_DECREF(pModule2); Py_DECREF(pModule); Py_Finalize(); return 0; I get leaks of over 500 kb. I have another program which is much more complex, in which every call to PyImport_ReloadModule is leaking 200+ kb, even though I am calling Py_DECREF correctly. -- >Comment By: Martin v. Löwis (loewis) Date: 2005-08-13 15:34 Message: Logged In: YES user_id=21627 How do you know there is a memory leak? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1256669&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1257687 ] Solaris 8 declares gethostname().
Bugs item #1257687, was opened at 2005-08-12 17:00 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1257687&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: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Hans Deragon (deragon) Assigned to: Nobody/Anonymous (nobody) Summary: Solaris 8 declares gethostname(). Initial Comment: In portpy.h line 377, we find: #ifdef SOLARIS /* Unchecked */ extern int gethostname(char *, int); #endif Well, on Solaris 8, that function is declared in /usr/include/unistd.h, thus a conflict. In unistd.h, there are a few #ifdef prior the declaration, so there might be some situation where the function is not declared. Of course, I cannot copy and paste the relevant section of unistd.h because of copyright. You might want to ask Sun Microsystem a copy of this file to patch this problem. My work around was to comment the above code in portpy.h. -- >Comment By: Martin v. Löwis (loewis) Date: 2005-08-13 16:05 Message: Logged In: YES user_id=21627 What precise problem does this cause? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1257687&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1258485 ] http auth documentation/implementation conflict
Bugs item #1258485, was opened at 2005-08-13 18:49 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=1258485&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: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: http auth documentation/implementation conflict Initial Comment: [forwarded from http://bugs.debian.org/304925] Bug reporter writes: I was trying to implement a basic HTTP client using HTTP basic authorization. The current preferred method of doing this is by using urllib2 HTTPPasswordMgr. A simple test snippet to try this: pwmgr=urllib2.HTTPPasswordMgrWithDefaultRealm() pwmgr.add_password(None, url, username, password) handler=urllib2.HTTPBasicAuthHandler(pwmgr) opener=urllib2.build_opener(handler) urllib2.install_opener(opener) u=urllib2.urlopen(url) This did not work. Modifying the second line to: pwmgr.add_password(None, urlparse.urlparse(url)[1], username, password) fixed things, which shows a problem in the documentation: instead of a URI or sequence of URIs the add_password method takes a hostname. The documented behaviour would be better since it allows for multiple passwords per host, although in reality those will use different realms. So I suggest not changing the code in order to not break existing application but fixing the documentation instead. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1258485&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1124861 ] GetStdHandle in interactive GUI
Bugs item #1124861, was opened at 2005-02-17 09:23
Message generated for change (Comment added) made by bediviere
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124861&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: Windows
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: davids (davidschein)
Assigned to: Nobody/Anonymous (nobody)
Summary: GetStdHandle in interactive GUI
Initial Comment:
Using the suprocess module from with IDLE or PyWindows,
it appears that calls GetStdHandle (STD__HANDLE)
returns None, which causes an error. (All appears fine
on Linux, the standard Python command-line, and ipython.)
For example:
>>> import subprocess
>>> p = subprocess.Popen("dir", stdout=subprocess.PIPE)
Traceback (most recent call last):
File "", line 1, in -toplevel-
p = subprocess.Popen("dir", stdout=subprocess.PIPE)
File "C:\Python24\lib\subprocess.py", line 545, in
__init__
(p2cread, p2cwrite,
File "C:\Python24\lib\subprocess.py", line 605, in
_get_handles
p2cread = self._make_inheritable(p2cread)
File "C:\Python24\lib\subprocess.py", line 646, in
_make_inheritable
DUPLICATE_SAME_ACCESS)
TypeError: an integer is required
The error originates in the mswindows implementation of
_get_handles. You need to set one of stdin, stdout, or
strerr because the first line in the method is:
if stdin == None and stdout == None and stderr == None:
...return (None, None, None, None, None, None)
I added "if not handle: return GetCurrentProcess()" to
_make_inheritable() as below and it worked. Of course,
I really do not know what is going on, so I am letting
go now...
def _make_inheritable(self, handle):
..."""Return a duplicate of handle, which is inheritable"""
...if not handle: return GetCurrentProcess()
...return DuplicateHandle(GetCurrentProcess(), handle,
GetCurrentProcess(),
0, 1,
DUPLICATE_SAME_ACCESS)
--
Comment By: Steven Bethard (bediviere)
Date: 2005-08-13 14:37
Message:
Logged In: YES
user_id=945502
I ran into a similar problem in Ellogon (www.ellogon.org)
which interfaces with Python through tclpython
(http://jfontain.free.fr/tclpython.htm).
My current workaround is to always set all of stdin, stdout,
and stderr to subprocess.PIPE. I never use the stderr pipe,
but at least this keeps the broken GetStdHandle calls from
happening.
Looking at the code, I kinda think the fix should be::
if handle is None:
return handle
return DuplicateHandle(GetCurrentProcess(), ...
where if handle is None, it stays None. But I'm also
probably in over my head here.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124861&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1100368 ] Wrong "type()" syntax in docs
Bugs item #1100368, was opened at 2005-01-11 12:03
Message generated for change (Comment added) made by bediviere
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1100368&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: Open
Resolution: None
Priority: 5
Submitted By: Facundo Batista (facundobatista)
Assigned to: Raymond Hettinger (rhettinger)
Summary: Wrong "type()" syntax in docs
Initial Comment:
>From the current docs:
type(object):
Return the type of an object. The return value
is a type object.
>From the interpreter:
>>> help(type)
Help on class type in module __builtin__:
class type(object)
| type(object) -> the object's type
| type(name, bases, dict) -> a new type
In the documentation is missing the second syntax form.
--
Comment By: Steven Bethard (bediviere)
Date: 2005-08-13 17:32
Message:
Logged In: YES
user_id=945502
I was going to file this as a new bug report, but I changed
my mind and decided to post it as a followup to this bug
instead. It's basically a first draft at some documentation
for the behavior of the type type.
--
The type object documentation is limited and hard to find.
The call type(obj) is defined in
http://docs.python.org/lib/built-in-funcs.html and the call
type(name, bases, dict) is briefly mentioned in
http://docs.python.org/ref/metaclasses.html. Confusingly,
the section on Type Objects
(http://www.python.org/dev/doc/devel/lib/bltin-type-objects.html)
is not about the type object at all; it's about *instances*
of type, e.g. int or str.
I'd like to add a section on the type object itself,
something like:
"""
type(name, bases, dict)
Return a new type object. This is essentially a
functional form of the class statement: the "name" string is
the class name and becomes the __name__ attribute, the
"bases" tuple is the class bases and becomes the __bases__
attribute, the "dict" dict is the namespace defined by the
class body, and becomes the __dict__ attribute. For
example, the following two statements create identical
"type" objects:
>>> class X(object):
... a = 1
...
>>> X = type('X', (object,), dict(a=1))
Just like type objects created by class statements, type
objects created by type() are callable, and when called
create new instances of their type. The __call__() method
of type objects accepts any number of positional and keyword
arguments, and passes these to the type object's __new__()
method to create a new instance. If __new__() returns an
instance of the same type, that instance's __init__() method
is then called with the same arguments. In either case, the
__call__() method then returns the new instance.
"""
I don't know where this should go, but I'd certainly like to
see something like this put in, and linked under the type()
function, the Type Objects section and the Customizing class
creation (metaclasses) section.
--
Comment By: Michael Chermside (mcherm)
Date: 2005-01-25 14:31
Message:
Logged In: YES
user_id=99874
cjwhrh's comment doesn't seem relevent. It is generally true
of ALL builtins that they can be shadowed by local variables.
Facundo is probably right that the newer use of type() should
be documented.
--
Comment By: Colin J. Williams (cjwhrh)
Date: 2005-01-18 15:03
Message:
Logged In: YES
user_id=285587
The accuracy of the above depends partly on the context.
Within a function or method which has "type" as a parameter
the type function described above is no longer accessible.
Colin W.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1100368&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
