[ python-Bugs-1565468 ] Install on WinXP always goes to C:\
Bugs item #1565468, was opened at 2006-09-25 23:05 Message generated for change (Comment added) made by piercew You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565468&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: Installation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Wayne Pierce (piercew) Assigned to: Nobody/Anonymous (nobody) Summary: Install on WinXP always goes to C:\ Initial Comment: When I install Python on WinXP it always goes go C:\ even though I select C:\Python . This happens when Python is installed for just me or for all users on a system. The system is running WinXP SP 2 and the account installing has enough rights to install applications. An install log has been attached. -- >Comment By: Wayne Pierce (piercew) Date: 2006-09-26 05:10 Message: Logged In: YES user_id=4553 Since I cannot attach a file to a bug report I have placed the python.log file at http://shalofin.googlepages.com/python.log -- Comment By: Wayne Pierce (piercew) Date: 2006-09-25 23:40 Message: Logged In: YES user_id=4553 I am unable to attach a file. Every time a file is attached I receive a 'page cannot be found' error message. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565468&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1565525 ] gc allowing tracebacks to eat up memory
Bugs item #1565525, was opened at 2006-09-26 02:58 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565525&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.5 Status: Open Resolution: None Priority: 5 Submitted By: Greg Hazel (ghazel) Assigned to: Nobody/Anonymous (nobody) Summary: gc allowing tracebacks to eat up memory Initial Comment: Attached is a file which demonstrates an oddity about traceback objects and the gc. The observed behaviour is that when the tuple from sys.exc_info() is stored on an object which is inside the local scope, the object, thus exc_info tuple, are not collected even when both leave scope. If you run the test with "s.e = sys.exc_info()" commented out, the observed memory footprint of the process quickly approaches and sits at 5,677,056 bytes. Totally reasonable. If you uncomment that line, the memory footprint climbs to 283,316,224 bytes quite rapidly. That's a two order of magnitude difference! If you uncomment the "gc.collect()" line, the process still hits 148,910,080 bytes. This was observed in production code, where exc_info tuples are saved for re-raising later to get the stack- appending behaviour tracebacks and 'raise' perform. The example includes a large array to simulate application state. I assume this is bad behaviour occurring because the traceback object holds frames, and those frames hold a reference to the local objects, thus the exc_info tuple itself, thus causing a circular reference which involves the entire stack. Either the gc needs to be improved to prevent this from growing so wildly, or the traceback objects need to (optionally?) hold frames which do not have references or have weak references instead. -- >Comment By: Tim Peters (tim_one) Date: 2006-09-26 06:04 Message: Logged In: YES user_id=31435 Your memory bloat is mostly due to the d = range(10) line. Python has no problem collecting the cyclic trash, but you're creating 10 * 100 = 10 million integer objects hanging off trash cycles before invoking gc.collect(), and those integers require at least 10 million * 12 ~= 120MB all by themselves. Worse, memory allocated to "short" integers is both immortal and unbounded: it can be reused for /other/ integer objects, but it never goes away. Note that memory usage in your program remains low and steady if you force gc.collect() after every call to bar(). Then you only create 100K integers, instead of 10M, before the trash gets cleaned up. There is no simple-minded way to "repair" this, BTW. For example, /of course/ a frame has to reference all its locals, and moving to weak references for those instead would be insanely inefficient (among other, and deeper, problems). Note that the library reference manual warns against storing the result of exc_info() in a local variable (which you're /effectively/ doing, since the formal parameter `s` is a local variable within foo()), and suggests other approaches. Sorry, but I really couldn't tell from your description why you want to store this stuff in an instance attribute, so can't guess whether another more-or-less obvious approach would help. For example, no cyclic trash is created if you add this method to your class O: def get_traceback(self): self.e = sys.exc_info() and inside foo() invoke: s.get_traceback() instead of doing: s.e = sys.exc_info() Is that unreasonable? Perhaps simpler is to define a function like: def get_exc_info(): return sys.exc_info() and inside foo() do: s.e = get_exc_info() No cyclic trash gets created that way either. These are the kinds of things the manual has suggested doing for the last 10 years ;-) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565525&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1564763 ] Unicode comparison change in 2.4 vs. 2.5
Bugs item #1564763, was opened at 2006-09-25 01:43
Message generated for change (Comment added) made by lemburg
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1564763&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: Unicode
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Joe Wreschnig (piman)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Unicode comparison change in 2.4 vs. 2.5
Initial Comment:
Python 2.5 changed the behavior of unicode comparisons
in a significant way from Python 2.4, causing a test
case failure in a module of mine. All tests passed with
an earlier version of 2.5, though unfortunately I don't
know what version in particular it started failing with.
The following code prints out all True on Python 2.4;
the strings are compared case-insensitively, whether
they are my lowerstr class, real strs, or unicodes. On
Python 2.5, the comparison between lowerstr and unicode
is false, but only in one direction.
If I make lowerstr inherit from unicode rather than
str, all comparisons are true again. So at the very
least, this is internally inconsistent. I also think
changing the behavior between 2.4 and 2.5 constitutes a
serious bug.
--
>Comment By: M.-A. Lemburg (lemburg)
Date: 2006-09-26 12:39
Message:
Logged In: YES
user_id=38388
Armin, is it possible that the missing
Py_TPFLAGS_HAVE_RICHCOMPARE type flag in the Unicode type is
causing this ?
I just had a look at the code and it appears that the
comparison code checks the flag rather than just looking at
the slot itself (didn't even know there was such a type flag).
--
Comment By: Armin Rigo (arigo)
Date: 2006-09-25 23:33
Message:
Logged In: YES
user_id=4771
Sorry, I missed your comment: if lowerstr inherits from
unicode then it just works. The reason is that
'abc'.__eq__(u'abc') returns NotImplemented, but
u'abc'.__eq__('abc') returns True.
This is only inconsistent because of the asymmetry between
strings and unicodes: strings can be transparently turned
into unicodes but not the other way around -- so
unicode.__eq__(x) can accept a string as the argument x
and convert it to a unicode transparently, but str.__eq__(x)
does not try to convert x to a string if it is a unicode.
It's not a completely convincing explanation, but I think it
shows at least why we got at the current situation of Python
2.5.
--
Comment By: Armin Rigo (arigo)
Date: 2006-09-25 23:11
Message:
Logged In: YES
user_id=4771
This is an artifact of the change in the unicode class, which
now has the proper __eq__, __ne__, __lt__, etc. methods
instead of the semi-deprecated __cmp__. The mixture of
__cmp__ and the other methods is not very well-defined. This
is why your code worked in 2.4: a bit by chance.
Indeed, in theory it should not, according to the language
reference. So what I am saying is that although it is a
behavior change from 2.4 to 2.5, I would argue that it is not
a bug but a bug fix...
The reason is that if we ignore the __eq__ vs __cmp__ issues,
the operation 'a == b' is defined as: Python tries
a.__eq__(b); if this returns NotImplemented, then Python
tries b.__eq__(a). As an exception, if type(b) is a strict
subclass of type(a), then Python tries in the other order.
This is why you get the 2.5 behavior: if lowerstr inherits
from str, it is not a subclass of unicode, so u'abc' ==
lowerstr() tries u'abc'.__eq__(), which works immediately.
On the other hand, if lowerstr inherits from unicode, then
Python tries first lowerstr().__eq__(u'abc').
This part of the Python object model - when to reverse the
order or not - is a bit obscure and not completely helpful...
Subclassing built-in types generally only works a bit. In
your situation you should use a regular class that behaves in
a string-like fashion, with an __eq__() method doing the
case-insensitive comparison... if you can at all - there are
places where you need a real string, so this "solution" might
not be one either, but I don't see a better one :-(
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1564763&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1564763 ] Unicode comparison change in 2.4 vs. 2.5
Bugs item #1564763, was opened at 2006-09-25 01:43
Message generated for change (Comment added) made by lemburg
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1564763&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: Unicode
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Joe Wreschnig (piman)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Unicode comparison change in 2.4 vs. 2.5
Initial Comment:
Python 2.5 changed the behavior of unicode comparisons
in a significant way from Python 2.4, causing a test
case failure in a module of mine. All tests passed with
an earlier version of 2.5, though unfortunately I don't
know what version in particular it started failing with.
The following code prints out all True on Python 2.4;
the strings are compared case-insensitively, whether
they are my lowerstr class, real strs, or unicodes. On
Python 2.5, the comparison between lowerstr and unicode
is false, but only in one direction.
If I make lowerstr inherit from unicode rather than
str, all comparisons are true again. So at the very
least, this is internally inconsistent. I also think
changing the behavior between 2.4 and 2.5 constitutes a
serious bug.
--
>Comment By: M.-A. Lemburg (lemburg)
Date: 2006-09-26 12:55
Message:
Logged In: YES
user_id=38388
Ah, wrong track: Py_TPFLAGS_HAVE_RICHCOMPARE is set via
Py_TPFLAGS_DEFAULT.
--
Comment By: M.-A. Lemburg (lemburg)
Date: 2006-09-26 12:39
Message:
Logged In: YES
user_id=38388
Armin, is it possible that the missing
Py_TPFLAGS_HAVE_RICHCOMPARE type flag in the Unicode type is
causing this ?
I just had a look at the code and it appears that the
comparison code checks the flag rather than just looking at
the slot itself (didn't even know there was such a type flag).
--
Comment By: Armin Rigo (arigo)
Date: 2006-09-25 23:33
Message:
Logged In: YES
user_id=4771
Sorry, I missed your comment: if lowerstr inherits from
unicode then it just works. The reason is that
'abc'.__eq__(u'abc') returns NotImplemented, but
u'abc'.__eq__('abc') returns True.
This is only inconsistent because of the asymmetry between
strings and unicodes: strings can be transparently turned
into unicodes but not the other way around -- so
unicode.__eq__(x) can accept a string as the argument x
and convert it to a unicode transparently, but str.__eq__(x)
does not try to convert x to a string if it is a unicode.
It's not a completely convincing explanation, but I think it
shows at least why we got at the current situation of Python
2.5.
--
Comment By: Armin Rigo (arigo)
Date: 2006-09-25 23:11
Message:
Logged In: YES
user_id=4771
This is an artifact of the change in the unicode class, which
now has the proper __eq__, __ne__, __lt__, etc. methods
instead of the semi-deprecated __cmp__. The mixture of
__cmp__ and the other methods is not very well-defined. This
is why your code worked in 2.4: a bit by chance.
Indeed, in theory it should not, according to the language
reference. So what I am saying is that although it is a
behavior change from 2.4 to 2.5, I would argue that it is not
a bug but a bug fix...
The reason is that if we ignore the __eq__ vs __cmp__ issues,
the operation 'a == b' is defined as: Python tries
a.__eq__(b); if this returns NotImplemented, then Python
tries b.__eq__(a). As an exception, if type(b) is a strict
subclass of type(a), then Python tries in the other order.
This is why you get the 2.5 behavior: if lowerstr inherits
from str, it is not a subclass of unicode, so u'abc' ==
lowerstr() tries u'abc'.__eq__(), which works immediately.
On the other hand, if lowerstr inherits from unicode, then
Python tries first lowerstr().__eq__(u'abc').
This part of the Python object model - when to reverse the
order or not - is a bit obscure and not completely helpful...
Subclassing built-in types generally only works a bit. In
your situation you should use a regular class that behaves in
a string-like fashion, with an __eq__() method doing the
case-insensitive comparison... if you can at all - there are
places where you need a real string, so this "solution" might
not be one either, but I don't see a better one :-(
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1564763&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1565797 ] 'all' documentation missing online
Bugs item #1565797, was opened at 2006-09-26 10:21 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=1565797&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: Open Resolution: None Priority: 5 Submitted By: Alan (aisaac0) Assigned to: Nobody/Anonymous (nobody) Summary: 'all' documentation missing online Initial Comment: http://docs.python.org/lib/built-in-funcs.html is missing a description of the new built-in 'all' function. On a separate note, contrary to the statement on the bugs page, the search dialogue is not in the left margin ... -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565797&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1564763 ] Unicode comparison change in 2.4 vs. 2.5
Bugs item #1564763, was opened at 2006-09-25 01:43
Message generated for change (Comment added) made by lemburg
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1564763&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: Unicode
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Joe Wreschnig (piman)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Unicode comparison change in 2.4 vs. 2.5
Initial Comment:
Python 2.5 changed the behavior of unicode comparisons
in a significant way from Python 2.4, causing a test
case failure in a module of mine. All tests passed with
an earlier version of 2.5, though unfortunately I don't
know what version in particular it started failing with.
The following code prints out all True on Python 2.4;
the strings are compared case-insensitively, whether
they are my lowerstr class, real strs, or unicodes. On
Python 2.5, the comparison between lowerstr and unicode
is false, but only in one direction.
If I make lowerstr inherit from unicode rather than
str, all comparisons are true again. So at the very
least, this is internally inconsistent. I also think
changing the behavior between 2.4 and 2.5 constitutes a
serious bug.
--
>Comment By: M.-A. Lemburg (lemburg)
Date: 2006-09-26 13:13
Message:
Logged In: YES
user_id=38388
In any case, the introduction of the Unicode tp_richcompare
slot is likely the cause for this behavior:
$python2.5 lowerstr.py
u'baR' == l'Bar'? False
$ python2.4 lowerstr.py
u'baR' == l'Bar'? True
Note that in both Python 2.4 and 2.5, the lowerstr.__eq__()
method is not even called. This is probably due to the fact
that Unicode can compare itself to strings, so the
w.__eq__(v) part of the rich comparison is never tried.
Now, the Unicode .__eq__() converts the string to Unicode,
so the right hand side becomes u'Bar' in both cases.
I guess a debugger session is due...
--
Comment By: M.-A. Lemburg (lemburg)
Date: 2006-09-26 12:55
Message:
Logged In: YES
user_id=38388
Ah, wrong track: Py_TPFLAGS_HAVE_RICHCOMPARE is set via
Py_TPFLAGS_DEFAULT.
--
Comment By: M.-A. Lemburg (lemburg)
Date: 2006-09-26 12:39
Message:
Logged In: YES
user_id=38388
Armin, is it possible that the missing
Py_TPFLAGS_HAVE_RICHCOMPARE type flag in the Unicode type is
causing this ?
I just had a look at the code and it appears that the
comparison code checks the flag rather than just looking at
the slot itself (didn't even know there was such a type flag).
--
Comment By: Armin Rigo (arigo)
Date: 2006-09-25 23:33
Message:
Logged In: YES
user_id=4771
Sorry, I missed your comment: if lowerstr inherits from
unicode then it just works. The reason is that
'abc'.__eq__(u'abc') returns NotImplemented, but
u'abc'.__eq__('abc') returns True.
This is only inconsistent because of the asymmetry between
strings and unicodes: strings can be transparently turned
into unicodes but not the other way around -- so
unicode.__eq__(x) can accept a string as the argument x
and convert it to a unicode transparently, but str.__eq__(x)
does not try to convert x to a string if it is a unicode.
It's not a completely convincing explanation, but I think it
shows at least why we got at the current situation of Python
2.5.
--
Comment By: Armin Rigo (arigo)
Date: 2006-09-25 23:11
Message:
Logged In: YES
user_id=4771
This is an artifact of the change in the unicode class, which
now has the proper __eq__, __ne__, __lt__, etc. methods
instead of the semi-deprecated __cmp__. The mixture of
__cmp__ and the other methods is not very well-defined. This
is why your code worked in 2.4: a bit by chance.
Indeed, in theory it should not, according to the language
reference. So what I am saying is that although it is a
behavior change from 2.4 to 2.5, I would argue that it is not
a bug but a bug fix...
The reason is that if we ignore the __eq__ vs __cmp__ issues,
the operation 'a == b' is defined as: Python tries
a.__eq__(b); if this returns NotImplemented, then Python
tries b.__eq__(a). As an exception, if type(b) is a strict
subclass of type(a), then Python tries in the other order.
This is why you get the 2.5 behavior: if lowerstr inherits
from str, it is not a subclass of unicode, so u'abc' ==
lowerstr() tries u'abc'.__eq__(), which works immediately.
On the other hand, if lowerstr inherits from unicode, then
Python tries first lowerstr().__eq__(u'abc').
This part of the Python object model - when to reverse the
order or not - is a bit obscure and no
[ python-Bugs-1565661 ] webbrowser on gnome runs wrong browser
Bugs item #1565661, was opened at 2006-09-26 11:33
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=1565661&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: kangabroo (kangabroo)
Assigned to: Nobody/Anonymous (nobody)
Summary: webbrowser on gnome runs wrong browser
Initial Comment:
Epiphany is set as system default, but Firefox runs
when webbrowser.open is called.
in webbrowser.py - register_X_browsers():
'gconftool-2 -g
/desktop/gnome/url-handlers/http/command 2>/dev/null'
returns 'epiphany %s'
A BackgroundBrowser with a name of 'epiphany %s' is
created.
later on open(),
subprocess.Popen(['epiphany %s', url], ) is called.
This throws an exception:
OSError: [Errno 2] No such file or directory
which is caught, and False is returned
Solution:
in webbrowser.py function register_X_browsers(), change:
register("gnome", None, BackgroundBrowser(commd))
to
register("gnome", None, BackgroundBrowser(commd.split()))
System: Python 2.5, Linux 2.6.17, Gnome 2.14.2.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565661&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1565797 ] 'all' documentation missing online
Bugs item #1565797, was opened at 2006-09-26 17:21 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565797&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: Pending >Resolution: Invalid Priority: 5 Submitted By: Alan (aisaac0) Assigned to: Nobody/Anonymous (nobody) Summary: 'all' documentation missing online Initial Comment: http://docs.python.org/lib/built-in-funcs.html is missing a description of the new built-in 'all' function. On a separate note, contrary to the statement on the bugs page, the search dialogue is not in the left margin ... -- >Comment By: Martin v. Löwis (loewis) Date: 2006-09-26 18:06 Message: Logged In: YES user_id=21627 Could it be that you had been looking at an old version of the documentation (the new version wasn't online shortly after the release). I can clearly see 'all' documented as all(iterable) Return True if all elements of the iterable are true. Equivalent to: ... As for the separate note: what bugs page are you referring to? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565797&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1542949 ] idle in python 2.5c1 freezes on macos 10.3.9
Bugs item #1542949, was opened at 2006-08-18 21:51
Message generated for change (Comment added) made by dstrozzi
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542949&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: Fixed
Priority: 6
Submitted By: David Strozzi (dstrozzi)
Assigned to: Ronald Oussoren (ronaldoussoren)
Summary: idle in python 2.5c1 freezes on macos 10.3.9
Initial Comment:
Hi,
I installed python 2.5b3 on a powerbook ppc laptop
running macos 10.3.9 a few days ago. python and idle
worked. Now I installed 2.5c1. python works fine from
a terminal. When I start idle, it loads, puts up its
menu bar, opens a shell window, displays usual startup
info, and gives me a prompt. But, I can't type or get
a cursor. Whenever I move the mouse over the idle
window or menu bar, I get a spinning color wheel and
can't do anything.
I deleted the whole /library/python tree, reinstalled
2.5c1, and exactly the same thing happened.
Oh, and I rebooted :)
Not sure what is happening, or how to diagnose.
--
>Comment By: David Strozzi (dstrozzi)
Date: 2006-09-26 13:01
Message:
Logged In: YES
user_id=1056922
Great, thanks for sorting this out!
I tried the edit you suggested in your first reply. Alas,
I'm not root on my system - I am in the admin group, but I
don't have total complete powers. The Python.Framework dir
in /Library/Frameworks has owner admin and group wheel. I'm
not in the wheel group, so can't edit files.
I can wait for the patch, or maybe in the future the
installer could make the group admin instead of wheel? This
may be too esoteric to my system's setup...
--
Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-09-24 14:46
Message:
Logged In: YES
user_id=580910
It turns out to be a buglet in python2.5 after all. There is some code in
distutils.sysconfig to strip out the -arch and -isysroot flags from the build
flags
when you ask for them through that way, but that doesn't fix all variables that
need to be fixed.
I'll apply a patch in the morning.
--
Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-09-24 12:15
Message:
Logged In: YES
user_id=580910
I'm seriously temped to call the problem you're having with numpy a bug in
their system.
What happens is that the binary distribution for Python 2.5 (and 2.4.3 as well)
is build as a universal binary on OSX 10.4. This is why you see '-arch ppc -
arch x86' in the compiler invocation. This works correctly on 10.4 but not on
10.3.9, which is why distutils strips those arguments from the command-line
on 10.3 systems. That's all fine when you use the stock distutils, but numpy
uses custom build commands and those don't work correctly with a universal
build of python on 10.3.
The easiest way for you to get going again is open /Library/Frameworks/
Python.framework/Versions/2.5/lib/python2.5/config/Makefile in a text
editor. Remove '-arch ppc -arch i386 -isysroot /Developer/SDKs/
MacOSX10.4u.sdk' from the definition of BASECFLAGS and LDFLAGS and then
try to build numpy again
--
Comment By: David Strozzi (dstrozzi)
Date: 2006-09-22 18:35
Message:
Logged In: YES
user_id=1056922
Hi,
Python 2.5 installs, and idle runs, perfectly on my 10.3.9
system! Kudos to our noble MacOS builder! Looks like the
problem vanished.
I'm going to risk bugging people here about my inability to
compile numpy 1.0* (* = betas and current release candidate
1) on the same 10.3.9 system. The end of this post is a
dump of trying to install as per numpy directions. One line
is very suspicious:
C compiler: gcc -arch ppc -arch i386 -isysroot
/Developer/SDKs/MacOSX10.4u.sdk -fno-strict-aliasing
-Wno-long-double -no-cpp-precomp -mno-fused-madd -fno-common
-dynamic -DNDEBUG -g -O3
-arch pcc -arch i386?? Smells bad.
10.4u.sdk?? I have sys 10.3.9;
/Developer/SDKs/MacOSX10.3.0.sdk exists on my system, but
not 10.4u.
Right after this, I get the error:
gcc: cannot specify -o with -c or -S and multiple compilations
gcc 3.3 is my 'main' gcc, although I finked 4.0 but haven't
replaced my 'main' gcc with it.
Anyway, thoughts are greatly appreciated, both by me and
presumably the numpy people (who haven't replied to any of
my bug postings :) )
** The whole dump **
> python setup.py install
Running from numpy source directory.
F2PY Version 2_3198
blas_opt_info:
FOUND:
extra_link_args = ['-Wl,-framework', '-Wl,Accelerate']
define_macros = [('NO_ATLAS_INFO', 3)]
extra_compile_args = ['-faltivec',
'-I/System/Library
[ python-Bugs-1565919 ] sets missing from standard types list in ref
Bugs item #1565919, was opened at 2006-09-26 18:51 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=1565919&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: Open Resolution: None Priority: 6 Submitted By: Georg Brandl (gbrandl) Assigned to: Nobody/Anonymous (nobody) Summary: sets missing from standard types list in ref Initial Comment: Sets (and frozensets) are missing from http://docs.python.org/ref/types.html. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565919&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1565967 ] pyexpat produces fals parsing results in CharacterDataHandle
Bugs item #1565967, was opened at 2006-09-26 20:34 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=1565967&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: XML Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Michael Gebetsroither (einsteinmg) Assigned to: Nobody/Anonymous (nobody) Summary: pyexpat produces fals parsing results in CharacterDataHandle Initial Comment: hi, with bigger files pyexpat begins to split up some things parsed through CharacterDataHandler. c: "root-menu" pyexpat: "root-me" "nu" c: "TopLeft" pyexpat: "TopL" "eft" that strange results are also reproduseable on python2.4 greets -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565967&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1566086 ] RE (regular expression) matching stuck in loop
Bugs item #1566086, was opened at 2006-09-27 01:23 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=1566086&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: Regular Expressions Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Fabien Devaux (fabinator) Assigned to: Gustavo Niemeyer (niemeyer) Summary: RE (regular expression) matching stuck in loop Initial Comment: See the code: http://pastebin.ca/183613 the "finditer()" call don't seems to return. Playing with the re can bypass the problem but it looks like a bug. (I'm really sorry if I did something wrong and didn't notice) note: I can reproduce it with python2.5 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566086&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1565525 ] gc allowing tracebacks to eat up memory
Bugs item #1565525, was opened at 2006-09-26 06:58 Message generated for change (Comment added) made by ghazel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565525&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.5 Status: Open Resolution: None Priority: 5 Submitted By: Greg Hazel (ghazel) Assigned to: Nobody/Anonymous (nobody) Summary: gc allowing tracebacks to eat up memory Initial Comment: Attached is a file which demonstrates an oddity about traceback objects and the gc. The observed behaviour is that when the tuple from sys.exc_info() is stored on an object which is inside the local scope, the object, thus exc_info tuple, are not collected even when both leave scope. If you run the test with "s.e = sys.exc_info()" commented out, the observed memory footprint of the process quickly approaches and sits at 5,677,056 bytes. Totally reasonable. If you uncomment that line, the memory footprint climbs to 283,316,224 bytes quite rapidly. That's a two order of magnitude difference! If you uncomment the "gc.collect()" line, the process still hits 148,910,080 bytes. This was observed in production code, where exc_info tuples are saved for re-raising later to get the stack- appending behaviour tracebacks and 'raise' perform. The example includes a large array to simulate application state. I assume this is bad behaviour occurring because the traceback object holds frames, and those frames hold a reference to the local objects, thus the exc_info tuple itself, thus causing a circular reference which involves the entire stack. Either the gc needs to be improved to prevent this from growing so wildly, or the traceback objects need to (optionally?) hold frames which do not have references or have weak references instead. -- >Comment By: Greg Hazel (ghazel) Date: 2006-09-27 03:20 Message: Logged In: YES user_id=731668 I have read the exc_info suggestions before, but they have never made any difference. Neither change you suggest modifies the memory footprint behaviour in any way. Weakrefs might be slow, I offered them as an alternative to just removing the references entirely. I understand this might cause problems with existing code, but the current situation causes a problem which is more difficult to work around. Code that needs locals and globals can explicity store a reference to eat - it is impossible to dig in to the traceback object and remove those references. The use-case of storing the exc_info is fairly simple, for example: Two threads. One queues a task for the other to complete. That task fails an raises an exception. The exc_info is caught, passed back to the first thread, the exc_info is raised from there. The goal is to get the whole execution stack, which it does quite nicely, except that it has this terrible memory side effect. -- Comment By: Tim Peters (tim_one) Date: 2006-09-26 10:04 Message: Logged In: YES user_id=31435 Your memory bloat is mostly due to the d = range(10) line. Python has no problem collecting the cyclic trash, but you're creating 10 * 100 = 10 million integer objects hanging off trash cycles before invoking gc.collect(), and those integers require at least 10 million * 12 ~= 120MB all by themselves. Worse, memory allocated to "short" integers is both immortal and unbounded: it can be reused for /other/ integer objects, but it never goes away. Note that memory usage in your program remains low and steady if you force gc.collect() after every call to bar(). Then you only create 100K integers, instead of 10M, before the trash gets cleaned up. There is no simple-minded way to "repair" this, BTW. For example, /of course/ a frame has to reference all its locals, and moving to weak references for those instead would be insanely inefficient (among other, and deeper, problems). Note that the library reference manual warns against storing the result of exc_info() in a local variable (which you're /effectively/ doing, since the formal parameter `s` is a local variable within foo()), and suggests other approaches. Sorry, but I really couldn't tell from your description why you want to store this stuff in an instance attribute, so can't guess whether another more-or-less obvious approach would help. For example, no cyclic trash is created if you add this method to your class O: def get_traceback(self): self.e = sys.exc_info() and inside foo() invoke: s.get_traceback() instead of doing: s.e = sys.exc_info() Is that unreasonable? Perhaps simpler is to define a function like: def get_exc_info(): return sys.exc_info() and inside foo() d
[ python-Bugs-1565514 ] does not raise SystemError on too many nested blocks
Bugs item #1565514, was opened at 2006-09-25 23:10 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565514&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: Parser/Compiler Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Greg Hazel (ghazel) Assigned to: Nobody/Anonymous (nobody) Summary: does not raise SystemError on too many nested blocks Initial Comment: Simple script attached, in python 2.4.3 I get reasonable results: C:\>.\python24\python.exe nested.py File "nested.py", line 22 while 22: SystemError: too many statically nested blocks C:\> However in python 2.5 I get nothing: C:\>.\python25\python.exe nested.py C:\> Shouldn't the same error be raised? (Note that it's not executing the file, or the prints would occur). -- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-26 21:45 Message: Logged In: YES user_id=33168 The attached patch fixes the problem. I'm not so sure that the error should be a SystemError, but some exception should definitely be produced. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565514&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1566140 ] T_ULONG -> double rounding in PyMember_GetOne()
Bugs item #1566140, was opened at 2006-09-27 07:23 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=1566140&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.6 Status: Open Resolution: None Priority: 5 Submitted By: Piet Delport (pjdelport) Assigned to: Nobody/Anonymous (nobody) Summary: T_ULONG -> double rounding in PyMember_GetOne() Initial Comment: Problem: Python/structmember.c's PyMember_GetOne currently handles getting T_ULONG members as follows: case T_ULONG: v = PyLong_FromDouble((double) *(unsigned long*)addr); break; On platforms with 64-bit longs, the double won't have enough precision to hold big values without rounding. The fix should be simple: v = PyLong_FromUnsignedLong(*(unsigned long*)addr); -- Piet Delport <[EMAIL PROTECTED]> -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566140&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
