[ python-Bugs-1517996 ] IDLE (macosx): Class and Path browsers show Tk menu
Bugs item #1517996, was opened at 2006-07-06 10:34
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1517996&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: IDLE
Group: Python 2.5
Status: Open
Resolution: None
>Priority: 4
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Ronald Oussoren (ronaldoussoren)
Summary: IDLE (macosx): Class and Path browsers show Tk menu
Initial Comment:
I've done some work on fixing the menus for IDLE before 2.5b1, but
recently found more toplevel windows that don't have their own menu.
Both the Path Browser and Class Browser don't have a menubar of their
own. The Tk implementation on MacOSX won't accept an empty menubar,
but will replace that by a generic Tk menubar.
--
>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-23 09:26
Message:
Logged In: YES
user_id=580910
Yes I mean AquaTk. The debugger has the same problem (as expected because
it doesn't define its own menu)
The behaviour of AquaTk is a feature, not a bug. Appearently the default menu
is inheritted from the root ("."). I'll see if I can override that menu in
macosxSupport.setupApp.
--
Comment By: Kurt B. Kaiser (kbk)
Date: 2006-07-22 23:23
Message:
Logged In: YES
user_id=149084
> Tk uses the per-window menu for the currently
> selected window
I assume you mean AquaTk uses the per-window...
Please put in a bug request on AquaTk to get it
to conform to how Tk handles this menu on Linux
and Windows. Then downgrade the priority of this
bug or close it.
Does the debugger have the same problem?
--
Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-18 14:20
Message:
Logged In: YES
user_id=580910
These menu problems are at the very root caused by differences in the way
menus work on OSX (one application wide menu at the top of the screen) and
most other systems (optional menus for every window). Applications on OSX
must have some kind of menu (or be full-screen, but we don't want that for
IDLE), Tk uses the per-window menu for the currently selected window for
that. If a window doesn't have a menu it makes up one and I haven't found a
way yet to override that menu (which would solve that problem once and for
all).
I do believe that my other changes really are good, they make IDLE perform
more like a true OSX application. This is important because IDLE is the default
IDE, and hence probably the first thing naive OSX users will see of python.
BTW. AquaTk really sucks, which makes it annoyingly hard to create a really
good OSX citizen of IDLE and I have given up on getting there. If I understand
the lazyweb correctly you're supposed to port your appliations to some other
GUI library (Tile?) to get a native L&F for lots of widgets and standard
dialogs.
--
Comment By: Kurt B. Kaiser (kbk)
Date: 2006-07-15 21:51
Message:
Logged In: YES
user_id=149084
I suppose this is also true for the debugger?
I'd consider this a bug in OSX Tk, it should be
reported there.
Without a specific need for a menubar, all it does
is take up valuable vertical space. And continuing
to add OSX special casing clutters up the IDLE code;
IMO it should be limited to situations where
functionality is compromised.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1517996&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1525447 ] Build fails on OS X with case sensitive fs
Bugs item #1525447, was opened at 2006-07-19 19:24
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1525447&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.5
Status: Open
Resolution: None
Priority: 6
Submitted By: gideon may (gdm)
>Assigned to: Ronald Oussoren (ronaldoussoren)
Summary: Build fails on OS X with case sensitive fs
Initial Comment:
When compiling python from svn on a Mac OS X with a
case sensitive file system I get the following build
error:
running build
running build_ext
db.h: found (4, 3) in /opt/local/include/db4
db lib: using (4, 3) db-4.3
sqlite: found /usr/include/sqlite3.h
/usr/include/sqlite3.h: version 3.1.3
Traceback (most recent call last):
File "./setup.py", line 1507, in
main()
.
.
File "./setup.py", line 1088, in addMacExtension
raise RuntimeError("%s not found" % name)
RuntimeError: MacOS not found
make: *** [sharedmods] Error 1
It can be fixed by either renaming the file:
Mac/Modules/macosmodule.c
to
Mac/Modules/MacOSmodule.c
or applying the following patch :
Index: setup.py
===
--- setup.py(revision 50687)
+++ setup.py(working copy)
@@ -1101,7 +1101,7 @@
carbon_kwds = {'extra_compile_args':
carbon_extra_compile_args,
'extra_link_args':
['-framework', 'Carbon'],
}
-CARBON_EXTS = ['ColorPicker', 'gestalt',
'MacOS', 'Nav',
+CARBON_EXTS = ['ColorPicker', 'gestalt',
'macos', 'Nav',
'OSATerminology', 'icglue',
# All these are in subdirs
'_AE', '_AH', '_App',
'_CarbonEvt', '_Cm', '_Ctl',
Cheers,
Gideon
--
>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-23 11:31
Message:
Logged In: YES
user_id=580910
The patch is incorrect, as this would rename user visible name of the python
extension ('import MacOS' would stop working).
The rename would be correct.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1525447&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1517996 ] IDLE (macosx): Class and Path browsers show Tk menu
Bugs item #1517996, was opened at 2006-07-06 10:34
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1517996&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: IDLE
Group: Python 2.5
Status: Open
Resolution: None
Priority: 4
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Ronald Oussoren (ronaldoussoren)
Summary: IDLE (macosx): Class and Path browsers show Tk menu
Initial Comment:
I've done some work on fixing the menus for IDLE before 2.5b1, but
recently found more toplevel windows that don't have their own menu.
Both the Path Browser and Class Browser don't have a menubar of their
own. The Tk implementation on MacOSX won't accept an empty menubar,
but will replace that by a generic Tk menubar.
--
>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-23 11:35
Message:
Logged In: YES
user_id=580910
Changing the default root menu is indeed possible without changes outside
macosxSupport.py. I'm going to apply the attached patch later today.
Annoyingly enough AquaTk still adds an (empty) Help menu to our menubar. It
would be nice to fill that menu, but that would IMHO add to much code. I'm
happy enough to blame that glitch on AquaTk.
--
Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-23 09:26
Message:
Logged In: YES
user_id=580910
Yes I mean AquaTk. The debugger has the same problem (as expected because
it doesn't define its own menu)
The behaviour of AquaTk is a feature, not a bug. Appearently the default menu
is inheritted from the root ("."). I'll see if I can override that menu in
macosxSupport.setupApp.
--
Comment By: Kurt B. Kaiser (kbk)
Date: 2006-07-22 23:23
Message:
Logged In: YES
user_id=149084
> Tk uses the per-window menu for the currently
> selected window
I assume you mean AquaTk uses the per-window...
Please put in a bug request on AquaTk to get it
to conform to how Tk handles this menu on Linux
and Windows. Then downgrade the priority of this
bug or close it.
Does the debugger have the same problem?
--
Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-18 14:20
Message:
Logged In: YES
user_id=580910
These menu problems are at the very root caused by differences in the way
menus work on OSX (one application wide menu at the top of the screen) and
most other systems (optional menus for every window). Applications on OSX
must have some kind of menu (or be full-screen, but we don't want that for
IDLE), Tk uses the per-window menu for the currently selected window for
that. If a window doesn't have a menu it makes up one and I haven't found a
way yet to override that menu (which would solve that problem once and for
all).
I do believe that my other changes really are good, they make IDLE perform
more like a true OSX application. This is important because IDLE is the default
IDE, and hence probably the first thing naive OSX users will see of python.
BTW. AquaTk really sucks, which makes it annoyingly hard to create a really
good OSX citizen of IDLE and I have given up on getting there. If I understand
the lazyweb correctly you're supposed to port your appliations to some other
GUI library (Tile?) to get a native L&F for lots of widgets and standard
dialogs.
--
Comment By: Kurt B. Kaiser (kbk)
Date: 2006-07-15 21:51
Message:
Logged In: YES
user_id=149084
I suppose this is also true for the debugger?
I'd consider this a bug in OSX Tk, it should be
reported there.
Without a specific need for a menubar, all it does
is take up valuable vertical space. And continuing
to add OSX special casing clutters up the IDLE code;
IMO it should be limited to situations where
functionality is compromised.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1517996&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1517996 ] IDLE (macosx): Class and Path browsers show Tk menu
Bugs item #1517996, was opened at 2006-07-06 10:34
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1517996&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: IDLE
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 4
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Ronald Oussoren (ronaldoussoren)
Summary: IDLE (macosx): Class and Path browsers show Tk menu
Initial Comment:
I've done some work on fixing the menus for IDLE before 2.5b1, but
recently found more toplevel windows that don't have their own menu.
Both the Path Browser and Class Browser don't have a menubar of their
own. The Tk implementation on MacOSX won't accept an empty menubar,
but will replace that by a generic Tk menubar.
--
>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-23 11:46
Message:
Logged In: YES
user_id=580910
Applied in revision 50785
--
Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-23 11:35
Message:
Logged In: YES
user_id=580910
Changing the default root menu is indeed possible without changes outside
macosxSupport.py. I'm going to apply the attached patch later today.
Annoyingly enough AquaTk still adds an (empty) Help menu to our menubar. It
would be nice to fill that menu, but that would IMHO add to much code. I'm
happy enough to blame that glitch on AquaTk.
--
Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-23 09:26
Message:
Logged In: YES
user_id=580910
Yes I mean AquaTk. The debugger has the same problem (as expected because
it doesn't define its own menu)
The behaviour of AquaTk is a feature, not a bug. Appearently the default menu
is inheritted from the root ("."). I'll see if I can override that menu in
macosxSupport.setupApp.
--
Comment By: Kurt B. Kaiser (kbk)
Date: 2006-07-22 23:23
Message:
Logged In: YES
user_id=149084
> Tk uses the per-window menu for the currently
> selected window
I assume you mean AquaTk uses the per-window...
Please put in a bug request on AquaTk to get it
to conform to how Tk handles this menu on Linux
and Windows. Then downgrade the priority of this
bug or close it.
Does the debugger have the same problem?
--
Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-18 14:20
Message:
Logged In: YES
user_id=580910
These menu problems are at the very root caused by differences in the way
menus work on OSX (one application wide menu at the top of the screen) and
most other systems (optional menus for every window). Applications on OSX
must have some kind of menu (or be full-screen, but we don't want that for
IDLE), Tk uses the per-window menu for the currently selected window for
that. If a window doesn't have a menu it makes up one and I haven't found a
way yet to override that menu (which would solve that problem once and for
all).
I do believe that my other changes really are good, they make IDLE perform
more like a true OSX application. This is important because IDLE is the default
IDE, and hence probably the first thing naive OSX users will see of python.
BTW. AquaTk really sucks, which makes it annoyingly hard to create a really
good OSX citizen of IDLE and I have given up on getting there. If I understand
the lazyweb correctly you're supposed to port your appliations to some other
GUI library (Tile?) to get a native L&F for lots of widgets and standard
dialogs.
--
Comment By: Kurt B. Kaiser (kbk)
Date: 2006-07-15 21:51
Message:
Logged In: YES
user_id=149084
I suppose this is also true for the debugger?
I'd consider this a bug in OSX Tk, it should be
reported there.
Without a specific need for a menubar, all it does
is take up valuable vertical space. And continuing
to add OSX special casing clutters up the IDLE code;
IMO it should be limited to situations where
functionality is compromised.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1517996&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1527397 ] PythonLauncher uses incorrect working directory
Bugs item #1527397, was opened at 2006-07-23 13:29 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=1527397&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: Macintosh Group: Python 2.5 Status: Open Resolution: None Priority: 7 Submitted By: Bob Ippolito (etrepum) Assigned to: Jack Jansen (jackjansen) Summary: PythonLauncher uses incorrect working directory Initial Comment: PythonLauncher, the application used to launch .py files by double-click, does not launch with the correct working directory. This means that any script that depends on data files will not work via PythonLauncher. Users expect the working directory to be that of the launched script, like on other platforms, but PythonLauncher launches with a working directory of $HOME. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1527397&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1525447 ] Build fails on OS X with case sensitive fs
Bugs item #1525447, was opened at 2006-07-19 19:24
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1525447&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.5
Status: Open
Resolution: None
Priority: 6
Submitted By: gideon may (gdm)
Assigned to: Ronald Oussoren (ronaldoussoren)
Summary: Build fails on OS X with case sensitive fs
Initial Comment:
When compiling python from svn on a Mac OS X with a
case sensitive file system I get the following build
error:
running build
running build_ext
db.h: found (4, 3) in /opt/local/include/db4
db lib: using (4, 3) db-4.3
sqlite: found /usr/include/sqlite3.h
/usr/include/sqlite3.h: version 3.1.3
Traceback (most recent call last):
File "./setup.py", line 1507, in
main()
.
.
File "./setup.py", line 1088, in addMacExtension
raise RuntimeError("%s not found" % name)
RuntimeError: MacOS not found
make: *** [sharedmods] Error 1
It can be fixed by either renaming the file:
Mac/Modules/macosmodule.c
to
Mac/Modules/MacOSmodule.c
or applying the following patch :
Index: setup.py
===
--- setup.py(revision 50687)
+++ setup.py(working copy)
@@ -1101,7 +1101,7 @@
carbon_kwds = {'extra_compile_args':
carbon_extra_compile_args,
'extra_link_args':
['-framework', 'Carbon'],
}
-CARBON_EXTS = ['ColorPicker', 'gestalt',
'MacOS', 'Nav',
+CARBON_EXTS = ['ColorPicker', 'gestalt',
'macos', 'Nav',
'OSATerminology', 'icglue',
# All these are in subdirs
'_AE', '_AH', '_App',
'_CarbonEvt', '_Cm', '_Ctl',
Cheers,
Gideon
--
>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-23 20:11
Message:
Logged In: YES
user_id=580910
Could you please test if renaming Mac/Modules/macosmodule.c to Mac/
Modules/MacOS.c solves your problem? With that rename the build still works
for me, but I don't have a case-sensitive filesystem.
--
Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-23 11:31
Message:
Logged In: YES
user_id=580910
The patch is incorrect, as this would rename user visible name of the python
extension ('import MacOS' would stop working).
The rename would be correct.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1525447&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1527397 ] PythonLauncher uses incorrect working directory
Bugs item #1527397, was opened at 2006-07-23 19:29 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1527397&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: Macintosh Group: Python 2.5 Status: Open Resolution: None Priority: 7 Submitted By: Bob Ippolito (etrepum) Assigned to: Jack Jansen (jackjansen) Summary: PythonLauncher uses incorrect working directory Initial Comment: PythonLauncher, the application used to launch .py files by double-click, does not launch with the correct working directory. This means that any script that depends on data files will not work via PythonLauncher. Users expect the working directory to be that of the launched script, like on other platforms, but PythonLauncher launches with a working directory of $HOME. -- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-07-23 20:50 Message: Logged In: YES user_id=580910 I agree that the current behaviour is not what users expect and should be considered a bug. I'd like to get the attached patch into 2.5, it changes the CWD to the directory containing the script and should be perfectly save. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1527397&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1436532 ] length of unicode string changes print behaviour
Bugs item #1436532, was opened at 2006-02-22 10:45 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1436532&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: IDLE Group: Python 2.4 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: James (hover_boy) Assigned to: Martin v. Löwis (loewis) Summary: length of unicode string changes print behaviour Initial Comment: Python 2.4.2 and IDLE (with Courier New font) on XP and the following code saved as a UTF-8 file if __name__ == "__main__": print "é¶ ä¸ äº ä¸ å äº å ä¸ å «" print "é¶ ä¸ äº ä¸ å äº å ä¸ å « ä¹ å " results in... IDLE 1.1.2 >>> RESTART >>> éâºÂ¶ ä¸⬠亊ä¸Ⱐåâºâº äºâ Ã¥â¦Ã¤Â¸Æ Ã¥â¦Â« é¶ ä¸ äº ä¸ å äº å ä¸ å « ä¹ å >>> -- >Comment By: Martin v. Löwis (loewis) Date: 2006-07-23 21:42 Message: Logged In: YES user_id=21627 This is not a bug. The program should not attempt to print byte strings, since it cannot know what the encoding of the byte strings is. Instead, the program should use Unicode strings, such as print u"å «å «å «å «å «å «å «å «å «å «å «å «å «å «å «å «å «å «å «å «å «å «" If you attempt to print byte strings, they have to be in the encoding of stdout, or else the behaviour is unspecified. In my installation/locale, sys.stdout.encoding is cp1250. IDLE's OutputWindow.write has this code: # Tk assumes that byte strings are Latin-1; # we assume that they are in the locale's encoding if isinstance(s, str): try: s = unicode(s, IOBinding.encoding) except UnicodeError: # some other encoding; let Tcl deal with it pass Of the strings specified in the source file, only strings 2..5 decode properly as cp1250; the others don't. So these get passed directly to Tcl, which then assumes they are UTF-8, with some fallback also. The strings that look "incorrectly" are actually printed out as designed: using sys.stdout.encoding. -- Comment By: Kurt B. Kaiser (kbk) Date: 2006-07-23 07:33 Message: Logged In: YES user_id=149084 I don't have a font installed which will print those characters. When I load your sample file, I see print statements which include unicode characters like \u5341. The printed output contains the same unicode characters as the input program. Maybe Martin has an idea. -- Comment By: James (hover_boy) Date: 2006-03-22 16:21 Message: Logged In: YES user_id=1458491 I've attached an example file to demonstrate the problem better. it seems not to be the length but something else which I haven't figured out yet. I've also added the encoding comment and also tried changing the default encoding in sitecustomize.py from latin -1 to utf-8 but neither seem to work. thanks, James. XP professional, SP2, english -- Comment By: James (hover_boy) Date: 2006-03-22 16:12 Message: Logged In: YES user_id=1458491 -- Comment By: Terry J. Reedy (tjreedy) Date: 2006-03-06 02:44 Message: Logged In: YES user_id=593130 I am fairly ignorant of unicode and encodings, but I am surprised you got anything coherent without an encoding cookie comment at the top (see manual). Have you tried that? Other questions that might help someone answer: What specific XP version? SP2 installed? Country version? Your results for >>> sys.getdefaultencoding() 'ascii' >>> sys.getfilesystemencoding() 'mbcs' What happens if you reverse the order of the print statements? (Ie, is it really the shorter string that does not work or just the first?) I don't know enough to know if this is really a bug. If you don't get an answer here, you might try for more info on python-list/comp.lang.python -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1436532&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1525678 ] exec and eval allocate lots of memory and do not free it
Bugs item #1525678, was opened at 2006-07-20 05:57
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1525678&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: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Connelly (connelly)
Assigned to: Nobody/Anonymous (nobody)
Summary: exec and eval allocate lots of memory and do not free it
Initial Comment:
I'm not sure if this is a bug. The "bug" is that if I start a new Python
session, create a dict or list called d which takes around 2 MB of
memory, and then I set d = eval(repr(d)), the Python process now is
using ~38 MB of memory more than where it started at. The high
memory usage continues even after d is deleted.
Example 1:
% python
>>> # Memory use: 3216 KB
>>> d = dict.fromkeys(range(5))
>>> # Memory use: 5400 KB
>>> d = eval('%r' % d)
>>> # Memory use: 41620 KB
>>> del d
>>> # Memory use: 40080 KB
I am using Python 2.4.1 (#65, Mar 30 2005) on Windows XP SP2 with
512 MB RAM.
If we start with a larger initial dict -- say
dict.fromkeys(range(1000**2)), then the line d = eval('%r' % d) can
easily cause the process to start paging to disk, even though both the
data structure and its string representation fit easily in memory.
Perhaps this behavior is due Python caching bytecodes. One
peculiarity about this "bug" is that if Example 1 is repeated with a
second variable such as "d2", which is set to the value
dict.fromkeys(range(5,10)), then the memory usage ends up
exactly at 40080 KB after the second "del" statement. If Python were
caching the bytecodes, then one would expect the repetition of the
example to put the memory usage at ~8 KB.
--
>Comment By: Martin v. Löwis (loewis)
Date: 2006-07-23 21:53
Message:
Logged In: YES
user_id=21627
This "bug" falls into the "won't fix" category, and also in
the "already fixed" category.
Python does indeed free the memory; there is no caching
going on. It just doesn't return the memory to the operating
system. You can see that the memory is really freed by
performing the same operating over and over again (say, a
thousand times), and watch the memory consumption not grow.
Python obtains the memory not from the system, but from
malloc, which obtains it from the system. Whether or not
malloc will return memory to the system depends on the
malloc implementation; this is out of our control (it's in
the Microsoft C library).
However, Python does not return the memory to malloc,
either. In the specific case, there are two allocators on
top of malloc operating: the integer allocator, and the
small objects allocator.
The integer allocator allocates a chunk from malloc and then
subdivides it into integer objects. This memory is never
returned to malloc; you are using this allocator within the
range() function. When the integers are released, the memory
becomes available for other integer objects, but not for
objects of another kind.
The small objects allocator is likely used for the repr
strings of the integers. Object sizes are rounded up to the
next multiple of 8 (say, 24), and then a pool of
24-byte-sized blocks is maintained. When the string objects
are released, they are released to the pool. In Python 2.4,
pool memory is never returned to malloc.
In Python 2.5, this aspect is fixed: under certain
circumstances (which are too involved to describe here),
pool memory is returned to malloc, which then hopefully
returns it to the system.
Closing as "won't fix".
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1525678&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1524938 ] MemoryError with a lot of available memory - gc not called
Bugs item #1524938, was opened at 2006-07-19 04:46
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1524938&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: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Matusevich (markmat)
Assigned to: Nobody/Anonymous (nobody)
Summary: MemoryError with a lot of available memory - gc not called
Initial Comment:
Also the gc behavior is consistent with the
documentation, I beleave it is wrong. I think, that Gc
should be called automatically before any memory
allocation is raised.
Example 1:
for i in range(700):
a = [range(500)]
a.append(a)
print i
This example will crash on any any PC with less then
20Gb RAM. On my PC (Windows 2000, 256Mb) it crashes at
i==7.
Also, this example can be fixed by addition of a call
to gc.collect() in the loop, in real cases it may be
unreasonable.
--
>Comment By: Martin v. Löwis (loewis)
Date: 2006-07-23 22:00
Message:
Logged In: YES
user_id=21627
This is very difficult to implement. The best way might be
to introduce yet another allocation function, one that
invokes gc before failing, and call that function in all
interesting places (of which there are many).
Contributions are welcome and should probably start with a
PEP first.
--
Comment By: Rene Dudfield (illume)
Date: 2006-07-20 01:20
Message:
Logged In: YES
user_id=2042
Perhaps better than checking before every memory allocation,
would be to check once a memory error happens in an allocation.
That way there is only the gc hit once there is low memory.
So...
res = malloc(...);
if(!res) {
gc.collect();
}
res = malloc(...);
if(!res) {
raise memory error.
}
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1524938&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1524938 ] MemoryError with a lot of available memory - gc not called
Bugs item #1524938, was opened at 2006-07-19 05:46
Message generated for change (Comment added) made by markmat
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1524938&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: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Matusevich (markmat)
Assigned to: Nobody/Anonymous (nobody)
Summary: MemoryError with a lot of available memory - gc not called
Initial Comment:
Also the gc behavior is consistent with the
documentation, I beleave it is wrong. I think, that Gc
should be called automatically before any memory
allocation is raised.
Example 1:
for i in range(700):
a = [range(500)]
a.append(a)
print i
This example will crash on any any PC with less then
20Gb RAM. On my PC (Windows 2000, 256Mb) it crashes at
i==7.
Also, this example can be fixed by addition of a call
to gc.collect() in the loop, in real cases it may be
unreasonable.
--
>Comment By: Mark Matusevich (markmat)
Date: 2006-07-23 23:11
Message:
Logged In: YES
user_id=1337765
This is exectly what I meant.
For my recollection, this is the policy in Java GC. I never
had to handle MemoryError in Java, because I knew, that I
really do not have any more memory.
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-07-23 23:00
Message:
Logged In: YES
user_id=21627
This is very difficult to implement. The best way might be
to introduce yet another allocation function, one that
invokes gc before failing, and call that function in all
interesting places (of which there are many).
Contributions are welcome and should probably start with a
PEP first.
--
Comment By: Rene Dudfield (illume)
Date: 2006-07-20 02:20
Message:
Logged In: YES
user_id=2042
Perhaps better than checking before every memory allocation,
would be to check once a memory error happens in an allocation.
That way there is only the gc hit once there is low memory.
So...
res = malloc(...);
if(!res) {
gc.collect();
}
res = malloc(...);
if(!res) {
raise memory error.
}
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1524938&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1524938 ] MemoryError with a lot of available memory - gc not called
Bugs item #1524938, was opened at 2006-07-19 05:46
Message generated for change (Comment added) made by markmat
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1524938&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: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Matusevich (markmat)
Assigned to: Nobody/Anonymous (nobody)
Summary: MemoryError with a lot of available memory - gc not called
Initial Comment:
Also the gc behavior is consistent with the
documentation, I beleave it is wrong. I think, that Gc
should be called automatically before any memory
allocation is raised.
Example 1:
for i in range(700):
a = [range(500)]
a.append(a)
print i
This example will crash on any any PC with less then
20Gb RAM. On my PC (Windows 2000, 256Mb) it crashes at
i==7.
Also, this example can be fixed by addition of a call
to gc.collect() in the loop, in real cases it may be
unreasonable.
--
>Comment By: Mark Matusevich (markmat)
Date: 2006-07-23 23:19
Message:
Logged In: YES
user_id=1337765
Sorry, my last comment was to illume (I am slow typer :( )
--
Comment By: Mark Matusevich (markmat)
Date: 2006-07-23 23:11
Message:
Logged In: YES
user_id=1337765
This is exectly what I meant.
For my recollection, this is the policy in Java GC. I never
had to handle MemoryError in Java, because I knew, that I
really do not have any more memory.
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-07-23 23:00
Message:
Logged In: YES
user_id=21627
This is very difficult to implement. The best way might be
to introduce yet another allocation function, one that
invokes gc before failing, and call that function in all
interesting places (of which there are many).
Contributions are welcome and should probably start with a
PEP first.
--
Comment By: Rene Dudfield (illume)
Date: 2006-07-20 02:20
Message:
Logged In: YES
user_id=2042
Perhaps better than checking before every memory allocation,
would be to check once a memory error happens in an allocation.
That way there is only the gc hit once there is low memory.
So...
res = malloc(...);
if(!res) {
gc.collect();
}
res = malloc(...);
if(!res) {
raise memory error.
}
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1524938&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1524938 ] PEP MemoryError with a lot of available memory gc not called
Bugs item #1524938, was opened at 2006-07-19 05:46
Message generated for change (Settings changed) made by markmat
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1524938&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: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Matusevich (markmat)
Assigned to: Nobody/Anonymous (nobody)
>Summary: PEP MemoryError with a lot of available memory gc not called
Initial Comment:
Also the gc behavior is consistent with the
documentation, I beleave it is wrong. I think, that Gc
should be called automatically before any memory
allocation is raised.
Example 1:
for i in range(700):
a = [range(500)]
a.append(a)
print i
This example will crash on any any PC with less then
20Gb RAM. On my PC (Windows 2000, 256Mb) it crashes at
i==7.
Also, this example can be fixed by addition of a call
to gc.collect() in the loop, in real cases it may be
unreasonable.
--
Comment By: Mark Matusevich (markmat)
Date: 2006-07-23 23:19
Message:
Logged In: YES
user_id=1337765
Sorry, my last comment was to illume (I am slow typer :( )
--
Comment By: Mark Matusevich (markmat)
Date: 2006-07-23 23:11
Message:
Logged In: YES
user_id=1337765
This is exectly what I meant.
For my recollection, this is the policy in Java GC. I never
had to handle MemoryError in Java, because I knew, that I
really do not have any more memory.
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-07-23 23:00
Message:
Logged In: YES
user_id=21627
This is very difficult to implement. The best way might be
to introduce yet another allocation function, one that
invokes gc before failing, and call that function in all
interesting places (of which there are many).
Contributions are welcome and should probably start with a
PEP first.
--
Comment By: Rene Dudfield (illume)
Date: 2006-07-20 02:20
Message:
Logged In: YES
user_id=2042
Perhaps better than checking before every memory allocation,
would be to check once a memory error happens in an allocation.
That way there is only the gc hit once there is low memory.
So...
res = malloc(...);
if(!res) {
gc.collect();
}
res = malloc(...);
if(!res) {
raise memory error.
}
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1524938&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1012435 ] ctrl-left/-right works incorectly with diacritics
Bugs item #1012435, was opened at 2004-08-19 15:40
Message generated for change (Comment added) made by kbk
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1012435&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: Tkinter
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Krzysztof Wilkosz (sophros)
>Assigned to: Nobody/Anonymous (nobody)
Summary: ctrl-left/-right works incorectly with diacritics
Initial Comment:
When left- or right-going in line with ctrl-arrow
(left/right) I have encountered problems:
example word with polish (cp1250) diacritics: zażółć
(last 4 letters might be unreadable) this keybord
shortcut stops each time diacritic letter is
encountered, not at the end of the word. It is
frustrating as I have many strings and comments in
Polish. I thing it might work bad also in the case of
any other non-ASCII letters.
--
>Comment By: Kurt B. Kaiser (kbk)
Date: 2006-07-23 16:45
Message:
Logged In: YES
user_id=149084
The control-{right,left} action appears to be
implemented in Tkinter, probably in Tcl/Tk, it's
not an IDLE issue.
Someone should check if the problem exists in
Tk. Passing this on to the Tkinter crew.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1012435&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1512124 ] OSX: debugger hangs IDLE
Bugs item #1512124, was opened at 2006-06-25 09:45 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512124&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: IDLE Group: Python 2.5 Status: Open Resolution: Accepted Priority: 7 Submitted By: Aahz (aahz) Assigned to: Nobody/Anonymous (nobody) Summary: OSX: debugger hangs IDLE Initial Comment: This has been previously found on 2.3/2.4 and verified again with 2.5b1 (was hoping that the 1.2 IDLE update would fix): When you bring up the debugger window in IDLE on OSX, you'll notice that it's vibrating, as if it's stuck in a resize loop. Unless you immediately resize the window manually, IDLE will hang the next time you try to do something that updates the debugger window. -- >Comment By: Kurt B. Kaiser (kbk) Date: 2006-07-23 16:47 Message: Logged In: YES user_id=149084 Please try running IDLE w/o the subprocess by starting it with the -n switch. Does the issue still exist? -- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-06-25 16:49 Message: Logged In: YES user_id=580910 And when you do resize the window layout sucks, automatic layout seems to be buggy here (although I must admit that I haven't seen IDLE on other platforms). I have no idea what is causing this bug. Upgrading the Tk version to the very latest instead of using the system version doesn't help. I've checked in a workaround in revision 47091. That patch avoids explicitly sizing the stackviewer widget on OSX, which seems to fix this problem. The debugger window now is rather less wide than it was before, which means users will likely have to resize the window if they want to use the debugger. I'm leaving this bug open and unassign it in the hope that someone who actually knows Tkinter proposed a better fix. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512124&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1510853 ] Add Windows 9x/ME (lack of) support information to README.TX
Feature Requests item #1510853, was opened at 2006-06-22 20:36 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1510853&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: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: ajaksu (ajaksu2) Assigned to: A.M. Kuchling (akuchling) Summary: Add Windows 9x/ME (lack of) support information to README.TX Initial Comment: I suggest that following informative note should be added as a new sub-section in README.TXT's "Unsupported systems" (which really needs mentioning MacOS 9). The sub-section idea regards README.TXT only talking about already unsupported platforms. Motivation: As one of the few Windows 98 users that program in Python AND installed the 2.5 beta1, I was greeted by Tools/msi/msi.py's warning message. However, no further information was available in the downloaded release or in the online beta documents (What's New, release notes, etc.). Best regards, Daniel Diniz - Warning on install in Windows 98 and Windows Me Following Microsoft's closing of Extended Support for Windows 98/ME (July 11, 2006), Python 2.6 will stop supporting these platforms. Python development and maintainability becomes easier (and more reliable) when platform specific code targeting OSes with few users and no dedicated expert developers is taken out. The vendor also warns that the OS versions listed above "can expose customers to security risks" and recommends upgrade. For a more detailed discussion regarding no-longer-supported and resupporting platforms, as well as a list of platforms that became or will be unsupported, see PEP 11. Current behavior The Python 2.5 installer presents a warning message on those systems: "Warning: Python 2.5.x is the last Python release for Windows 9x." Suggested readings PEP 11: Removing support for little used platforms (http://www.python.org/dev/peps/pep-0011) End of support for Windows 98, Windows Me, and Windows XP Service Pack 1 (http://www.microsoft.com/windows/support/endofsupport.mspx) Copyright This document has been placed in the public domain. -- -- >Comment By: Martin v. Löwis (loewis) Date: 2006-07-24 07:06 Message: Logged In: YES user_id=21627 Thanks for the suggestion. I added the text (in some form) to README in r50794. -- Comment By: Georg Brandl (gbrandl) Date: 2006-06-22 20:59 Message: Logged In: YES user_id=849994 Andrew? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1510853&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1512124 ] OSX: debugger hangs IDLE
Bugs item #1512124, was opened at 2006-06-25 15:45 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512124&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: IDLE Group: Python 2.5 Status: Open Resolution: Accepted Priority: 7 Submitted By: Aahz (aahz) Assigned to: Nobody/Anonymous (nobody) Summary: OSX: debugger hangs IDLE Initial Comment: This has been previously found on 2.3/2.4 and verified again with 2.5b1 (was hoping that the 1.2 IDLE update would fix): When you bring up the debugger window in IDLE on OSX, you'll notice that it's vibrating, as if it's stuck in a resize loop. Unless you immediately resize the window manually, IDLE will hang the next time you try to do something that updates the debugger window. -- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-07-24 08:09 Message: Logged In: YES user_id=580910 You'd have to test with a version of python before 2.5b1, after that I've added a workaround for this issue. This workaround makes the debugger window narrower than intended, but at least you have a working version of IDLE. My guess is that the root cause of this issue is a bug in TkAqua. I haven't filed a bug with them because I have never programmed in Tcl and would therefore require lots of time to get a Tcl program going that demonstrates this problem. -- Comment By: Kurt B. Kaiser (kbk) Date: 2006-07-23 22:47 Message: Logged In: YES user_id=149084 Please try running IDLE w/o the subprocess by starting it with the -n switch. Does the issue still exist? -- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-06-25 22:49 Message: Logged In: YES user_id=580910 And when you do resize the window layout sucks, automatic layout seems to be buggy here (although I must admit that I haven't seen IDLE on other platforms). I have no idea what is causing this bug. Upgrading the Tk version to the very latest instead of using the system version doesn't help. I've checked in a workaround in revision 47091. That patch avoids explicitly sizing the stackviewer widget on OSX, which seems to fix this problem. The debugger window now is rather less wide than it was before, which means users will likely have to resize the window if they want to use the debugger. I'm leaving this bug open and unassign it in the hope that someone who actually knows Tkinter proposed a better fix. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512124&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
