[ python-Bugs-1676321 ] scheduler.empty() in module sched appears broken
Bugs item #1676321, was opened at 2007-03-08 00:50 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=1676321&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mark (theshtat) Assigned to: Nobody/Anonymous (nobody) Summary: scheduler.empty() in module sched appears broken Initial Comment: In: Python 2.5 (r25:51918, Sep 19 2006, 08:49:13) [GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin The sched.scheduler.empty() method appears to be broken. Its implementation is: return not not self.queue Which returns true when the event queue is *not* empty. http://www.google.com/codesearch?hl=en&q=+file:sched.py+%22not+not%22+show:_EUH1sHctjI:SV8rbKB68UQ:wZlnTyplW4c&sa=N&cd=1&ct=rc&cs_p=http://svn.python.org/snapshots/python25.tar.bz2&cs_f=python/Lib/sched.py#a0 Other Python builds seem to have a correct implementation: http://www.google.com/codesearch?hl=en&q=+file:sched.py+%22len(self.queue)%22+show:tKxWDv9S6Xg:d-f-3CzYpHc:iU9xQ6L5s1s&sa=N&cd=1&ct=rc&cs_p=http://www.python.org/ftp/python/2.4.3/Python-2.4.3.tar.bz2&cs_f=Python-2.4.3/Lib/sched.py#a0 Thanks, Mark mayzenshtat at) gmail (dot com -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1676321&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1671411 ] python code fails with "MemoryError" on HP-UX 11.11 PA_RISC
Bugs item #1671411, was opened at 2007-03-01 05:27
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1671411&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: Performance
Group: None
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Private: No
Submitted By: shashi (shashikala)
Assigned to: Nobody/Anonymous (nobody)
Summary: python code fails with "MemoryError" on HP-UX 11.11 PA_RISC
Initial Comment:
Hi,
Python-2.5 code fails with "MemoryError". This is happening only on one
system, PA-RISC running HP-UX 11.11.Failing system has 12 GB of RAM installed,
non-failing system has 8 GB.
1) spark 9GB phys mem(Python is working fine)
2) stalker 12GB phys mem (that has problem with python 2.5 )
please assist me in this.
Thanks in advance
Shashi
--
>Comment By: Martin v. Löwis (loewis)
Date: 2007-03-08 10:19
Message:
Logged In: YES
user_id=21627
Originator: NO
If you think your problem is solved, then fine (you seem to have found a
work-around).
If Python raises a MemoryError, this is still a problem; it sholdn't
normally do that, and it should normally invoke garbage collection itself.
To analyse this further, we still would need a debug stack trace. However,
I'm closing this as "won't fix" now; if you ever feel like analysing it
further, and have data to help there, feel free to reopen the report.
--
Comment By: shashi (shashikala)
Date: 2007-03-08 04:57
Message:
Logged In: YES
user_id=1506183
Originator: YES
Hi ,
I added "import gc" and "gc.collect()" , it worked out fine , I dint get
any further MemoryError is this the correct approach , please let me know
about the same.
Thanks and Reagrds,
shashi
--
Comment By: Martin v. Löwis (loewis)
Date: 2007-03-01 22:34
Message:
Logged In: YES
user_id=21627
Originator: NO
Can you also provide a gdb/dbx backtrace of where the problem occurred?
--
Comment By: shashi (shashikala)
Date: 2007-03-01 12:47
Message:
Logged In: YES
user_id=1506183
Originator: YES
File Added: Pythonmemoryerror.txt
--
Comment By: Martin v. Löwis (loewis)
Date: 2007-03-01 07:38
Message:
Logged In: YES
user_id=21627
Originator: NO
This tracker is not about assistance. If at all, we need you to assist
us.
Can you please report more details, like stack traces, causes of the
crash, patches? If not, I think there is little we can do about this report
("it crashes" is pretty unspecific).
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1671411&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1676656 ] Stdlib reference is in italics
Bugs item #1676656, was opened at 2007-03-08 16:34 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1676656&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: Fixed Priority: 5 Private: No Submitted By: Bj�rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: Stdlib reference is in italics Initial Comment: The development version of the stdlib reference is messed up. All pages after this one http://docs.python.org/dev/lib/module-SocketServer.html has all the text in italics. -- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-08 17:50 Message: Logged In: YES user_id=849994 Originator: NO The problem was that \em sets italics for the whole LaTeX "scope" while \emph does that only for the following argument. Fixed in rev. 54220, 54221 (2.5) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1676656&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1676656 ] Stdlib reference is in italics
Bugs item #1676656, was opened at 2007-03-08 17: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=1676656&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 Private: No Submitted By: Bj�rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: Stdlib reference is in italics Initial Comment: The development version of the stdlib reference is messed up. All pages after this one http://docs.python.org/dev/lib/module-SocketServer.html has all the text in italics. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1676656&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1514617 ] evaluated code filename changed to instead of ?
Bugs item #1514617, was opened at 2006-06-29 16:07
Message generated for change (Comment added) made by collinwinter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1514617&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: Closed
>Resolution: Wont Fix
Priority: 5
Private: No
Submitted By: James Y Knight (foom)
Assigned to: Nobody/Anonymous (nobody)
Summary: evaluated code filename changed to instead of ?
Initial Comment:
It seems as though the default filename for evaluated changed from "?" to
"". Was this intentional? (it's causing some test failures for me.
The tests are correctable of course, but it doesn't seem to be an obvious
improvement in behavior, so if it wasn't intentional, perhaps it should be
changed back.)
Python 2.3.5 (#1, Mar 20 2005, 20:38:20)
[GCC 3.3 20030304 (Apple Computer, Inc. build 1809)] on darwin
>>> eval("0/0")
Traceback (most recent call last):
File "", line 1, in ?
File "", line 0, in ?
Python 2.5b1 (trunk:47096, Jun 25 2006, 23:18:21)
[GCC 4.0.0 20041026 (Apple Computer, Inc. build 4061)] on darwin
>>> eval("0/0")
Traceback (most recent call last):
File "", line 1, in
File "", line 1, in
ZeroDivisionError: integer division or modulo by zero
--
>Comment By: Collin Winter (collinwinter)
Date: 2007-03-08 13:18
Message:
Logged In: YES
user_id=1344176
Originator: NO
1) An interpreter session is essentially a module that the user types in,
one statement at a time.
2) "?" tells me considerably less about where the error occurred than does
"". "?" could mean anything.
3) Since Python 2.5 has already been released with the objected-to
behavior, I'd say it's incredibly unlikely that this change will be
reverted.
--
Comment By: Jp Calderone (kuran)
Date: 2006-07-02 16:20
Message:
Logged In: YES
user_id=366566
Also see
https://sourceforge.net/tracker/?func=detail&aid=1512007&group_id=5470&atid=305470
for a patch to revert to the old behavior.
--
Comment By: Jp Calderone (kuran)
Date: 2006-07-02 16:18
Message:
Logged In: YES
user_id=366566
Note that in the example James included, the code is /not/
in a module.
A clear improvement to me would be to say something like
or in the case James pasted and
for the case of top-level code.
"" is about as information-free as "?".
--
Comment By: Collin Winter (collinwinter)
Date: 2006-07-01 14:26
Message:
Logged In: YES
user_id=1344176
For me, this is indeed an obvious improvement in behaviour.
"" is a much clearer indicator of where the code in
question is located; using "?" could mean that it's anywhere.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1514617&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1676321 ] scheduler.empty() in module sched appears broken
Bugs item #1676321, was opened at 2007-03-08 08:50 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1676321&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mark (theshtat) >Assigned to: Raymond Hettinger (rhettinger) Summary: scheduler.empty() in module sched appears broken Initial Comment: In: Python 2.5 (r25:51918, Sep 19 2006, 08:49:13) [GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin The sched.scheduler.empty() method appears to be broken. Its implementation is: return not not self.queue Which returns true when the event queue is *not* empty. http://www.google.com/codesearch?hl=en&q=+file:sched.py+%22not+not%22+show:_EUH1sHctjI:SV8rbKB68UQ:wZlnTyplW4c&sa=N&cd=1&ct=rc&cs_p=http://svn.python.org/snapshots/python25.tar.bz2&cs_f=python/Lib/sched.py#a0 Other Python builds seem to have a correct implementation: http://www.google.com/codesearch?hl=en&q=+file:sched.py+%22len(self.queue)%22+show:tKxWDv9S6Xg:d-f-3CzYpHc:iU9xQ6L5s1s&sa=N&cd=1&ct=rc&cs_p=http://www.python.org/ftp/python/2.4.3/Python-2.4.3.tar.bz2&cs_f=Python-2.4.3/Lib/sched.py#a0 Thanks, Mark mayzenshtat at) gmail (dot com -- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-08 18:24 Message: Logged In: YES user_id=849994 Originator: NO This was your change, Raymond. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1676321&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1676321 ] scheduler.empty() in module sched appears broken
Bugs item #1676321, was opened at 2007-03-08 03:50 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1676321&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Mark (theshtat) Assigned to: Raymond Hettinger (rhettinger) Summary: scheduler.empty() in module sched appears broken Initial Comment: In: Python 2.5 (r25:51918, Sep 19 2006, 08:49:13) [GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin The sched.scheduler.empty() method appears to be broken. Its implementation is: return not not self.queue Which returns true when the event queue is *not* empty. http://www.google.com/codesearch?hl=en&q=+file:sched.py+%22not+not%22+show:_EUH1sHctjI:SV8rbKB68UQ:wZlnTyplW4c&sa=N&cd=1&ct=rc&cs_p=http://svn.python.org/snapshots/python25.tar.bz2&cs_f=python/Lib/sched.py#a0 Other Python builds seem to have a correct implementation: http://www.google.com/codesearch?hl=en&q=+file:sched.py+%22len(self.queue)%22+show:tKxWDv9S6Xg:d-f-3CzYpHc:iU9xQ6L5s1s&sa=N&cd=1&ct=rc&cs_p=http://www.python.org/ftp/python/2.4.3/Python-2.4.3.tar.bz2&cs_f=Python-2.4.3/Lib/sched.py#a0 Thanks, Mark mayzenshtat at) gmail (dot com -- >Comment By: Raymond Hettinger (rhettinger) Date: 2007-03-08 14:25 Message: Logged In: YES user_id=80475 Originator: NO Fixed in revs 54224 and 54225. Thanks for the bug report. -- Comment By: Georg Brandl (gbrandl) Date: 2007-03-08 13:24 Message: Logged In: YES user_id=849994 Originator: NO This was your change, Raymond. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1676321&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1673403 ] date-datetime comparison doesn't work
Bugs item #1673403, was opened at 2007-03-04 06:51 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1673403&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 Private: No Submitted By: Jon Ribbens (jribbens) Assigned to: Nobody/Anonymous (nobody) Summary: date-datetime comparison doesn't work Initial Comment: Summary: bug #1028306 was not a bug, but the fix for it introduced one Comparing a date to a datetime currently throws an exception. This makes no sense. In what way is: datetime(2006, 1, 1, 0, 0, 0) < date(2007, 1, 1) not a perfectly reasonable and well-defined comparison? Throwing an exception here violates the "Principle of Least Surprise" to a considerable degree. Obviously some slight ambiguity arises if the date and the datetime differ only in the time part. There are two sensible responses in this situation that I can see: Treat dates as if they have a time-part of midnight. This is my preferred solution, and it is already what the datetime module does, for example, when subtracting two dates. Treat dates as if they refer to the entire day, i.e. if the date and datetime differ only in the time part then they are equal. This is consistent but becomes confusing in other situations such as when subtracting dates. -- >Comment By: Collin Winter (collinwinter) Date: 2007-03-08 15:55 Message: Logged In: YES user_id=1344176 Originator: NO I think this warrants discussion on python-dev (http://mail.python.org/mailman/listinfo/python-dev) as to which of the two date interpretations to pick. Please post a description of the problem there and ask for suggestions. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1673403&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1673403 ] date-datetime comparison doesn't work
Bugs item #1673403, was opened at 2007-03-04 06:51 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1673403&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 Private: No Submitted By: Jon Ribbens (jribbens) >Assigned to: Tim Peters (tim_one) Summary: date-datetime comparison doesn't work Initial Comment: Summary: bug #1028306 was not a bug, but the fix for it introduced one Comparing a date to a datetime currently throws an exception. This makes no sense. In what way is: datetime(2006, 1, 1, 0, 0, 0) < date(2007, 1, 1) not a perfectly reasonable and well-defined comparison? Throwing an exception here violates the "Principle of Least Surprise" to a considerable degree. Obviously some slight ambiguity arises if the date and the datetime differ only in the time part. There are two sensible responses in this situation that I can see: Treat dates as if they have a time-part of midnight. This is my preferred solution, and it is already what the datetime module does, for example, when subtracting two dates. Treat dates as if they refer to the entire day, i.e. if the date and datetime differ only in the time part then they are equal. This is consistent but becomes confusing in other situations such as when subtracting dates. -- >Comment By: Raymond Hettinger (rhettinger) Date: 2007-03-08 16:09 Message: Logged In: YES user_id=80475 Originator: NO Tim, any thoughts? -- Comment By: Collin Winter (collinwinter) Date: 2007-03-08 15:55 Message: Logged In: YES user_id=1344176 Originator: NO I think this warrants discussion on python-dev (http://mail.python.org/mailman/listinfo/python-dev) as to which of the two date interpretations to pick. Please post a description of the problem there and ask for suggestions. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1673403&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1676656 ] Stdlib reference is in italics
Bugs item #1676656, was opened at 2007-03-08 17:34 Message generated for change (Comment added) made by sonderblade You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1676656&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: Fixed Priority: 5 Private: No Submitted By: Bj�rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: Stdlib reference is in italics Initial Comment: The development version of the stdlib reference is messed up. All pages after this one http://docs.python.org/dev/lib/module-SocketServer.html has all the text in italics. -- >Comment By: Bj�rn Lindqvist (sonderblade) Date: 2007-03-08 22:30 Message: Logged In: YES user_id=51702 Originator: YES That was FAST. Thanks! -- Comment By: Georg Brandl (gbrandl) Date: 2007-03-08 18:50 Message: Logged In: YES user_id=849994 Originator: NO The problem was that \em sets italics for the whole LaTeX "scope" while \emph does that only for the following argument. Fixed in rev. 54220, 54221 (2.5) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1676656&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1637850 ] make_table in difflib does not work with unicode
Bugs item #1637850, was opened at 2007-01-17 11:22 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1637850&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: y-unno (y-unno) >Assigned to: Raymond Hettinger (rhettinger) Summary: make_table in difflib does not work with unicode Initial Comment: make_table function in difflib.HtmlDiff does not work correctly when input strings are unicode. This is because the library uses cStringIO.StringIO classes, and cStringIO.StringIO returns strings encoded by the default encoding. When the default encoding is 'ascii', for example, this behaviour becomes a problem because some unicode characters cannot be encoded in 'ascii'. So, please change cStringIO to StringIO in difflib.py. When I use StringIO in difflib.py, this function returns unicode strings and no problems occured. This problem occured in Python 2.5/2.4 on Windows XP. -- >Comment By: Raymond Hettinger (rhettinger) Date: 2007-03-08 16:35 Message: Logged In: YES user_id=80475 Originator: NO Fixed in revs 54229 and 54230. It wasn't necessary to use StringIO at all. A simple list of strings and join works fine (and handles unicode transparently). -- Comment By: Georg Brandl (gbrandl) Date: 2007-01-17 16:13 Message: Logged In: YES user_id=849994 Originator: NO I don't know. Perhaps we should rather fix cStringIO to accept Unicode strings. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1637850&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-1624674 ] webbrowser.open_new() suggestion
Feature Requests item #1624674, was opened at 2006-12-29 19:03
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1624674&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Imre Péntek (imi1984)
Assigned to: Georg Brandl (gbrandl)
Summary: webbrowser.open_new() suggestion
Initial Comment:
Hello,
under Linux if I use
webbrowser.open_new('...') a konqueror gets invoked. At the time when invoking
konqueror (maybe you probe first, but anyways) you assume that user has a
properly installed kde. But if you assume the user has a properly installed KDE
you have a better opportunity to open a webpage, even in the browser preferred
by the user -- no matter really what it is. Try this one:
kfmclient exec http://sourceforge.net/
using this one the client associated with .html in kcontrol gets invoked.
I suppose that (becouse of the ability to customize the browser) this way would
be better if available than guessing which browser would the user prefer.
--
Comment By: Mark Roberts (mark-roberts)
Date: 2007-01-14 18:08
Message:
Logged In: YES
user_id=1591633
Originator: NO
A quick look at the code makes me think that it does try to run kfmclient
first. Specifically, line 351 of webbrowser.py tries kfmclient, while like
line 363 of webbrowser.py opens konqueror.
I don't really run KDE, Gnome, or Windows, so I'm not a lot of help for
testing this for you. I can, however, tell you that it does the "right
thing" for me, in that it opens Firefox. When I did Python development on
Windows, it also "did the right thing" there.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1624674&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1628987 ] inspect trouble when source file changes
Bugs item #1628987, was opened at 2007-01-05 13:43 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1628987&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 Private: No Submitted By: phil (philipdumont) Assigned to: Nobody/Anonymous (nobody) Summary: inspect trouble when source file changes Initial Comment: backtrace (relevant outer frames only): File "/path/to/myfile", line 1198, in get_hook_name for frame_record in inspect.stack(): File "/usr/mbench2.2/lib/python2.4/inspect.py", line 819, in stack return getouterframes(sys._getframe(1), context) File "/usr/mbench2.2/lib/python2.4/inspect.py", line 800, in getouterframes framelist.append((frame,) + getframeinfo(frame, context)) File "/usr/mbench2.2/lib/python2.4/inspect.py", line 775, in getframeinfo lines, lnum = findsource(frame) File "/usr/mbench2.2/lib/python2.4/inspect.py", line 437, in findsource if pat.match(lines[lnum]): break IndexError: list index out of range Based on a quick look at the inspect code, I think this happens when you: - Start python and load a module - While it's running, edit the source file for the module (before inspect tries to look into it). - Call a routine in the edited module that will lead to a call to inspect.stack(). During an inspect.stack() call, inspect will open source files to get the source code for the routines on the stack. If the source file that is opened doesn't match the byte compiled code that's being run, there are problems. Inspect caches the files it reads (using the linecache module), so if the file gets cached before it is edited, nothing should go wrong. But if the source file is edited after the module is loaded and before inspect has a chance to cache the source, you're out of luck. Of course, this shouldn't be a problem in production code, but it has bit us more than once in a development environment. Seems like it would be easy to avoid by just comparing the timestamps on the source/object files. If the source file is newer, just behave the same as if it wasn't there. Attached is a stupid little python script that reproduces the problem. -- >Comment By: Collin Winter (collinwinter) Date: 2007-03-08 16:19 Message: Logged In: YES user_id=1344176 Originator: NO Could you possibly work up a patch demonstrating exactly what you're proposing with the "comparing the timestamps" solution? That seems like a lot of complication for such a rare issue, but I'd be interested in seeing a patch all the same. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1628987&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1676121 ] Problem linking to readline lib on x86(64) Solaris
Bugs item #1676121, was opened at 2007-03-07 23:07 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1676121&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alexander Belopolsky (belopolsky) Assigned to: Nobody/Anonymous (nobody) Summary: Problem linking to readline lib on x86(64) Solaris Initial Comment: Configuring with ./configure --with-gcc="gcc -m64 -L/usr/sfw/lib/64 -R/usr/sfw/lib/64" where 64bit libreadline is found in /usr/sfw/lib/64, configure script fails to realize that readline lib is present. I was able to fix the problem by editing config script manually as follows: $ diff configure~ configure 20744c20744 < if test "$ac_cv_have_readline_readline" = no --- > if test "$ac_cv_lib_readline_readline" = no 20747c20747 < echo "$as_me:$LINENO: checking for readline in -ltermcap" >&5 --- > echo "$as_me:$LINENO: checking for readline in -lreadline -ltermcap" >&5 20753c20753 < LIBS="-ltermcap $LIBS" --- > LIBS="-lreadline -ltermcap $LIBS" A proper fix would be to change configure.in, but I don't know enough about autoconf to submit a proper patch. -- >Comment By: Martin v. Löwis (loewis) Date: 2007-03-08 23:18 Message: Logged In: YES user_id=21627 Originator: NO The right solution in this case is to edit Modules/Setup -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1676121&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1676121 ] Problem linking to readline lib on x86(64) Solaris
Bugs item #1676121, was opened at 2007-03-07 17:07 Message generated for change (Comment added) made by belopolsky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1676121&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alexander Belopolsky (belopolsky) Assigned to: Nobody/Anonymous (nobody) Summary: Problem linking to readline lib on x86(64) Solaris Initial Comment: Configuring with ./configure --with-gcc="gcc -m64 -L/usr/sfw/lib/64 -R/usr/sfw/lib/64" where 64bit libreadline is found in /usr/sfw/lib/64, configure script fails to realize that readline lib is present. I was able to fix the problem by editing config script manually as follows: $ diff configure~ configure 20744c20744 < if test "$ac_cv_have_readline_readline" = no --- > if test "$ac_cv_lib_readline_readline" = no 20747c20747 < echo "$as_me:$LINENO: checking for readline in -ltermcap" >&5 --- > echo "$as_me:$LINENO: checking for readline in -lreadline -ltermcap" >&5 20753c20753 < LIBS="-ltermcap $LIBS" --- > LIBS="-lreadline -ltermcap $LIBS" A proper fix would be to change configure.in, but I don't know enough about autoconf to submit a proper patch. -- >Comment By: Alexander Belopolsky (belopolsky) Date: 2007-03-08 17:25 Message: Logged In: YES user_id=835142 Originator: YES Can you explain how to edit Module/Setup to solve this problem? Note that the problem that I see comes before modules are built. In fact it comes even before make. In any case, I think the check for $ac_cv_have_readline_readline" = no instead of "$ac_cv_lib_readline_readline" = no looks like a typo in configure.in. And looking for readline in libtermcap does not look like sound logic either. -- Comment By: Martin v. Löwis (loewis) Date: 2007-03-08 17:18 Message: Logged In: YES user_id=21627 Originator: NO The right solution in this case is to edit Modules/Setup -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1676121&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1666807 ] Incorrect file path reported by inspect.getabsfile()
Bugs item #1666807, was opened at 2007-02-23 02:08 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1666807&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 Private: No Submitted By: Fernando P�rez (fer_perez) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect file path reported by inspect.getabsfile() Initial Comment: The following code demonstrates the problem succinctly: ### import inspect,sys print 'Version info:',sys.version_info print f1 = inspect.getabsfile(inspect) f2 = inspect.getabsfile(inspect.iscode) print 'File for `inspect` :',f1 print 'File for `inspect.iscode`:',f2 print 'Do these match?',f1==f2 if f1==f2: print 'OK' else: print 'BUG - this is a bug in this version of Python' ### EOF Running this on my system (Linux, Ubuntu Edgy) with 2.3, 2.4 and 2.5 produces: tlon[bin]> ./python2.3 ~/code/python/inspect_bug.py Version info: (2, 3, 6, 'final', 0) File for `inspect` : /home/fperez/tmp/local/lib/python2.3/inspect.py File for `inspect.iscode`: /home/fperez/tmp/local/lib/python2.3/inspect.py Do these match? True OK tlon[bin]> python2.4 ~/code/python/inspect_bug.py Version info: (2, 4, 4, 'candidate', 1) File for `inspect` : /usr/lib/python2.4/inspect.py File for `inspect.iscode`: /home/fperez/tmp/local/bin/inspect.py Do these match? False BUG - this is a bug in this version of Python tlon[bin]> python2.5 ~/code/python/inspect_bug.py Version info: (2, 5, 0, 'final', 0) File for `inspect` : /usr/lib/python2.5/inspect.py File for `inspect.iscode`: /home/fperez/tmp/local/bin/inspect.py Do these match? False BUG - this is a bug in this version of Python ### The problem arises in the fact that inspect relies, for functions (at least), on the func_code.co_filename attribute to contain a complete path. This changed between 2.3 and 2.4, but the inspect module was never updated. This code: ### import inspect,sys print 'Python version info:',sys.version_info print 'File info for `inspect.iscode function`:' print ' ',inspect.iscode.func_code.co_filename print ### EOF shows the problem: tlon[bin]> ./python2.3 ~/code/python/inspect_bug_details.py Python version info: (2, 3, 6, 'final', 0) File info for `inspect.iscode function`: /home/fperez/tmp/local//lib/python2.3/inspect.py tlon[bin]> python2.5 ~/code/python/inspect_bug_details.py Python version info: (2, 5, 0, 'final', 0) File info for `inspect.iscode function`: inspect.py ### (2.4 has the same issue). Basically, if the func_code.co_filename attribute now stores only the final filename without the full path, then the logic in the inspect module needs to be changed to accomodate this so that correct paths are reported to the user like they were in the 2.3 days. -- >Comment By: Collin Winter (collinwinter) Date: 2007-03-08 19:04 Message: Logged In: YES user_id=1344176 Originator: NO I haven't been able to reproduce this with Python 2.3.5, 2.4.4, 2.5.0 or SVN HEAD (all hand-built on Slackware Linux). What options are you providing to ./configure? -- Comment By: Fernando P�rez (fer_perez) Date: 2007-02-24 02:22 Message: Logged In: YES user_id=395388 Originator: YES No, in my case the original tests with 2.4 and 2.5 were done with the Ubuntu-provided (Edgy) versions, unmodified from their apt-get install state. But your comments are interesting. I just rebuilt 2.5 by hand from source on the same system, and this is what I get: tlon[bin]> ./python2.5 ~/code/python/inspect_bug.py Version info: (2, 5, 0, 'final', 0) File for `inspect` : /home/fperez/tmp/local/lib/python2.5/inspect.py File for `inspect.iscode`: /home/fperez/tmp/local/lib/python2.5/inspect.py Do these match? True OK tlon[bin]> ./python2.5 ~/code/python/inspect_bug_details.py Python version info: (2, 5, 0, 'final', 0) File info for `inspect.iscode function`: /home/fperez/tmp/local//lib/python2.5/inspect.py So basically it seems that there's a difference in the value of the func_code.co_filename object attribute depending on how the build was made. At this point I'm not really sure if this should be considered a Python bug or an Ubuntu one... Perhaps the Python build process can be made more robust, I simply don't know. But the end-user behavior /is/ a bug, so it would be nice to know how to fix it. Thanks for your info! -- Comment By: Jerry Seutter (jseutter) Date: 2007-02-24 01:51 Message: Logged In: YES user_id=1727609 Originator: NO Hi, On a custom-compiled Python 2.5 o
[ python-Bugs-1625381 ] re module documentation on search/match is unclear
Bugs item #1625381, was opened at 2006-12-31 11:42
Message generated for change (Comment added) made by collinwinter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1625381&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
Private: No
Submitted By: Richard Boulton (richardb)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: re module documentation on search/match is unclear
Initial Comment:
Section 4.2.2 ("Matching vs Searching") of the Python Library Reference covers
the match and search methods of regular expression objects. However, it
doesn't begin by describing the difference between these methods. Each time I
try to remember which way round match and search are, it takes several minutes
of checking the documentation to work out which is which. I suggest that the
first paragraph of the section is replaced with the following text (in two
paragraphs), to make the distinction between the methods clearer:
"Python offers two different primitive operations based on regular expressions:
match and search. match() checks for a match at the beginning of the search
string, whereas search() checks for a match anywhere in the string.
If you want something equivalent to Perl's semantics, the search operation is
what you're looking for. See the search() function and corresponding method of
compiled regular expression objects."
--
>Comment By: Collin Winter (collinwinter)
Date: 2007-03-08 19:21
Message:
Logged In: YES
user_id=1344176
Originator: NO
+1 on the general idea, though I'd change your "match() checks for a match
at the beginning..." to "match() checks for a match starting at the
beginning...". I'd also like to drop the reference to Perl entirely; saying
that I should look to search() for Perl's semantics makes it sound like
match() doesn't support PCREs.
Fred, any thoughts?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1625381&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-1625576 ] add ability to specify name to os.fdopen
Feature Requests item #1625576, was opened at 2007-01-01 02:19 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1625576&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Python Library >Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mark Diekhans (diekhans) Assigned to: Nobody/Anonymous (nobody) Summary: add ability to specify name to os.fdopen Initial Comment: Please add an optional argument to os.fdopen() to specify the name field in the resulting file object. This would allow for a more useful name than: '...> -- >Comment By: Collin Winter (collinwinter) Date: 2007-03-08 20:02 Message: Logged In: YES user_id=1344176 Originator: NO Changing this to a "feature request", since it's certainly not a bug. I can see both sides of this; on the one hand, isn't the most descriptive string and doesn't give you an idea where it came from; on the other hand, you lose the distinction between files opened by filename and those by file descriptor. If the purpose is to distinguish between fdopen()'d files, what if fdopen() was changed so that the filename matched , where \d+ is the file descriptor passed to fdopen()? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1625576&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1666807 ] Incorrect file path reported by inspect.getabsfile()
Bugs item #1666807, was opened at 2007-02-23 07:08 Message generated for change (Comment added) made by fer_perez You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1666807&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 Private: No Submitted By: Fernando P�rez (fer_perez) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect file path reported by inspect.getabsfile() Initial Comment: The following code demonstrates the problem succinctly: ### import inspect,sys print 'Version info:',sys.version_info print f1 = inspect.getabsfile(inspect) f2 = inspect.getabsfile(inspect.iscode) print 'File for `inspect` :',f1 print 'File for `inspect.iscode`:',f2 print 'Do these match?',f1==f2 if f1==f2: print 'OK' else: print 'BUG - this is a bug in this version of Python' ### EOF Running this on my system (Linux, Ubuntu Edgy) with 2.3, 2.4 and 2.5 produces: tlon[bin]> ./python2.3 ~/code/python/inspect_bug.py Version info: (2, 3, 6, 'final', 0) File for `inspect` : /home/fperez/tmp/local/lib/python2.3/inspect.py File for `inspect.iscode`: /home/fperez/tmp/local/lib/python2.3/inspect.py Do these match? True OK tlon[bin]> python2.4 ~/code/python/inspect_bug.py Version info: (2, 4, 4, 'candidate', 1) File for `inspect` : /usr/lib/python2.4/inspect.py File for `inspect.iscode`: /home/fperez/tmp/local/bin/inspect.py Do these match? False BUG - this is a bug in this version of Python tlon[bin]> python2.5 ~/code/python/inspect_bug.py Version info: (2, 5, 0, 'final', 0) File for `inspect` : /usr/lib/python2.5/inspect.py File for `inspect.iscode`: /home/fperez/tmp/local/bin/inspect.py Do these match? False BUG - this is a bug in this version of Python ### The problem arises in the fact that inspect relies, for functions (at least), on the func_code.co_filename attribute to contain a complete path. This changed between 2.3 and 2.4, but the inspect module was never updated. This code: ### import inspect,sys print 'Python version info:',sys.version_info print 'File info for `inspect.iscode function`:' print ' ',inspect.iscode.func_code.co_filename print ### EOF shows the problem: tlon[bin]> ./python2.3 ~/code/python/inspect_bug_details.py Python version info: (2, 3, 6, 'final', 0) File info for `inspect.iscode function`: /home/fperez/tmp/local//lib/python2.3/inspect.py tlon[bin]> python2.5 ~/code/python/inspect_bug_details.py Python version info: (2, 5, 0, 'final', 0) File info for `inspect.iscode function`: inspect.py ### (2.4 has the same issue). Basically, if the func_code.co_filename attribute now stores only the final filename without the full path, then the logic in the inspect module needs to be changed to accomodate this so that correct paths are reported to the user like they were in the 2.3 days. -- >Comment By: Fernando P�rez (fer_perez) Date: 2007-03-09 02:00 Message: Logged In: YES user_id=395388 Originator: YES As I mentioned, on hand-built Pythons I don't get the bug at all. So it may be a problem with how Ubuntu builds its Python, since I can reproduce the problem with both 2.4 and 2.5, but only with the default ones provided by Ubuntu Edgy. I don't know enough about their packaging system to know how to retrieve build info. There may be something odd in their build, but it would be nice if this simply couldn't happen at all. If anyone knows how to retrieve the relevant info from an ubuntu build, I'll be happy to try and provide it. -- Comment By: Collin Winter (collinwinter) Date: 2007-03-09 00:04 Message: Logged In: YES user_id=1344176 Originator: NO I haven't been able to reproduce this with Python 2.3.5, 2.4.4, 2.5.0 or SVN HEAD (all hand-built on Slackware Linux). What options are you providing to ./configure? -- Comment By: Fernando P�rez (fer_perez) Date: 2007-02-24 07:22 Message: Logged In: YES user_id=395388 Originator: YES No, in my case the original tests with 2.4 and 2.5 were done with the Ubuntu-provided (Edgy) versions, unmodified from their apt-get install state. But your comments are interesting. I just rebuilt 2.5 by hand from source on the same system, and this is what I get: tlon[bin]> ./python2.5 ~/code/python/inspect_bug.py Version info: (2, 5, 0, 'final', 0) File for `inspect` : /home/fperez/tmp/local/lib/python2.5/inspect.py File for `inspect.iscode`: /home/fperez/tmp/local/lib/python2.5/inspect.py Do these match? True OK tlon[bin]> ./python2.5 ~/code/python/inspect_bug_details.py Python version info: (2, 5, 0, 'final', 0) File info for `inspec
[ python-Feature Requests-1625576 ] add ability to specify name to os.fdopen
Feature Requests item #1625576, was opened at 2007-01-01 07:19 Message generated for change (Comment added) made by diekhans You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1625576&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mark Diekhans (diekhans) Assigned to: Nobody/Anonymous (nobody) Summary: add ability to specify name to os.fdopen Initial Comment: Please add an optional argument to os.fdopen() to specify the name field in the resulting file object. This would allow for a more useful name than: '...> -- >Comment By: Mark Diekhans (diekhans) Date: 2007-03-09 04:58 Message: Logged In: YES user_id=66101 Originator: YES thanks collin; that was suppose to be a feature request! doesn't really help. For end user message, a file name is very use, the fact that it is opened by fdopen is not. If one is debugging a program and knows the file name, one can usually figure out where it is opened, the file number, or for that matter that fdopen was used is less useful. The particular case that prompted this request was the need use os.open to get non-blocking mode and then pass the result to fdopen. However this now loses the file name, replacing it with something not useful. thanks. -- Comment By: Collin Winter (collinwinter) Date: 2007-03-09 01:02 Message: Logged In: YES user_id=1344176 Originator: NO Changing this to a "feature request", since it's certainly not a bug. I can see both sides of this; on the one hand, isn't the most descriptive string and doesn't give you an idea where it came from; on the other hand, you lose the distinction between files opened by filename and those by file descriptor. If the purpose is to distinguish between fdopen()'d files, what if fdopen() was changed so that the filename matched , where \d+ is the file descriptor passed to fdopen()? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1625576&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-1625576 ] add ability to specify name to os.fdopen
Feature Requests item #1625576, was opened at 2007-01-01 07:19 Message generated for change (Comment added) made by diekhans You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1625576&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mark Diekhans (diekhans) Assigned to: Nobody/Anonymous (nobody) Summary: add ability to specify name to os.fdopen Initial Comment: Please add an optional argument to os.fdopen() to specify the name field in the resulting file object. This would allow for a more useful name than: '...> -- >Comment By: Mark Diekhans (diekhans) Date: 2007-03-09 05:00 Message: Logged In: YES user_id=66101 Originator: YES p.s. I will happy implement the change. -- Comment By: Mark Diekhans (diekhans) Date: 2007-03-09 04:58 Message: Logged In: YES user_id=66101 Originator: YES thanks collin; that was suppose to be a feature request! doesn't really help. For end user message, a file name is very use, the fact that it is opened by fdopen is not. If one is debugging a program and knows the file name, one can usually figure out where it is opened, the file number, or for that matter that fdopen was used is less useful. The particular case that prompted this request was the need use os.open to get non-blocking mode and then pass the result to fdopen. However this now loses the file name, replacing it with something not useful. thanks. -- Comment By: Collin Winter (collinwinter) Date: 2007-03-09 01:02 Message: Logged In: YES user_id=1344176 Originator: NO Changing this to a "feature request", since it's certainly not a bug. I can see both sides of this; on the one hand, isn't the most descriptive string and doesn't give you an idea where it came from; on the other hand, you lose the distinction between files opened by filename and those by file descriptor. If the purpose is to distinguish between fdopen()'d files, what if fdopen() was changed so that the filename matched , where \d+ is the file descriptor passed to fdopen()? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1625576&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1676971 ] Complex OverflowError has a typo
Bugs item #1676971, was opened at 2007-03-09 05: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=1676971&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: John Dong (jdong2002) Assigned to: Nobody/Anonymous (nobody) Summary: Complex OverflowError has a typo Initial Comment: >>> (1-24j)**34324324 Traceback (most recent call last): File "", line 1, in OverflowError: complex exponentiaion Exponentiation is spelled incorrectly. This has been reproduced on Python 2.4 and 2.5. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1676971&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1676971 ] Complex OverflowError has a typo
Bugs item #1676971, was opened at 2007-03-08 21:21 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1676971&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: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: John Dong (jdong2002) >Assigned to: Neal Norwitz (nnorwitz) Summary: Complex OverflowError has a typo Initial Comment: >>> (1-24j)**34324324 Traceback (most recent call last): File "", line 1, in OverflowError: complex exponentiaion Exponentiation is spelled incorrectly. This has been reproduced on Python 2.4 and 2.5. -- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-08 22:02 Message: Logged In: YES user_id=33168 Originator: NO Thanks for the report! Committed revision 54237. Committed revision 54238. (2.5) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1676971&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1675511 ] Python still uses broken -xcode option on Solaris/x86
Bugs item #1675511, was opened at 2007-03-07 08:54 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675511&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: 5 Private: No Submitted By: Carson Gaspar (cgaspar) Assigned to: Nobody/Anonymous (nobody) Summary: Python still uses broken -xcode option on Solaris/x86 Initial Comment: Bug 1561333 was submitted against Python 2.4 with no action, so I'm submitting a new bug against 2.5 in the hopes that someone will read it... text updated with minor corrections. Python 2.5, Solaris x86 10 Update 3, Sun Studio 11 xcode=pic32 option is not supported on Solaris x86 Sun C . Python's ./configure script on Solaris systems sets the compiler flag -xcode=pic32 when any compiler other than gcc is used. Unfortunately, the -xcode flag is only available in the sparc version of Sun C. The x86 version of Sun C does not support the -xcode option at all and generates an error that an illegal option was used. The portable flag supported on both platforms to use independent 32-bit addressing is -KPIC. -- >Comment By: Martin v. Löwis (loewis) Date: 2007-03-09 08:08 Message: Logged In: YES user_id=21627 Originator: NO One problem is that the proposed change is incorrect. According to the C User's Guide of Sun Studio 11 (document 819-3688-10), -KPIC is an obsolete option on SPARC, and should be replaced with -xcode=pic32 (section A.1.15). So I think a patch should be architecture-specific. Can somebody come up with a patch that does that? -- Comment By: James Lick (jlick) Date: 2007-03-07 09:34 Message: Logged In: YES user_id=673069 Originator: NO Perhaps I was unclear in bug #1561333 that this resulted in only a warning. Actually the build will fail because of the incorrect flag. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675511&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1675026 ] Redirect cause invalid descriptor error
Bugs item #1675026, was opened at 2007-03-06 16:58
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675026&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.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jean-Marc Ranger (jmranger)
Assigned to: Nobody/Anonymous (nobody)
Summary: Redirect cause invalid descriptor error
Initial Comment:
Test setup:
- Windows 2000 (french)
- Python 2.5 (reproducible with 2.4.2 and 2.4.4)
One python source file, test.py:
---
import os
print os.system("echo test")
---
Console output:
---
C:\test>test.py
test
0
C:\test>test.py > test.log
Descripteur non valide
C:\test>type test.log
0
C:\test>c:\python25\python test.py
test
0
C:\test>c:\python25\python test.py > test.log
C:\test>type test.log
test
0
C:\test>
---
The "Descripteur non valide" error would translate to "invalid file descriptor".
I would expect the 2nd call to perform the same way the 4th does.
--
>Comment By: Martin v. Löwis (loewis)
Date: 2007-03-09 08:10
Message:
Logged In: YES
user_id=21627
Originator: NO
Do you have an explanation for the cause of the problem?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675026&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
