[ python-Bugs-1235266 ] debug info file descriptor of tarfile is inconsistent
Bugs item #1235266, was opened at 2005-07-09 18:24 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1235266&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: debug info file descriptor of tarfile is inconsistent Initial Comment: "7.19.1 TarFile Objects" says The messages are written to sys.stdout. but they are actually written to sys.stderr :: def _dbg(self, level, msg): """Write debugging output to sys.stderr. """ if level <= self.debug: print >> sys.stderr, msg There are 2 options: (a) change document from stdout to stderr. (b) rewrite the code to use stdout. Given this is debug messages and most other modules use stdout for debug printing(gc is one of the few exceptions?), I'm +1 on (b). [*] http://docs.python.org/lib/tarfile-objects.html -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-12 09:29 Message: Logged In: YES user_id=1188172 Okay. Checked in Doc/lib/libtarfile.tex r1.10, r1.7.2.1. And when will be some day? -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-07-12 05:06 Message: Logged In: YES user_id=80475 Just change the docs to match the actual behavior. Let's leave the implementation alone. There is no great need to have tarfile's implementation match zipfile. Someday, all of the modules will generate messages via the logging module and you'll trivially be able to mask them or redirect them in a consistent manner. -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-11 08:19 Message: Logged In: YES user_id=1188172 Attaching patches for both tarfile and zipfile. For tarfile, the docs are changed to stderr, for zipfile, both docs and implementation are changed to stderr. Since I don't assume that someone actually uses the debug info in some automated way, I think we can correct this in 2.5. Raymond, please review. -- Comment By: George Yoshida (quiver) Date: 2005-07-10 18:26 Message: Logged In: YES user_id=671362 OK. I tested some GNU compression/decompression tools and comfirmed that they write debugging messages (displayed in verbose mode(-v)) to stderr. Now I'm leaning toward Reinhold's idea. > What about zipfile? > Should we print debug info to stderr there, too? Maybe yes. I'd be happy to volunteer for that patch. -- Comment By: Lars Gustäbel (gustaebel) Date: 2005-07-10 10:00 Message: Logged In: YES user_id=642936 This is a documentation error. Debug messages must go to stderr because that's what stderr is for. Think of a script that writes a tar archive to stdout for use in a unix shell pipeline. If debug messages went to stdout, too, it would produce unusable output, because archive data and debug messages would be mixed. -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-09 19:04 Message: Logged In: YES user_id=1188172 The documentation seems to be borrowed from zipfile, where the statement is true: debug info is written to stdout. I'm in favour of changing the docs to stderr for tarfile. What about zipfile? Should we print debug info to stderr there, too? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1235266&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1229429 ] missing Py_DECREF in PyObject_CallMethod
Bugs item #1229429, was opened at 2005-06-29 03:18 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1229429&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Gary (gdray-1) Assigned to: Michael Hudson (mwh) Summary: missing Py_DECREF in PyObject_CallMethod Initial Comment: Once PyObject *func has been successfully returned by PyObject_GetAttrString(), the ref count is not decremented by any of the error exit cases from PyObject_CallMethod(). After the check that func is not NULL, there are four error case exits that do not decrement the ref count on func. -- >Comment By: Michael Hudson (mwh) Date: 2005-07-12 11:23 Message: Logged In: YES user_id=6656 Heh, it's a fair cop. Fixed in: Objects/abstract.c revision 2.137 Lib/test/test_enumerate.py revision 1.15 Misc/NEWS revision 1.1313 Raymond, while I have your attention, is the __reversed__ protocol tested anywhere? -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-07-12 04:08 Message: Logged In: YES user_id=80475 Assigning to the god of leak fixes. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1229429&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1229429 ] missing Py_DECREF in PyObject_CallMethod
Bugs item #1229429, was opened at 2005-06-28 21:18 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1229429&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Gary (gdray-1) Assigned to: Michael Hudson (mwh) Summary: missing Py_DECREF in PyObject_CallMethod Initial Comment: Once PyObject *func has been successfully returned by PyObject_GetAttrString(), the ref count is not decremented by any of the error exit cases from PyObject_CallMethod(). After the check that func is not NULL, there are four error case exits that do not decrement the ref count on func. -- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-07-12 05:31 Message: Logged In: YES user_id=80475 It's not an official, documented protocol. It is an implementation detail (choosen as a way to decouple individual types from the general purpose reversed() code). It is tested via the types than implement __reversed__ (such as collections.deque). BTW, all the general testing for reversed is cleverly hidden in test_enumerate. -- Comment By: Michael Hudson (mwh) Date: 2005-07-12 05:23 Message: Logged In: YES user_id=6656 Heh, it's a fair cop. Fixed in: Objects/abstract.c revision 2.137 Lib/test/test_enumerate.py revision 1.15 Misc/NEWS revision 1.1313 Raymond, while I have your attention, is the __reversed__ protocol tested anywhere? -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-07-11 22:08 Message: Logged In: YES user_id=80475 Assigning to the god of leak fixes. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1229429&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1229429 ] missing Py_DECREF in PyObject_CallMethod
Bugs item #1229429, was opened at 2005-06-29 03:18 Message generated for change (Settings changed) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1229429&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Gary (gdray-1) Assigned to: Michael Hudson (mwh) Summary: missing Py_DECREF in PyObject_CallMethod Initial Comment: Once PyObject *func has been successfully returned by PyObject_GetAttrString(), the ref count is not decremented by any of the error exit cases from PyObject_CallMethod(). After the check that func is not NULL, there are four error case exits that do not decrement the ref count on func. -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-07-12 11:31 Message: Logged In: YES user_id=80475 It's not an official, documented protocol. It is an implementation detail (choosen as a way to decouple individual types from the general purpose reversed() code). It is tested via the types than implement __reversed__ (such as collections.deque). BTW, all the general testing for reversed is cleverly hidden in test_enumerate. -- Comment By: Michael Hudson (mwh) Date: 2005-07-12 11:23 Message: Logged In: YES user_id=6656 Heh, it's a fair cop. Fixed in: Objects/abstract.c revision 2.137 Lib/test/test_enumerate.py revision 1.15 Misc/NEWS revision 1.1313 Raymond, while I have your attention, is the __reversed__ protocol tested anywhere? -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-07-12 04:08 Message: Logged In: YES user_id=80475 Assigning to the god of leak fixes. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1229429&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1232768 ] Mistakes in online docs under "5.3 Pure Embedding"
Bugs item #1232768, was opened at 2005-07-05 16:11 Message generated for change (Comment added) made by pterk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1232768&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Matt Smart (mcsmart) Assigned to: Nobody/Anonymous (nobody) Summary: Mistakes in online docs under "5.3 Pure Embedding" Initial Comment: I'm looking at the "5.3 Pure Embedding" page: http://python.org/doc/2.4.1/ext/pure-embedding.html 1. pFunc = PyDict_GetItemString(pDict, argv[2]); - /* pFun: Borrowed reference */ + /* pFunc: Borrowed reference */ 2. The code snippet in the section starting with "After initializing the interpreter," does not follow the code in the example. It uses PyObject_GetAttrString() instead of PyObject_GetItemString(), which creates a new reference instead of borrowing one, and therefore needs a Py_XDEREF(pFunc) call that is also not in the initial example. -- Comment By: Peter van Kampen (pterk) Date: 2005-07-12 12:59 Message: Logged In: YES user_id=174455 These seem to have been fixed already in CVS (although I can't find a duplicate report). Suggest closing. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1232768&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1232768 ] Mistakes in online docs under "5.3 Pure Embedding"
Bugs item #1232768, was opened at 2005-07-05 16:11 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1232768&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Matt Smart (mcsmart) Assigned to: Nobody/Anonymous (nobody) Summary: Mistakes in online docs under "5.3 Pure Embedding" Initial Comment: I'm looking at the "5.3 Pure Embedding" page: http://python.org/doc/2.4.1/ext/pure-embedding.html 1. pFunc = PyDict_GetItemString(pDict, argv[2]); - /* pFun: Borrowed reference */ + /* pFunc: Borrowed reference */ 2. The code snippet in the section starting with "After initializing the interpreter," does not follow the code in the example. It uses PyObject_GetAttrString() instead of PyObject_GetItemString(), which creates a new reference instead of borrowing one, and therefore needs a Py_XDEREF(pFunc) call that is also not in the initial example. -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-12 13:35 Message: Logged In: YES user_id=1188172 Only the first part has been fixed. The second is beyond my decision and must be considered by someone other. -- Comment By: Peter van Kampen (pterk) Date: 2005-07-12 12:59 Message: Logged In: YES user_id=174455 These seem to have been fixed already in CVS (although I can't find a duplicate report). Suggest closing. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1232768&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1232768 ] Mistakes in online docs under "5.3 Pure Embedding"
Bugs item #1232768, was opened at 2005-07-05 16:11
Message generated for change (Comment added) made by pterk
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1232768&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Matt Smart (mcsmart)
Assigned to: Nobody/Anonymous (nobody)
Summary: Mistakes in online docs under "5.3 Pure Embedding"
Initial Comment:
I'm looking at the "5.3 Pure Embedding" page:
http://python.org/doc/2.4.1/ext/pure-embedding.html
1.
pFunc = PyDict_GetItemString(pDict, argv[2]);
- /* pFun: Borrowed reference */
+ /* pFunc: Borrowed reference */
2.
The code snippet in the section starting with "After initializing the
interpreter," does not follow the code in the example. It uses
PyObject_GetAttrString() instead of PyObject_GetItemString(),
which creates a new reference instead of borrowing one, and
therefore needs a Py_XDEREF(pFunc) call that is also not in the
initial example.
--
Comment By: Peter van Kampen (pterk)
Date: 2005-07-12 14:57
Message:
Logged In: YES
user_id=174455
Reinhold, I must confess I am confused. I'm trying to
unravel what goes in in CVS with all the branches. It seems
this was corrected in rev. 1.5 of embedding.tex (from
2002!?). Looking at cvs (HEAD) I also see:
python/dist/src/Doc/ext/embedding.tex (line ~180):
\begin{verbatim}
pFunc = PyObject_GetAttrString(pModule, argv[2]);
/* pFunc is a new reference */
if (pFunc && PyCallable_Check(pFunc)) {
...
}
Py_XDECREF(pFunc);
\end{verbatim}
This seems to fix the problem? Also looking at
http://python.org/doc/2.4.1/ext/pure-embedding.html *today*
I don't see 'Borrowed reference' and but 'a new reference'
and including a PyXDEREF. Am I totally missing the point of
the bug-report or is the time-machine flying again?
--
Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-07-12 13:35
Message:
Logged In: YES
user_id=1188172
Only the first part has been fixed. The second is beyond my
decision and must be considered by someone other.
--
Comment By: Peter van Kampen (pterk)
Date: 2005-07-12 12:59
Message:
Logged In: YES
user_id=174455
These seem to have been fixed already in CVS (although I
can't find a duplicate report). Suggest closing.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1232768&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1233799 ] tkFileDialog.askopen... fails when dir=""
Bugs item #1233799, was opened at 2005-07-06 17:08
Message generated for change (Comment added) made by jepler
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1233799&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Tkinter
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Russell Owen (reowen)
Assigned to: Martin v. Löwis (loewis)
Summary: tkFileDialog.askopen... fails when dir=""
Initial Comment:
The following simple code fails on MacOS X 10.3 running the built-
in python 2.3 and Aqua Tcl/Tk 8.4.9:
import Tkinter
import tkFileDialog
root = Tkinter.Tk()
newPath = tkFileDialog.askopenfilename(
initialdir = "",
)
The error is:
Traceback (most recent call last):
File "tkFileDialog_askopen bug.py", line 5, in ?
newPath = tkFileDialog.askopenfilename(
File "/System/Library/Frameworks/Python.framework/Versions/2.3/
lib/python2.3/lib-tk/tkFileDialog.py", line 119, in askopenfilename
return Open(**options).show()
File "/System/Library/Frameworks/Python.framework/Versions/2.3/
lib/python2.3/lib-tk/tkCommonDialog.py", line 52, in show
s = w.tk.call(self.command, *w._options(self.options))
_tkinter.TclError: bad directory ""
The same code runs fine on unix Python 2.2.3 with unknown tcl/tk
and on and unix Python 2.4.1 with tcl/tk 8.4.9. it starts out in the
user's home directory as I'd expect.
Mind you, I know I can use None or not specify the initialdir
argument. But in my code it's a string that *might* be empty.
--
Comment By: Jeff Epler (jepler)
Date: 2005-07-12 08:10
Message:
Logged In: YES
user_id=2772
At first glance, this appears to be a bug or an incompatible
change in Tk between the old version and Aqua 8.4.9.
If you know the name of the 'wish' executable that uses the
same version of Tcl/Tk as your Python 2.3, please check
whether the tcl command
tk_getOpenFile -initialdir {}
fails. If it does, then this is a Tcl/Tk bug or
incompatible change, and I believe this tracker item should
be closed. Only if that works, but the Python equivalent
doesn't, is there a reason to treat this as a bug in
Python/Tkinter.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1233799&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1232768 ] Mistakes in online docs under "5.3 Pure Embedding"
Bugs item #1232768, was opened at 2005-07-05 16:11
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1232768&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Matt Smart (mcsmart)
Assigned to: Nobody/Anonymous (nobody)
Summary: Mistakes in online docs under "5.3 Pure Embedding"
Initial Comment:
I'm looking at the "5.3 Pure Embedding" page:
http://python.org/doc/2.4.1/ext/pure-embedding.html
1.
pFunc = PyDict_GetItemString(pDict, argv[2]);
- /* pFun: Borrowed reference */
+ /* pFunc: Borrowed reference */
2.
The code snippet in the section starting with "After initializing the
interpreter," does not follow the code in the example. It uses
PyObject_GetAttrString() instead of PyObject_GetItemString(),
which creates a new reference instead of borrowing one, and
therefore needs a Py_XDEREF(pFunc) call that is also not in the
initial example.
--
>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-07-12 15:12
Message:
Logged In: YES
user_id=1188172
I thought the same when I first read this report. On this
HTML page, there's the large code sample at the top, and
below are explanations. In the large sample the code with
GetItemString and without Py_XDECREF. Both are OK, but
different, and that's what the reporter's problem was.
But thanks to your digging in the CVS history, I can tell
that the intended code is the second version with GetAttrString.
--
Comment By: Peter van Kampen (pterk)
Date: 2005-07-12 14:57
Message:
Logged In: YES
user_id=174455
Reinhold, I must confess I am confused. I'm trying to
unravel what goes in in CVS with all the branches. It seems
this was corrected in rev. 1.5 of embedding.tex (from
2002!?). Looking at cvs (HEAD) I also see:
python/dist/src/Doc/ext/embedding.tex (line ~180):
\begin{verbatim}
pFunc = PyObject_GetAttrString(pModule, argv[2]);
/* pFunc is a new reference */
if (pFunc && PyCallable_Check(pFunc)) {
...
}
Py_XDECREF(pFunc);
\end{verbatim}
This seems to fix the problem? Also looking at
http://python.org/doc/2.4.1/ext/pure-embedding.html *today*
I don't see 'Borrowed reference' and but 'a new reference'
and including a PyXDEREF. Am I totally missing the point of
the bug-report or is the time-machine flying again?
--
Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-07-12 13:35
Message:
Logged In: YES
user_id=1188172
Only the first part has been fixed. The second is beyond my
decision and must be considered by someone other.
--
Comment By: Peter van Kampen (pterk)
Date: 2005-07-12 12:59
Message:
Logged In: YES
user_id=174455
These seem to have been fixed already in CVS (although I
can't find a duplicate report). Suggest closing.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1232768&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1232768 ] Mistakes in online docs under "5.3 Pure Embedding"
Bugs item #1232768, was opened at 2005-07-05 16:11
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1232768&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Matt Smart (mcsmart)
>Assigned to: Reinhold Birkenfeld (birkenfeld)
Summary: Mistakes in online docs under "5.3 Pure Embedding"
Initial Comment:
I'm looking at the "5.3 Pure Embedding" page:
http://python.org/doc/2.4.1/ext/pure-embedding.html
1.
pFunc = PyDict_GetItemString(pDict, argv[2]);
- /* pFun: Borrowed reference */
+ /* pFunc: Borrowed reference */
2.
The code snippet in the section starting with "After initializing the
interpreter," does not follow the code in the example. It uses
PyObject_GetAttrString() instead of PyObject_GetItemString(),
which creates a new reference instead of borrowing one, and
therefore needs a Py_XDEREF(pFunc) call that is also not in the
initial example.
--
>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-07-12 15:18
Message:
Logged In: YES
user_id=1188172
Okay. Fixed as Doc/ext/run-func.c r1.4.20.1, r1.5.
--
Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-07-12 15:12
Message:
Logged In: YES
user_id=1188172
I thought the same when I first read this report. On this
HTML page, there's the large code sample at the top, and
below are explanations. In the large sample the code with
GetItemString and without Py_XDECREF. Both are OK, but
different, and that's what the reporter's problem was.
But thanks to your digging in the CVS history, I can tell
that the intended code is the second version with GetAttrString.
--
Comment By: Peter van Kampen (pterk)
Date: 2005-07-12 14:57
Message:
Logged In: YES
user_id=174455
Reinhold, I must confess I am confused. I'm trying to
unravel what goes in in CVS with all the branches. It seems
this was corrected in rev. 1.5 of embedding.tex (from
2002!?). Looking at cvs (HEAD) I also see:
python/dist/src/Doc/ext/embedding.tex (line ~180):
\begin{verbatim}
pFunc = PyObject_GetAttrString(pModule, argv[2]);
/* pFunc is a new reference */
if (pFunc && PyCallable_Check(pFunc)) {
...
}
Py_XDECREF(pFunc);
\end{verbatim}
This seems to fix the problem? Also looking at
http://python.org/doc/2.4.1/ext/pure-embedding.html *today*
I don't see 'Borrowed reference' and but 'a new reference'
and including a PyXDEREF. Am I totally missing the point of
the bug-report or is the time-machine flying again?
--
Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-07-12 13:35
Message:
Logged In: YES
user_id=1188172
Only the first part has been fixed. The second is beyond my
decision and must be considered by someone other.
--
Comment By: Peter van Kampen (pterk)
Date: 2005-07-12 12:59
Message:
Logged In: YES
user_id=174455
These seem to have been fixed already in CVS (although I
can't find a duplicate report). Suggest closing.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1232768&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1233799 ] tkFileDialog.askopen... fails when dir=""
Bugs item #1233799, was opened at 2005-07-06 15:08
Message generated for change (Comment added) made by reowen
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1233799&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Tkinter
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Russell Owen (reowen)
Assigned to: Martin v. Löwis (loewis)
Summary: tkFileDialog.askopen... fails when dir=""
Initial Comment:
The following simple code fails on MacOS X 10.3 running the built-
in python 2.3 and Aqua Tcl/Tk 8.4.9:
import Tkinter
import tkFileDialog
root = Tkinter.Tk()
newPath = tkFileDialog.askopenfilename(
initialdir = "",
)
The error is:
Traceback (most recent call last):
File "tkFileDialog_askopen bug.py", line 5, in ?
newPath = tkFileDialog.askopenfilename(
File "/System/Library/Frameworks/Python.framework/Versions/2.3/
lib/python2.3/lib-tk/tkFileDialog.py", line 119, in askopenfilename
return Open(**options).show()
File "/System/Library/Frameworks/Python.framework/Versions/2.3/
lib/python2.3/lib-tk/tkCommonDialog.py", line 52, in show
s = w.tk.call(self.command, *w._options(self.options))
_tkinter.TclError: bad directory ""
The same code runs fine on unix Python 2.2.3 with unknown tcl/tk
and on and unix Python 2.4.1 with tcl/tk 8.4.9. it starts out in the
user's home directory as I'd expect.
Mind you, I know I can use None or not specify the initialdir
argument. But in my code it's a string that *might* be empty.
--
>Comment By: Russell Owen (reowen)
Date: 2005-07-12 09:55
Message:
Logged In: YES
user_id=431773
The suggested tk command does fail:
() 1 % tk_getOpenFile -initialdir {}
bad directory ""
so I'll report this as a Tk bug.
--
Comment By: Jeff Epler (jepler)
Date: 2005-07-12 06:10
Message:
Logged In: YES
user_id=2772
At first glance, this appears to be a bug or an incompatible
change in Tk between the old version and Aqua 8.4.9.
If you know the name of the 'wish' executable that uses the
same version of Tcl/Tk as your Python 2.3, please check
whether the tcl command
tk_getOpenFile -initialdir {}
fails. If it does, then this is a Tcl/Tk bug or
incompatible change, and I believe this tracker item should
be closed. Only if that works, but the Python equivalent
doesn't, is there a reason to treat this as a bug in
Python/Tkinter.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1233799&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1233799 ] tkFileDialog.askopen... fails when dir=""
Bugs item #1233799, was opened at 2005-07-07 00:08
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1233799&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Tkinter
>Group: 3rd Party
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Russell Owen (reowen)
Assigned to: Martin v. Löwis (loewis)
Summary: tkFileDialog.askopen... fails when dir=""
Initial Comment:
The following simple code fails on MacOS X 10.3 running the built-
in python 2.3 and Aqua Tcl/Tk 8.4.9:
import Tkinter
import tkFileDialog
root = Tkinter.Tk()
newPath = tkFileDialog.askopenfilename(
initialdir = "",
)
The error is:
Traceback (most recent call last):
File "tkFileDialog_askopen bug.py", line 5, in ?
newPath = tkFileDialog.askopenfilename(
File "/System/Library/Frameworks/Python.framework/Versions/2.3/
lib/python2.3/lib-tk/tkFileDialog.py", line 119, in askopenfilename
return Open(**options).show()
File "/System/Library/Frameworks/Python.framework/Versions/2.3/
lib/python2.3/lib-tk/tkCommonDialog.py", line 52, in show
s = w.tk.call(self.command, *w._options(self.options))
_tkinter.TclError: bad directory ""
The same code runs fine on unix Python 2.2.3 with unknown tcl/tk
and on and unix Python 2.4.1 with tcl/tk 8.4.9. it starts out in the
user's home directory as I'd expect.
Mind you, I know I can use None or not specify the initialdir
argument. But in my code it's a string that *might* be empty.
--
>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-07-12 19:32
Message:
Logged In: YES
user_id=1188172
Closing this as 3rd party, then.
--
Comment By: Russell Owen (reowen)
Date: 2005-07-12 18:55
Message:
Logged In: YES
user_id=431773
The suggested tk command does fail:
() 1 % tk_getOpenFile -initialdir {}
bad directory ""
so I'll report this as a Tk bug.
--
Comment By: Jeff Epler (jepler)
Date: 2005-07-12 15:10
Message:
Logged In: YES
user_id=2772
At first glance, this appears to be a bug or an incompatible
change in Tk between the old version and Aqua 8.4.9.
If you know the name of the 'wish' executable that uses the
same version of Tcl/Tk as your Python 2.3, please check
whether the tcl command
tk_getOpenFile -initialdir {}
fails. If it does, then this is a Tcl/Tk bug or
incompatible change, and I believe this tracker item should
be closed. Only if that works, but the Python equivalent
doesn't, is there a reason to treat this as a bug in
Python/Tkinter.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1233799&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1175396 ] codecs.readline sometimes removes newline chars
Bugs item #1175396, was opened at 2005-04-02 15:14 Message generated for change (Comment added) made by vrmeyer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1175396&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: Accepted Priority: 5 Submitted By: Irmen de Jong (irmen) Assigned to: Walter Dörwald (doerwalter) Summary: codecs.readline sometimes removes newline chars Initial Comment: In Python 2.4.1 i observed a new bug in codecs.readline, it seems that with certain inputs it removes newline characters from the end of the line Probably related to bug #1076985 (Incorrect behaviour of StreamReader.readline leads to crash) and bug #1098990 codec readline() splits lines apart (both with status closed) so I'm assigning this to Walter. See the attached files that demonstrate the problem. Reproduced with Python 2.4.1 on windows XP and on Linux. The problem does not occur with Python 2.4. (btw, it seems bug #1076985 was fixed in python 2.4.1, but the other one (#1098990) not? ) -- Comment By: Alan Meyer (vrmeyer) Date: 2005-07-12 18:07 Message: Logged In: YES user_id=338015 Hello doerwalter, Our thanks to you and to glchapman for working on this bug. I think the project I am working on may have run into this bug while attempting to use the python COM client wrappers for ADO on Win32. We saw the problem in Python 2.4.1, but not 2.4 or 2.3.5. Do you have any projection for when the fix will make it into the stable distribution? Our production is running on 2.3.5. If it looks like a long while before the fix is distributed, we may upgrade to 2.4.0. Otherwise we'll stick with 2.3.5 and wait. Thanks again. Alan -- Comment By: Walter Dörwald (doerwalter) Date: 2005-05-16 14:20 Message: Logged In: YES user_id=89016 > > 1) How do we handle the problem of a truncated line, if the > > data comes from the charbuffer instead of being read from > > > the stream? > > > > My suggestion is to make the top of the loop look like: > > > > while True: > > havecharbuffer = bool(self.charbuffer) > > > > And then the break condition (when no line break found) > > should be: > > > > # we didn't get anything or this was our only try > > if not data or (size is not None and not havecharbuffer): > > > > (too many negatives in that). Anyway, the idea is that, if > > size specified, there will be at most one read of the > > underlying stream (using the size). So if you enter the > > loop with a charbuffer, and that charbuffer does not have a > > line break, then you redo the loop once (the second time it > > will break, because havecharbuffer will be False). This makes sense. However, with the current state of the tokenizer this might be to dangerous, because the resulting line might be twice as long. So fixing the tokenizer should be the first step. BTW, your patch fixes the problems with the fix for #1178484, so I think I'm going to apply the patch in the next days, if there are no objections. > > Also, not sure about this, but should the size parameter > > default to -1 (to keep it in sync with read)? None seems to be a better default from an API viewpoint, but -1 is better for "C compatibility". > > As to issue 2, it looks like it should be possible to get > > the line number right, because the UnicodeDecodeError > > exception object has all the necessary information in it > > (including the original string). I think this should be > > done by fp_readl (in tokenizer.c). The patch for #1178484 fixes this. Combined with this patch I think we're in good shape. > > By the way, using a findlinebreak function (using sre) turns > > out to be slower than splitting/joining when no size is > > specified (which I assume will be the overwhelmingly most > > common case), so that turned out to be a bad idea on my part. Coding this on the C level and using Py_UNICODE_ISLINEBREAK() should be the fastest version, but I don't know if this is worth it. -- Comment By: Greg Chapman (glchapman) Date: 2005-04-23 16:46 Message: Logged In: YES user_id=86307 > 1) How do we handle the problem of a truncated line, if the > data comes from the charbuffer instead of being read from > the stream? My suggestion is to make the top of the loop look like: while True: havecharbuffer = bool(self.charbuffer) And then the break condition (when no line break found) should be: # we didn't get anything or this was our only try if not data or (size is not None and not havecharbuffer): (too many negatives in that). Anyway, the idea is that, if s
[ python-Bugs-1236906 ] email.Generator traceback in forwarded msg
Bugs item #1236906, was opened at 2005-07-12 13:59
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=1236906&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: Skip Montanaro (montanaro)
Assigned to: Nobody/Anonymous (nobody)
Summary: email.Generator traceback in forwarded msg
Initial Comment:
The SpamBayes sb_unheader app uses the email package
to dump out a copy of a message with user-specified
headers removed. The email.Generator.Generator class is
barfing on the attached message. I haven't had a chance
to look into it yet, but I suspect it's a problem in
the email
package, not the sb_unheader program.
Here's the traceback I see. This is with a Python built
from CVS within the last couple days.
Traceback (most recent call last):
File "/Users/skip/local/bin/sb_unheader.py", line
144, in ?
main(sys.argv[1:])
File "/Users/skip/local/bin/sb_unheader.py", line
139, in main
process_mailbox(f, dosa, pats)
File "/Users/skip/local/bin/sb_unheader.py", line 86,
in process_mailbox
gen.flatten(msg, unixfrom=1)
File
"/Users/skip/local/lib/python2.5/email/Generator.py",
line 82, in flattenself._write(msg)
File
"/Users/skip/local/lib/python2.5/email/Generator.py",
line 113, in _writeself._dispatch(msg)
File
"/Users/skip/local/lib/python2.5/email/Generator.py",
line 139, in _dispatch
meth(msg)
File
"/Users/skip/local/lib/python2.5/email/Generator.py",
line 273, in _handle_message
g.flatten(msg.get_payload(0), unixfrom=False)
File
"/Users/skip/local/lib/python2.5/email/Message.py",
line 183, in get_payload
raise TypeError('Expected list, got %s' %
type(self._payload))
TypeError: Expected list, got
montanaro:tmp% type tradelink
tradelink is aliased to `ssh -C -X loginhost.trdlnk.com'
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1236906&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1236906 ] email.Generator traceback in forwarded msg
Bugs item #1236906, was opened at 2005-07-12 14:59
Message generated for change (Settings changed) made by bwarsaw
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1236906&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: Skip Montanaro (montanaro)
>Assigned to: Barry A. Warsaw (bwarsaw)
Summary: email.Generator traceback in forwarded msg
Initial Comment:
The SpamBayes sb_unheader app uses the email package
to dump out a copy of a message with user-specified
headers removed. The email.Generator.Generator class is
barfing on the attached message. I haven't had a chance
to look into it yet, but I suspect it's a problem in
the email
package, not the sb_unheader program.
Here's the traceback I see. This is with a Python built
from CVS within the last couple days.
Traceback (most recent call last):
File "/Users/skip/local/bin/sb_unheader.py", line
144, in ?
main(sys.argv[1:])
File "/Users/skip/local/bin/sb_unheader.py", line
139, in main
process_mailbox(f, dosa, pats)
File "/Users/skip/local/bin/sb_unheader.py", line 86,
in process_mailbox
gen.flatten(msg, unixfrom=1)
File
"/Users/skip/local/lib/python2.5/email/Generator.py",
line 82, in flattenself._write(msg)
File
"/Users/skip/local/lib/python2.5/email/Generator.py",
line 113, in _writeself._dispatch(msg)
File
"/Users/skip/local/lib/python2.5/email/Generator.py",
line 139, in _dispatch
meth(msg)
File
"/Users/skip/local/lib/python2.5/email/Generator.py",
line 273, in _handle_message
g.flatten(msg.get_payload(0), unixfrom=False)
File
"/Users/skip/local/lib/python2.5/email/Message.py",
line 183, in get_payload
raise TypeError('Expected list, got %s' %
type(self._payload))
TypeError: Expected list, got
montanaro:tmp% type tradelink
tradelink is aliased to `ssh -C -X loginhost.trdlnk.com'
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1236906&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1175396 ] codecs.readline sometimes removes newline chars
Bugs item #1175396, was opened at 2005-04-02 06:14 Message generated for change (Comment added) made by glchapman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1175396&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: Accepted Priority: 5 Submitted By: Irmen de Jong (irmen) Assigned to: Walter Dörwald (doerwalter) Summary: codecs.readline sometimes removes newline chars Initial Comment: In Python 2.4.1 i observed a new bug in codecs.readline, it seems that with certain inputs it removes newline characters from the end of the line Probably related to bug #1076985 (Incorrect behaviour of StreamReader.readline leads to crash) and bug #1098990 codec readline() splits lines apart (both with status closed) so I'm assigning this to Walter. See the attached files that demonstrate the problem. Reproduced with Python 2.4.1 on windows XP and on Linux. The problem does not occur with Python 2.4. (btw, it seems bug #1076985 was fixed in python 2.4.1, but the other one (#1098990) not? ) -- Comment By: Greg Chapman (glchapman) Date: 2005-07-12 11:53 Message: Logged In: YES user_id=86307 Build 204 of pywin32 has a workaround for bug 1163244 which should also avoid this bug: it leaves out the encoding notation in generated COM wrapper files (so loading will not involve the codecs module). If your wrapper files don't need extended characters (I don't think ADO does), you might want to give that a shot. -- Comment By: Alan Meyer (vrmeyer) Date: 2005-07-12 10:07 Message: Logged In: YES user_id=338015 Hello doerwalter, Our thanks to you and to glchapman for working on this bug. I think the project I am working on may have run into this bug while attempting to use the python COM client wrappers for ADO on Win32. We saw the problem in Python 2.4.1, but not 2.4 or 2.3.5. Do you have any projection for when the fix will make it into the stable distribution? Our production is running on 2.3.5. If it looks like a long while before the fix is distributed, we may upgrade to 2.4.0. Otherwise we'll stick with 2.3.5 and wait. Thanks again. Alan -- Comment By: Walter Dörwald (doerwalter) Date: 2005-05-16 06:20 Message: Logged In: YES user_id=89016 > > 1) How do we handle the problem of a truncated line, if the > > data comes from the charbuffer instead of being read from > > > the stream? > > > > My suggestion is to make the top of the loop look like: > > > > while True: > > havecharbuffer = bool(self.charbuffer) > > > > And then the break condition (when no line break found) > > should be: > > > > # we didn't get anything or this was our only try > > if not data or (size is not None and not havecharbuffer): > > > > (too many negatives in that). Anyway, the idea is that, if > > size specified, there will be at most one read of the > > underlying stream (using the size). So if you enter the > > loop with a charbuffer, and that charbuffer does not have a > > line break, then you redo the loop once (the second time it > > will break, because havecharbuffer will be False). This makes sense. However, with the current state of the tokenizer this might be to dangerous, because the resulting line might be twice as long. So fixing the tokenizer should be the first step. BTW, your patch fixes the problems with the fix for #1178484, so I think I'm going to apply the patch in the next days, if there are no objections. > > Also, not sure about this, but should the size parameter > > default to -1 (to keep it in sync with read)? None seems to be a better default from an API viewpoint, but -1 is better for "C compatibility". > > As to issue 2, it looks like it should be possible to get > > the line number right, because the UnicodeDecodeError > > exception object has all the necessary information in it > > (including the original string). I think this should be > > done by fp_readl (in tokenizer.c). The patch for #1178484 fixes this. Combined with this patch I think we're in good shape. > > By the way, using a findlinebreak function (using sre) turns > > out to be slower than splitting/joining when no size is > > specified (which I assume will be the overwhelmingly most > > common case), so that turned out to be a bad idea on my part. Coding this on the C level and using Py_UNICODE_ISLINEBREAK() should be the fastest version, but I don't know if this is worth it. -- Comment By: Greg Chapman (glchapman) Date: 2005-04-23 08:46 Message: Logged In: YES user_id=86307 > 1) How
[ python-Bugs-1236090 ] Carbon.FSSpec.as_pathname() crashes
Bugs item #1236090, was opened at 2005-07-11 16:12
Message generated for change (Comment added) made by jackjansen
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1236090&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: Extension Modules
Group: Platform-specific
Status: Open
Resolution: None
Priority: 8
Submitted By: Michael Hudson (mwh)
Assigned to: Jack Jansen (jackjansen)
>Summary: Carbon.FSSpec.as_pathname() crashes
Initial Comment:
There's something peculiar in the land of bgen-ed wrappers:
$ ./python.exe
Python 2.5a0 (#1, Jul 11 2005, 13:21:11)
[GCC 3.3 20030304 (Apple Computer, Inc. build 1671)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import Carbon.File
[45313 refs]
>>> Carbon.File.FSSpec(os.curdir).as_pathname()
Segmentation fault
("make test" also crashes).
This is on 10.3.9.
My first investigations with gdb didn't reveal anything that made
much sense, so it *might* be a compiler bug. At any rate, it didn't
do this a few weeks ago...
--
>Comment By: Jack Jansen (jackjansen)
Date: 2005-07-12 22:18
Message:
Logged In: YES
user_id=45365
The problem appears to be in as_pathname(). Investigating...
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1236090&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1236090 ] Carbon.FSSpec.as_pathname() crashes
Bugs item #1236090, was opened at 2005-07-11 16:12
Message generated for change (Comment added) made by jackjansen
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1236090&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: Extension Modules
Group: Platform-specific
>Status: Closed
>Resolution: Fixed
Priority: 8
Submitted By: Michael Hudson (mwh)
Assigned to: Jack Jansen (jackjansen)
Summary: Carbon.FSSpec.as_pathname() crashes
Initial Comment:
There's something peculiar in the land of bgen-ed wrappers:
$ ./python.exe
Python 2.5a0 (#1, Jul 11 2005, 13:21:11)
[GCC 3.3 20030304 (Apple Computer, Inc. build 1671)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import Carbon.File
[45313 refs]
>>> Carbon.File.FSSpec(os.curdir).as_pathname()
Segmentation fault
("make test" also crashes).
This is on 10.3.9.
My first investigations with gdb didn't reveal anything that made
much sense, so it *might* be a compiler bug. At any rate, it didn't
do this a few weeks ago...
--
>Comment By: Jack Jansen (jackjansen)
Date: 2005-07-12 23:26
Message:
Logged In: YES
user_id=45365
Argh! It turns out that patch #1035255 was incomplete: it patched
_Filemodule.c, but not filesupport.py (bad Bob, no cookie:-)
So, when I regenerated _Filemodule.c last week FSSpec.as_pathname()
still called FSSpec_as_pathname, in stead of _FSSpec_as_pathname
(note the subtle difference, which I consequently overlooked). This
resulted in an infinite loop.
Fixed in _Filemodule.c rev. 1.25, filesupport.py rev. 1.22.
--
Comment By: Jack Jansen (jackjansen)
Date: 2005-07-12 22:18
Message:
Logged In: YES
user_id=45365
The problem appears to be in as_pathname(). Investigating...
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1236090&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1089395 ] segfault/assert in tokenizer
Bugs item #1089395, was opened at 2004-12-21 23:02 Message generated for change (Settings changed) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1089395&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: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Martin v. Löwis (loewis) Summary: segfault/assert in tokenizer Initial Comment: The attached script fail.py (with the attached codec evilascii.py) leads to a segfault in both Python 2.3 and 2.4. With a debug build I get: python: Parser/tokenizer.c:367: fp_readl: Assertion `strlen(str) < (size_t)size' failed. Aborted Assigning to Martin, because this seems to be PEP 263 related. -- >Comment By: Walter Dörwald (doerwalter) Date: 2005-07-13 00:00 Message: Logged In: YES user_id=89016 OK, patch www.python.org/sf/1101726 has been applied. -- Comment By: Greg Chapman (glchapman) Date: 2005-01-13 16:47 Message: Logged In: YES user_id=86307 I just posted a patch for this here: www.python.org/sf/1101726 I'd appreciate any comments/corrections. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1089395&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1237015 ] Missing sk_SK in windows_locale
Bugs item #1237015, was opened at 2005-07-13 00: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=1237015&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Lukas Lalinsky (luks) Assigned to: Nobody/Anonymous (nobody) Summary: Missing sk_SK in windows_locale Initial Comment: Please, could you add sk_SK locale to windows_locale array in module locale? Corresponding entry should look like: 0x041b: "sk_SK", # Slovak Information about language ID taken is from http://msdn.microsoft.com/library/default.asp?url=/library/en-us/intl/nls_238z.asp -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1237015&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1229788 ] Bus error in extension with gcc 3.3
Bugs item #1229788, was opened at 2005-06-30 03:43
Message generated for change (Comment added) made by esrever_otua
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1229788&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: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Gary Robinson (garyrob)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bus error in extension with gcc 3.3
Initial Comment:
This text contains a c module with 4 versions of the same
extremely simple function. All they do is return a float double to
python.
On Windows I have received a report from someone who can built
the module, imported it into Python, and ran it successfully.
It has also been reported that there is no problem when the
extension is compiled with gcc 4.0 on OS X.
However, on OS X, if the extension is compiled with gcc 3.3, the 4th
of the 4 function results in a bus error:
>>> from check import *
fun0()
411.0
>>> fun1()
534.37
>>> fun2()
411.0
>>> fun3()
Bus error
I originally reported this on the C++ sig's mail list. They suggested I
try dev-python. Scott David Daniels on that list helped me refine
some
test cases and verified that they all worked on Windows.
Along the way it was suggested that I post a bug report. So this is it.
The code follows:
#include "Python.h"
static double value = 411.0;
static PyObject *
fun0(PyObject *self, PyObject *args)
{
if (!PyArg_ParseTuple(args, "", NULL)) return NULL;
return Py_BuildValue("d", value);
}
static PyObject *
fun1(PyObject *self, PyObject *args)
{
return Py_BuildValue("d", 1.3*value);
}
static PyObject *
fun2(PyObject *self, PyObject *args)
{
return PyFloat_FromDouble(value);
}
static PyObject *
fun3(PyObject *self, PyObject *args)
{
return Py_BuildValue("d", value);
}
static PyMethodDef TestMethods[] = {
{"fun0", fun0, METH_VARARGS, "Read args and return value"},
{"fun1", fun1, METH_VARARGS, "Return value multiplied inline
by
1.3"},
{"fun2", fun2, METH_VARARGS, "Return value using
PyFloat_FromDouble"},
{"fun3", fun3, METH_VARARGS, "Return value using
Py_BuildValue
without reading args -- causes bus error on OS X Panther with
XCode 1.5
installed"},
{NULL, NULL, 0, NULL}/* Sentinel */
};
PyMODINIT_FUNC
initcheck(void)
{
PyObject *module;
module = Py_InitModule3("check", TestMethods,
"extension module with three functions.");
if (module) {
PyModule_AddStringConstant(module, "__version__", "0.02");
}
}
--
Comment By: Darryl Dixon (esrever_otua)
Date: 2005-07-13 16:36
Message:
Logged In: YES
user_id=567623
Bus errors are generally caused by unaligned memory
accesses, or by attempts to read past the end of a
file-descriptor (or something along those lines). This
sounds like a gcc bug rather than a Python bug. Can I
suggest changing your compiler flags and experimenting with
things like different -O levels? (-O3, -O1, etc) to see if
it makes a difference... Also, you may want to raise a bug
with gcc (although I've no idea how seriously they would
take it :( ). Finally, what version of gcc is Python
compiled with on Panther? There may be a conflict there
(once again, different optimisations might be the problem).
Anyhow, just my random thoughts,
D
--
Comment By: Terry J. Reedy (tjreedy)
Date: 2005-07-02 15:13
Message:
Logged In: YES
user_id=593130
I understand that you got advice to post, but I strongly doubt that
core Python code is involved for three reasons.
1. On the Unix I used, bus errors were much rarer and esoteric
than segmentation violations (from bad pointers). But maybe
BSD-derived OSX is different.
2. The only difference between fun1 that works and fun3 that
doesn't, seems to be how the arg in computed. The receiving
function only gets a value (which it copies) and does not know its
history.
3. You report that upgrading the compiler fixes the problem. (So
why not just do that?)
If you want to experiment more, redo fun1 and fun3 with 'value'
replaced by its literal value. Then redo again with value =
534.37 instead of 411 and change arg in fun1 to
value/1.3 instead of 1.3*value.
About stack trace: On unix (of 15 years ago), program crashes
usually resulted in a file called 'core' added to either the startup
or current working directory. A debugger program could extract
a stack trace, which was more readable if the executable still had
the symbol table attached and not stripped. I don't know
equivalent for OSX, but I found it very helpful for debugging.
--
