[ python-Bugs-639611 ] crash (SEGV) in Py_EndInterpreter()
Bugs item #639611, was opened at 2002-11-17 10:38
Message generated for change (Comment added) made by yoda_gh
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=639611&group_id=5470
Category: Python Interpreter Core
Group: Python 2.2.2
Status: Open
>Resolution: Works For Me
Priority: 3
Submitted By: Gernot Hillier (yoda_gh)
Assigned to: Guido van Rossum (gvanrossum)
Summary: crash (SEGV) in Py_EndInterpreter()
Initial Comment:
I experience a 80% reproducable SIGSEGV in a multithreaded app I
wrote using different embedded sub interpreters in its threads.
I have a C++ class (PClass) which encapsulates the sub-interpreters
somehow - it creates a new one in its constructor and deletes it in
the destructor (see below).
When 2 objects of this class are destroyed at nearly the same time
thus resulting in subsequent calls to Py_EndInterpreter() (but for the
different threads), I get the following SIGSEGV in most cases:
> gdb application core.31889
[...]
Program terminated with signal 11, Segmentation fault.
[...]
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from
/usr/local/lib/python2.2/lib-dynload/time.so...done.
Loaded symbols for /usr/local/lib/python2.2/lib-dynload/time.so
#0 0x08078763 in class_dealloc (op=0x81a8624) at
Objects/classobject.c:169
169 _PyObject_GC_UNTRACK(op);
(gdb) bt
#0 0x08078763 in class_dealloc (op=0x81a8624) at
Objects/classobject.c:169
#1 0x080daefa in PyThreadState_Clear (tstate=0x816b7f0) at
Python/pystate.c:190
#2 0x080dab89 in PyInterpreterState_Clear (interp=0x81427e8) at
Python/pystate.c:77
#3 0x080dce1e in Py_EndInterpreter (tstate=0x816b7f0) at
Python/pythonrun.c:381
#4 0x0805c287 in ~PClass (this=0x81421d0) at pclass.cpp:123
When the 2nd object is destroyed some seconds later, everything
seems to be fine. It only crashes when the 2 objects are deleted
within a short period of time.
I've tried this with the SuSE RPMs of Python 2.2.1 and a self-built
Python-2.2.2 with the same result. :-(
Here's a very short snippet of the python related code in my class:
// Constructor, initializes Python sub-interpreter
PClass::PClass()
{
PyEval_AcquireLock();
py_state=Py_NewInterpreter();
PyEval_SaveThread();
}
// destructor, kills the Python sub-interpreter
PClass::~PClass()
{
PyEval_RestoreThread(py_state);
Py_EndInterpreter(py_state);
py_state=NULL;
PyEval_ReleaseLock(); // release lock
}
// thread code, runs Python function
void
PClass::run()
{
PyEval_RestoreThread(py_state);
PyObject_CallFunction(...)
PyEval_SaveThread();
}
--
>Comment By: Gernot Hillier (yoda_gh)
Date: 2005-01-08 09:52
Message:
Logged In: YES
user_id=633130
Hmm, I'm quite sorry, but I changed my application quite thoroughly
in the meantime and never ever experienced any problem again -
and the application is widely used in the meantime.
I also can't really remember what I've changed in the "workaround"
of 2002-11-21 07:09. I could try to find these details if someone is
really interested in my old archives, but if not, I'll consider this as
fixed/"works for me" now.
--
Comment By: Facundo Batista (facundobatista)
Date: 2005-01-08 06:19
Message:
Logged In: YES
user_id=752496
Please, could you verify if this problem persists in Python 2.3.4
or 2.4?
If yes, in which version? Can you provide a test case?
If the problem is solved, from which version?
Note that if you fail to answer in one month, I'll close this bug
as "Won't fix".
Thank you!
.Facundo
--
Comment By: Guido van Rossum (gvanrossum)
Date: 2003-02-11 22:10
Message:
Logged In: YES
user_id=6380
No time for this now, lowering priority. If someone has a
patch, feel free to submit to SF.
--
Comment By: Tim Peters (tim_one)
Date: 2002-12-31 22:35
Message:
Logged In: YES
user_id=31435
Guido should look at it -- subinterpreters were his idea
.
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2002-12-31 14:19
Message:
Logged In: YES
user_id=33168
Tim, it was suggested you see this. Is this documented
somewhere? What should be done?
--
Comment By: Grzegorz Makarewicz (makaron)
Date: 2002-11-21 10:31
Message:
Logged In: YES
user_id=115179
I think it should be documented and additional check
performed before killing thread state or interpereter.
Leave it open - Tim Peters sho
[ python-Bugs-1098134 ] getsource and getsourcelines in the inspect module
Bugs item #1098134, was opened at 2005-01-07 21:28 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1098134&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Björn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: getsource and getsourcelines in the inspect module Initial Comment: import inspect class Hi: def oneliner1(): pass def oneliner2(): pass h = Hi() print inspect.getsourcelines(h.oneliner1) print "+++" + inspect.getsource(h.oneliner1) + "+++" Tested on Python 2.3.4. Both the getsource* functions takes the body of onliner1() and oneliner2() in the call. -- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-01-08 12:09 Message: Logged In: YES user_id=469548 This is fixed in Python 2.5 and the upcoming 2.4.1 by patch 1011890. Thanks for the report, though. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1098134&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-639611 ] crash (SEGV) in Py_EndInterpreter()
Bugs item #639611, was opened at 2002-11-17 10:38
Message generated for change (Settings changed) made by jlgijsbers
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=639611&group_id=5470
Category: Python Interpreter Core
Group: Python 2.2.2
>Status: Closed
Resolution: Works For Me
Priority: 3
Submitted By: Gernot Hillier (yoda_gh)
Assigned to: Guido van Rossum (gvanrossum)
Summary: crash (SEGV) in Py_EndInterpreter()
Initial Comment:
I experience a 80% reproducable SIGSEGV in a multithreaded app I
wrote using different embedded sub interpreters in its threads.
I have a C++ class (PClass) which encapsulates the sub-interpreters
somehow - it creates a new one in its constructor and deletes it in
the destructor (see below).
When 2 objects of this class are destroyed at nearly the same time
thus resulting in subsequent calls to Py_EndInterpreter() (but for the
different threads), I get the following SIGSEGV in most cases:
> gdb application core.31889
[...]
Program terminated with signal 11, Segmentation fault.
[...]
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from
/usr/local/lib/python2.2/lib-dynload/time.so...done.
Loaded symbols for /usr/local/lib/python2.2/lib-dynload/time.so
#0 0x08078763 in class_dealloc (op=0x81a8624) at
Objects/classobject.c:169
169 _PyObject_GC_UNTRACK(op);
(gdb) bt
#0 0x08078763 in class_dealloc (op=0x81a8624) at
Objects/classobject.c:169
#1 0x080daefa in PyThreadState_Clear (tstate=0x816b7f0) at
Python/pystate.c:190
#2 0x080dab89 in PyInterpreterState_Clear (interp=0x81427e8) at
Python/pystate.c:77
#3 0x080dce1e in Py_EndInterpreter (tstate=0x816b7f0) at
Python/pythonrun.c:381
#4 0x0805c287 in ~PClass (this=0x81421d0) at pclass.cpp:123
When the 2nd object is destroyed some seconds later, everything
seems to be fine. It only crashes when the 2 objects are deleted
within a short period of time.
I've tried this with the SuSE RPMs of Python 2.2.1 and a self-built
Python-2.2.2 with the same result. :-(
Here's a very short snippet of the python related code in my class:
// Constructor, initializes Python sub-interpreter
PClass::PClass()
{
PyEval_AcquireLock();
py_state=Py_NewInterpreter();
PyEval_SaveThread();
}
// destructor, kills the Python sub-interpreter
PClass::~PClass()
{
PyEval_RestoreThread(py_state);
Py_EndInterpreter(py_state);
py_state=NULL;
PyEval_ReleaseLock(); // release lock
}
// thread code, runs Python function
void
PClass::run()
{
PyEval_RestoreThread(py_state);
PyObject_CallFunction(...)
PyEval_SaveThread();
}
--
Comment By: Gernot Hillier (yoda_gh)
Date: 2005-01-08 09:52
Message:
Logged In: YES
user_id=633130
Hmm, I'm quite sorry, but I changed my application quite thoroughly
in the meantime and never ever experienced any problem again -
and the application is widely used in the meantime.
I also can't really remember what I've changed in the "workaround"
of 2002-11-21 07:09. I could try to find these details if someone is
really interested in my old archives, but if not, I'll consider this as
fixed/"works for me" now.
--
Comment By: Facundo Batista (facundobatista)
Date: 2005-01-08 06:19
Message:
Logged In: YES
user_id=752496
Please, could you verify if this problem persists in Python 2.3.4
or 2.4?
If yes, in which version? Can you provide a test case?
If the problem is solved, from which version?
Note that if you fail to answer in one month, I'll close this bug
as "Won't fix".
Thank you!
.Facundo
--
Comment By: Guido van Rossum (gvanrossum)
Date: 2003-02-11 22:10
Message:
Logged In: YES
user_id=6380
No time for this now, lowering priority. If someone has a
patch, feel free to submit to SF.
--
Comment By: Tim Peters (tim_one)
Date: 2002-12-31 22:35
Message:
Logged In: YES
user_id=31435
Guido should look at it -- subinterpreters were his idea
.
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2002-12-31 14:19
Message:
Logged In: YES
user_id=33168
Tim, it was suggested you see this. Is this documented
somewhere? What should be done?
--
Comment By: Grzegorz Makarewicz (makaron)
Date: 2002-11-21 10:31
Message:
Logged In: YES
user_id=115179
I think it should be documented and additional check
performed before killing thread state or interpereter.
Leave it open - Tim Pet
[ python-Bugs-1048878 ] shutil.copytree copies stat of files, but not of dirs
Bugs item #1048878, was opened at 2004-10-18 00:12 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1048878&group_id=5470 Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Thomas Waldmann (thomaswaldmann) >Assigned to: Johannes Gijsbers (jlgijsbers) Summary: shutil.copytree copies stat of files, but not of dirs Initial Comment: Caring for stat of files, but modifying stat of dirs is maybe not what's expected from that function. I discovered that when implementing a new function in MoinMoin when it changed directory modes from -rw-rw to -rw---. It is easy to fix: $ diff -u shutil.py shutil.py-tw --- shutil.py 2004-10-17 23:19:25.0 +0200 +++ shutil.py-tw2004-10-18 00:01:57.0 +0200 @@ -109,6 +109,7 @@ """ names = os.listdir(src) os.mkdir(dst) +copystat(src, dst) errors = [] for name in names: srcname = os.path.join(src, name) Maybe it is even better to do that copystat after the for loop (and thus, after the recursive calls modifying the timestamp of the directory) and before the if statement, so it may even conserve the dir timestamp (I didn't test that). It happens in 2.3.4 as well as in 2.4 beta 1. Strictly taken, it is not a bug, as the docs say nothing about what it does to directories. But well, maybe just the docs need to be changed as well. :) -- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-01-08 13:32 Message: Logged In: YES user_id=469548 Fixed by applying patch #1094015. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1048878&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-975763 ] shutil.copytree uses os.mkdir instead of os.mkdirs
Bugs item #975763, was opened at 2004-06-19 08:35 Message generated for change (Settings changed) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=975763&group_id=5470 Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 3 Submitted By: Brett Cannon (bcannon) >Assigned to: Johannes Gijsbers (jlgijsbers) Summary: shutil.copytree uses os.mkdir instead of os.mkdirs Initial Comment: shutil.copytree uses os.mkdir instead of os.mkdirs for creating the new destination directory. Any reason why it doesn't use os.mkdirs? If there is the docs should be made more specific in stating that it will not create intermediate directories for the destination. -- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-01-08 13:33 Message: Logged In: YES user_id=469548 Fixed by applying patch #1094015. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=975763&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1095342 ] General FAQ: list.sort() out of date
Bugs item #1095342, was opened at 2005-01-04 00:16 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1095342&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Tim Delaney (tcdelaney) >Assigned to: Johannes Gijsbers (jlgijsbers) Summary: General FAQ: list.sort() out of date Initial Comment: http://www.python.org/doc/faq/general.html#why- doesn-t-list-sort-return-the-sorted-list specifies the idiom: keys = dict.keys() keys.sort() for key in keys: ...do whatever with dict[key]... and doesn't mention sorted(). I would suggest the following wording be used: In situations where performance matters, making a copy of the list just to sort it would be wasteful. Therefore, list.sort() sorts the list in place. In order to remind you of that fact, it does not return the sorted list. This way, you won't be fooled into accidentally overwriting a list when you need a sorted copy but also need to keep the unsorted version around. In Python 2.4 a new builtin - sorted() - has been added. This function creates a new list from the passed iterable, sorts it and returns it. As a result, here's the idiom to iterate over the keys of a dictionary in sorted order: for key in sorted(dict.iterkeys()): ...do whatever with dict[key]... -- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-01-08 13:41 Message: Logged In: YES user_id=469548 Fixed in rev 1.22 of general.ht. Thanks for the new text! -- Comment By: Tim Delaney (tcdelaney) Date: 2005-01-04 01:28 Message: Logged In: YES user_id=603121 Updated text: In situations where performance matters, making a copy of the list just to sort it would be wasteful. Therefore, list.sort() sorts the list in place. In order to remind you of that fact, it does not return the sorted list. This way, you won't be fooled into accidentally overwriting a list when you need a sorted copy but also need to keep the unsorted version around. In Python 2.4 a new builtin - sorted() - has been added. This function creates a new list from a passed iterable, sorts it and returns it. As a result, here's the idiom to iterate over the keys of a dictionary in sorted order: for key in sorted(dict.iterkeys()): ...do whatever with dict[key]... Versions of Python prior to 2.4 need to use the following idiom: keys = dict.keys() keys.sort() for key in keys: ...do whatever with dict[key]... -- Comment By: Tim Delaney (tcdelaney) Date: 2005-01-04 00:21 Message: Logged In: YES user_id=603121 Do we want to also reference the 2.3 and earlier idiom? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1095342&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-756982 ] mailbox should use email not rfc822
Bugs item #756982, was opened at 2003-06-19 04:19 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=756982&group_id=5470 Category: Extension Modules Group: Python 2.3 >Status: Open >Resolution: None Priority: 5 Submitted By: Ben Leslie (benno37) Assigned to: Barry A. Warsaw (bwarsaw) Summary: mailbox should use email not rfc822 Initial Comment: The mailbox module uses the rfc822 module as its default factory for creating message objects. The rfc822 documentation claims that its use is deprecated. The mailbox module should probably use the new email module as its default factory. Of course this has backward compatibility issues, in which case it should at least be mentioned in the mailbox documentation that it uses the deprecated rfc822 module, and provide an example of how to use the email module instead. -- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-01-08 15:22 Message: Logged In: YES user_id=469548 So, with the plans to seriously start working deprecating rfc822, should we use the email module as the default factory now? -- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-06-20 23:48 Message: Logged In: YES user_id=12800 I've added some sample code to the mailbox documentation that explain how to use the email package with the mailbox module. We can't change the default for backward compatibility reasons, as you point out. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=756982&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1098497 ] typo in "Python Tutorial": 1. Whetting your appetite
Bugs item #1098497, was opened at 2005-01-08 16:06 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=1098497&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ludootje (ludootje) Assigned to: Nobody/Anonymous (nobody) Summary: typo in "Python Tutorial": 1. Whetting your appetite Initial Comment: URL: http://docs.python.org/tut/node3.html In the first paragraph, it says: "[snip] or the feature involves a system call or other function that is only accessible from C ...Usually the problem [snip]" The typo: "[snip] C ...Usually [snip]" The space after 'C' should be removed, and one should be added before 'Usually', so it becomes: "[snip] C... Usually [snip]". I admit it's not a really big problem, but it's not hard to solve either, I guess. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1098497&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1098497 ] typo in "Python Tutorial": 1. Whetting your appetite
Bugs item #1098497, was opened at 2005-01-08 16:06 Message generated for change (Comment added) made by ludootje You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1098497&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ludootje (ludootje) Assigned to: Nobody/Anonymous (nobody) Summary: typo in "Python Tutorial": 1. Whetting your appetite Initial Comment: URL: http://docs.python.org/tut/node3.html In the first paragraph, it says: "[snip] or the feature involves a system call or other function that is only accessible from C ...Usually the problem [snip]" The typo: "[snip] C ...Usually [snip]" The space after 'C' should be removed, and one should be added before 'Usually', so it becomes: "[snip] C... Usually [snip]". I admit it's not a really big problem, but it's not hard to solve either, I guess. -- >Comment By: Ludootje (ludootje) Date: 2005-01-08 16:34 Message: Logged In: YES user_id=313612 I'm not too sure what I should do with another error in the tutorial... I guess starting a new bugreport each time for stuff like simple typos would be overkill, so maybe it's just easier to attach (an)other error(s) here? If you prefer a new bugreport, please tell me. Anyway, on to the actual "error"... URL: http://docs.python.org/tut/node4.html Part: 2.2.2 Executable Python Scripts Sentence: "The script can be given a executable mode, or permission, using the chmod command:" Should be: "aN executable mode", AFAIK. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1098497&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-756982 ] mailbox should use email not rfc822
Bugs item #756982, was opened at 2003-06-18 22:19 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=756982&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Ben Leslie (benno37) Assigned to: Barry A. Warsaw (bwarsaw) Summary: mailbox should use email not rfc822 Initial Comment: The mailbox module uses the rfc822 module as its default factory for creating message objects. The rfc822 documentation claims that its use is deprecated. The mailbox module should probably use the new email module as its default factory. Of course this has backward compatibility issues, in which case it should at least be mentioned in the mailbox documentation that it uses the deprecated rfc822 module, and provide an example of how to use the email module instead. -- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2005-01-08 10:49 Message: Logged In: YES user_id=12800 It's a good question. I'd like to say yes so that we can start adding deprecation warnings to rfc822 for Python 2.5. -- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-01-08 09:22 Message: Logged In: YES user_id=469548 So, with the plans to seriously start working deprecating rfc822, should we use the email module as the default factory now? -- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-06-20 17:48 Message: Logged In: YES user_id=12800 I've added some sample code to the mailbox documentation that explain how to use the email package with the mailbox module. We can't change the default for backward compatibility reasons, as you point out. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=756982&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1098497 ] typo in "Python Tutorial": 1. Whetting your appetite
Bugs item #1098497, was opened at 2005-01-08 16:06 Message generated for change (Comment added) made by ludootje You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1098497&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ludootje (ludootje) Assigned to: Nobody/Anonymous (nobody) Summary: typo in "Python Tutorial": 1. Whetting your appetite Initial Comment: URL: http://docs.python.org/tut/node3.html In the first paragraph, it says: "[snip] or the feature involves a system call or other function that is only accessible from C ...Usually the problem [snip]" The typo: "[snip] C ...Usually [snip]" The space after 'C' should be removed, and one should be added before 'Usually', so it becomes: "[snip] C... Usually [snip]". I admit it's not a really big problem, but it's not hard to solve either, I guess. -- >Comment By: Ludootje (ludootje) Date: 2005-01-08 18:06 Message: Logged In: YES user_id=313612 URL: http://docs.python.org/tut/node5.html Part: 3.1.3 Unicode Strings Sentence: "Previously, there were only 256 possible ordinals for script characters and texts were typically bound to a code page which mapped the ordinals to script characters." I'm not sure if I totally "get" this sentence, but if I do, adding a comma after "characters" (the first occurence of it) would make it more clear or readable, IMHO. This would lead to: "Previously, there were only 256 possible ordinals for script characters, and texts were typically bound to a code page which mapped the ordinals to script characters." Just a thought. -- Comment By: Ludootje (ludootje) Date: 2005-01-08 16:34 Message: Logged In: YES user_id=313612 I'm not too sure what I should do with another error in the tutorial... I guess starting a new bugreport each time for stuff like simple typos would be overkill, so maybe it's just easier to attach (an)other error(s) here? If you prefer a new bugreport, please tell me. Anyway, on to the actual "error"... URL: http://docs.python.org/tut/node4.html Part: 2.2.2 Executable Python Scripts Sentence: "The script can be given a executable mode, or permission, using the chmod command:" Should be: "aN executable mode", AFAIK. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1098497&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1098497 ] typo in "Python Tutorial": 1. Whetting your appetite
Bugs item #1098497, was opened at 2005-01-08 16:06 Message generated for change (Comment added) made by ludootje You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1098497&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ludootje (ludootje) Assigned to: Nobody/Anonymous (nobody) Summary: typo in "Python Tutorial": 1. Whetting your appetite Initial Comment: URL: http://docs.python.org/tut/node3.html In the first paragraph, it says: "[snip] or the feature involves a system call or other function that is only accessible from C ...Usually the problem [snip]" The typo: "[snip] C ...Usually [snip]" The space after 'C' should be removed, and one should be added before 'Usually', so it becomes: "[snip] C... Usually [snip]". I admit it's not a really big problem, but it's not hard to solve either, I guess. -- >Comment By: Ludootje (ludootje) Date: 2005-01-08 18:16 Message: Logged In: YES user_id=313612 URL: http://docs.python.org/tut/node5.html Part: 3.1.3 Unicode Strings Sentence: The small "u" in front of the quote indicates that an Unicode string is supposed to be created. Isn't it "a Unicode", instead of "an Unicode"? I wasn't too sure of this one, but Googling for both brings up much more results for "a Unicode", and, more importantly, the results are from more "official" entities (like unicode.org, for example). -- Comment By: Ludootje (ludootje) Date: 2005-01-08 18:06 Message: Logged In: YES user_id=313612 URL: http://docs.python.org/tut/node5.html Part: 3.1.3 Unicode Strings Sentence: "Previously, there were only 256 possible ordinals for script characters and texts were typically bound to a code page which mapped the ordinals to script characters." I'm not sure if I totally "get" this sentence, but if I do, adding a comma after "characters" (the first occurence of it) would make it more clear or readable, IMHO. This would lead to: "Previously, there were only 256 possible ordinals for script characters, and texts were typically bound to a code page which mapped the ordinals to script characters." Just a thought. -- Comment By: Ludootje (ludootje) Date: 2005-01-08 16:34 Message: Logged In: YES user_id=313612 I'm not too sure what I should do with another error in the tutorial... I guess starting a new bugreport each time for stuff like simple typos would be overkill, so maybe it's just easier to attach (an)other error(s) here? If you prefer a new bugreport, please tell me. Anyway, on to the actual "error"... URL: http://docs.python.org/tut/node4.html Part: 2.2.2 Executable Python Scripts Sentence: "The script can be given a executable mode, or permission, using the chmod command:" Should be: "aN executable mode", AFAIK. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1098497&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1098618 ] socket.setdefaulttimeout() breaks smtplib.starttls()
Bugs item #1098618, was opened at 2005-01-08 14:24
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=1098618&group_id=5470
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Cowles (mdcowles)
Assigned to: Nobody/Anonymous (nobody)
Summary: socket.setdefaulttimeout() breaks smtplib.starttls()
Initial Comment:
If you use socket.setdefaulttimeout() to set a socket
timeout, and then do smtplib.starttls(), no data is read after
TLS is started.
Here's a session that's as you'd expect:
>>> import smtplib
>>> s=smtplib.SMTP("smtp.example.com")
>>> s.set_debuglevel(1)
>>> s.helo()
send: 'helo mint-julep.mondoinfo.com\r\n'
reply: '250 smtpout-1.example.net\r\n'
reply: retcode (250); Msg: smtpout-1.example.net
(250, 'smtpout-1.example.net')
>>> s.starttls()
send: 'STARTTLS\r\n'
reply: '220 Ready to start TLS\r\n'
reply: retcode (220); Msg: Ready to start TLS
(220, 'Ready to start TLS')
>>> s.ehlo()
send: 'ehlo mint-julep.mondoinfo.com\r\n'
reply: '250-smtpout-1.example.net\r\n'
reply: '250-PIPELINING\r\n'
reply: '250-SIZE 32768000\r\n'
reply: '250-VRFY\r\n'
reply: '250-ETRN\r\n'
reply: '250-AUTH LOGIN PLAIN DIGEST-MD5\r\n'
reply: '250-AUTH=LOGIN PLAIN DIGEST-MD5\r\n'
reply: '250 8BITMIME\r\n'
reply: retcode (250); Msg: smtpout-1.example.net
PIPELINING
SIZE 32768000
VRFY
ETRN
AUTH LOGIN PLAIN DIGEST-MD5
AUTH=LOGIN PLAIN DIGEST-MD5
8BITMIME
(250,
'smtpout-1.example.net\nPIPELINING\nSIZE
32768000\nVRFY\nETRN\nAUTH LOGIN PLAIN DIGEST-
MD5\nAUTH=LOGIN PLAIN DIGEST-MD5\n8BITMIME')
>>> s.quit()
send: 'quit\r\n'
reply: '221 Bye\r\n'
reply: retcode (221); Msg: Bye
But if I set a socket timeout, I get this:
>>> import socket
>>> socket.setdefaulttimeout(30)
>>> s=smtplib.SMTP("smtp.example.com")
>>> s.set_debuglevel(1)
>>> s.helo()
send: 'helo mint-julep.mondoinfo.com\r\n'
reply: '250 smtpout-1.example.net\r\n'
reply: retcode (250); Msg: smtpout-1.example.net
(250, 'smtpout-1.example.net')
>>> s.starttls()
send: 'STARTTLS\r\n'
reply: '220 Ready to start TLS\r\n'
reply: retcode (220); Msg: Ready to start TLS
(220, 'Ready to start TLS')
>>> s.ehlo()
send: 'ehlo mint-julep.mondoinfo.com\r\n'
^CTraceback (most recent call last):
File "", line 1, in ?
File "/Library/Frameworks/Python.framework/Versions/2.4/
lib/python2.4/smtplib.py", line 391, in ehlo
(code,msg)=self.getreply()
File "/Library/Frameworks/Python.framework/Versions/2.4/
lib/python2.4/smtplib.py", line 345, in getreply
line = self.file.readline()
File "/Library/Frameworks/Python.framework/Versions/2.4/
lib/python2.4/smtplib.py", line 160, in readline
chr = self.sslobj.read(1)
KeyboardInterrupt
(I waited ten or fifteen seconds before typing the control-c.)
If I set the socket timeout back to None, it works correctly:
>>> socket.setdefaulttimeout(None)
>>> s=smtplib.SMTP("smtp.example.com")
>>> s.helo()
(250, 'smtpout-2.example.net')
>>> s.starttls()
(220, 'Ready to start TLS')
>>> s.ehlo()
(250,
'smtpout-2.example.net\nPIPELINING\nSIZE
32768000\nVRFY\nETRN\nAUTH LOGIN PLAIN DIGEST-
MD5\nAUTH=LOGIN PLAIN DIGEST-MD5\n8BITMIME')
>>> s.quit()
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1098618&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1096310 ] sys.__stdout__ doco isn't discouraging enough
Bugs item #1096310, was opened at 2005-01-05 04:18 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1096310&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Just van Rossum (jvr) Assigned to: Nobody/Anonymous (nobody) Summary: sys.__stdout__ doco isn't discouraging enough Initial Comment: sys.__stdout__ is quite often abused (two independent sightings on c.l.py yesterday): people use it to restore stdout instead of saving the previous stdout. The real intended use for __stdout__ isn't all that clear (I keep wondering myself why it's there in the first place; its use case must be quite obscure), but more importantly I think the sys docs should contain a warning that __stdout__ is *not* suitable to restore sys.stdout after redirection. I'd produce a patch if I knew how to better describe what sys.__stdout__ was *for*. -- >Comment By: Kurt B. Kaiser (kbk) Date: 2005-01-08 17:41 Message: Logged In: YES user_id=149084 In IDLE it's useful for debugging: print>>sys.__stderr__, "!!!BOO!!!" will print a message to the console no matter what the redirection status is. So that's a use in addition to the two given in the sys module docs. Agreed that its bad practice to use them to restore redirection, but that IMO belongs in a tutorial, not the reference docs -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1096310&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1098497 ] typo in "Python Tutorial": 1. Whetting your appetite
Bugs item #1098497, was opened at 2005-01-08 16:06 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1098497&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Ludootje (ludootje) >Assigned to: Johannes Gijsbers (jlgijsbers) Summary: typo in "Python Tutorial": 1. Whetting your appetite Initial Comment: URL: http://docs.python.org/tut/node3.html In the first paragraph, it says: "[snip] or the feature involves a system call or other function that is only accessible from C ...Usually the problem [snip]" The typo: "[snip] C ...Usually [snip]" The space after 'C' should be removed, and one should be added before 'Usually', so it becomes: "[snip] C... Usually [snip]". I admit it's not a really big problem, but it's not hard to solve either, I guess. -- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-01-09 01:16 Message: Logged In: YES user_id=469548 I checked in fixes for the problems you reported: 1. Fixed as you suggested. 2. Fixed as you suggested. 3. Split up the two into separate sentences. 4. It's "a Unicode" string. 'a' vs. 'an' is about pronunciation (e.g.: an MRI). So, fixed as you suggested. I'll close this bug now, but feel free to reopen it if you find anymore problems with the tutorial. -- Comment By: Ludootje (ludootje) Date: 2005-01-08 18:16 Message: Logged In: YES user_id=313612 URL: http://docs.python.org/tut/node5.html Part: 3.1.3 Unicode Strings Sentence: The small "u" in front of the quote indicates that an Unicode string is supposed to be created. Isn't it "a Unicode", instead of "an Unicode"? I wasn't too sure of this one, but Googling for both brings up much more results for "a Unicode", and, more importantly, the results are from more "official" entities (like unicode.org, for example). -- Comment By: Ludootje (ludootje) Date: 2005-01-08 18:06 Message: Logged In: YES user_id=313612 URL: http://docs.python.org/tut/node5.html Part: 3.1.3 Unicode Strings Sentence: "Previously, there were only 256 possible ordinals for script characters and texts were typically bound to a code page which mapped the ordinals to script characters." I'm not sure if I totally "get" this sentence, but if I do, adding a comma after "characters" (the first occurence of it) would make it more clear or readable, IMHO. This would lead to: "Previously, there were only 256 possible ordinals for script characters, and texts were typically bound to a code page which mapped the ordinals to script characters." Just a thought. -- Comment By: Ludootje (ludootje) Date: 2005-01-08 16:34 Message: Logged In: YES user_id=313612 I'm not too sure what I should do with another error in the tutorial... I guess starting a new bugreport each time for stuff like simple typos would be overkill, so maybe it's just easier to attach (an)other error(s) here? If you prefer a new bugreport, please tell me. Anyway, on to the actual "error"... URL: http://docs.python.org/tut/node4.html Part: 2.2.2 Executable Python Scripts Sentence: "The script can be given a executable mode, or permission, using the chmod command:" Should be: "aN executable mode", AFAIK. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1098497&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1081879 ] Pydoc can't find browser (bug+solution!)
Bugs item #1081879, was opened at 2004-12-09 06:14
Message generated for change (Settings changed) made by jlgijsbers
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1081879&group_id=5470
>Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Stewart Midwinter (midtoad)
Assigned to: Nobody/Anonymous (nobody)
Summary: Pydoc can't find browser (bug+solution!)
Initial Comment:
I've got Python 2.3 installed on Mandrake Linux 10.1 with
KDE 3.2 running. When I run "pydoc -g" and search on
any term, if I try to display the relevant documentation,
pydoc throws an exception:
Traceback (most recent call last):
File "/usr/lib/python2.3/lib-tk/Tkinter.py", line 1345, in
__call__
return self.func(*args)
File "/usr/lib/python2.3/pydoc.py", line 1970, in open
webbrowser.open(url)
File "/usr/lib/python2.3/webbrowser.py", line 43, in
open
get().open(url, new, autoraise)
File "/usr/lib/python2.3/webbrowser.py", line 38, in get
raise Error("could not locate runnable browser")
Error: could not locate runnable browser
I did some research and found that the problem is that
KDE sets the BROWSER environment variable to an
unexpected value:
BROWSER='kfmclient openProfile webbrowsing'
The solution would be to test for this strange setting. I
patched webbrowser.py on my system in an inelegant
fashion by simply inserting the following code at the top
of the file, just after the 'import' statements:
#patch for KDE mangling of BROWSER environment
variable
#per:
http://mail.python.org/pipermail/tutor/2004-September/032060.html
if os.environ.has_key("BROWSER") and \
os.environ["BROWSER"]=='kfmclient openProfile
webbrowsing':
os.environ["BROWSER"] = 'konqueror' # set it to
konqueror
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1081879&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1010196 ] xml.dom documentation omits hasAttribute, hasAttributeNS
Bugs item #1010196, was opened at 2004-08-16 20:12 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1010196&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Mike Brown (mike_j_brown) >Assigned to: Johannes Gijsbers (jlgijsbers) Summary: xml.dom documentation omits hasAttribute, hasAttributeNS Initial Comment: http://www.python.org/doc/2.3.4/lib/dom-element- objects.html does not mention hasAttribute() and hasAttributeNS(), which are DOM L2 Core methods present on Element objects. They should be mentioned not just for completeness, but also so that people are not tempted to use getAttribute() and getAttributeNS() to test for attribute existence. -- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-01-09 01:40 Message: Logged In: YES user_id=469548 Fixed by applying patch #1051321. -- Comment By: Mike Brown (mike_j_brown) Date: 2004-10-21 10:40 Message: Logged In: YES user_id=371366 OK, submitted as patch # 1051321 https://sourceforge.net/tracker/index.php?func=detail&aid=1051321&group_id=5470&atid=305470 -- Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-20 10:29 Message: Logged In: YES user_id=80475 Can you draft a patch? For the LaTeX markup, just mimic the surrounding text. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1010196&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1013525 ] xml.dom documentation omits createDocument, ...DocumentType
Bugs item #1013525, was opened at 2004-08-21 22:22 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1013525&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Mike Brown (mike_j_brown) >Assigned to: Johannes Gijsbers (jlgijsbers) Summary: xml.dom documentation omits createDocument, ...DocumentType Initial Comment: http://www.python.org/doc/2.3.4/lib/dom- implementation-objects.html mentions that DOM L2 Core methods exist on DomImplementation objects to create Document and DocumentType objects, but does not say what the methods are, nor does it adequately document the one method that is documented: hasFeature(). The documentation should be updated to say what hasFeature does with its arguments and what it returns. Documentation for the createDocument() and createDocumentType() methods should be added to this page as well. -- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-01-09 01:40 Message: Logged In: YES user_id=469548 Fixed by applying patch 1051321. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1013525&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-991805 ] Documentation of DOMImplmentation lacking
Bugs item #991805, was opened at 2004-07-15 20:37 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991805&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Robert M. Zigweid (rzigweid) >Assigned to: Johannes Gijsbers (jlgijsbers) Summary: Documentation of DOMImplmentation lacking Initial Comment: The documentation for DOMImplementation is lacking. While I realize that there are several possible DOMImplementations, the default one seems to have no documentation. If it is documented, a cross reference needs to be made on the minidom documentation (Section 13.7), where DOMImplementation.createDocument is referenced. I want to know what the arguments are supposed to be. Examples are great, but they don't replace documentation. p.s. Barry made me do it. :) -- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-01-09 01:43 Message: Logged In: YES user_id=469548 This should be fixed by patch #1051321. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991805&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-886619 ] wrong documentation for popen2
Bugs item #886619, was opened at 2004-01-29 01:07 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=886619&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Serge Winitzki (winitzki) Assigned to: Nobody/Anonymous (nobody) Summary: wrong documentation for popen2 Initial Comment: the python 2.3.3 library documentation for popen2 says: ( file:///usr/share/doc/python2.3/html/lib/module-popen2.html) popen2( cmd[, bufsize[, mode]]) Executes cmd as a sub-process. Returns the file objects (child_stdout, child_stdin). however, the actual behavior of python 2.3.3 is to return (child_stdin, child_stdout) - in the reverse order. I haven't checked with popen3 and popen4. thanks. -- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-01-09 02:08 Message: Logged In: YES user_id=469548 This has either been fixed in Python 2.4, or you're confusing popen2.popen2 with os.popen2, which does return the file objects in the order you describe. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=886619&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-489256 ] Lib/profile.doc should be updated
Bugs item #489256, was opened at 2001-12-05 06:51 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=489256&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Lib/profile.doc should be updated Initial Comment: What's Lib/profile.doc doing there? Is it still needed? Why is it in Lib, anyway? (it seems very old - is it still up to date after all the hackery? doesn't seem so) -- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-01-09 02:27 Message: Logged In: YES user_id=469548 I would like to go ahead with removing profile.doc and the help() function from profile.py for Python 2.5. They're not really all that helpful, they're in an unexpected place, and they're undocumented. I'll remove them if there are no objections within some weeks. -- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-05 07:08 Message: Logged In: YES user_id=3066 profile.doc is used as the help file for profile.py, and is read by an external pager (sloppily) using the profile.help() function. Either the document should be updated and the help() function should be more intelligent about the pager, or... ...the document and the help() function should be removed. This is a possibility since help() is not documented. profile.doc should be updated for Python 2.2; other changes will need to wait for Python 2.3. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=489256&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1017546 ] test_inspect.py fails to clean up upon failure
Bugs item #1017546, was opened at 2004-08-27 14:20 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1017546&group_id=5470 Category: Build Group: Python 2.4 >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Michael (ms_) Assigned to: Nobody/Anonymous (nobody) Summary: test_inspect.py fails to clean up upon failure Initial Comment: When test_inspect.py encounters a failure in the code it's testing it fails to clean up its temporary files upon exit. This causes spurious errors for other tests when debugging. eg: force a test to fail by changing test_inspect.py such that this: test(inspect.getsource(mod2.wrapped) == sourcerange(13, 16), "inspect.getsource(mod.wrapped)") Is replaced with: test(inspect.getsource(mod2.wrapped) != sourcerange(13, 16), "inspect.getsource(mod.wrapped)") Clearly this should only cause test_inspect.py to fail, however: # ./python Lib/test/regrtest.py test_inspect test_posixpath test_inspect test test_inspect failed -- inspect.getsource(mod.wrapped) test_posixpath test test_posixpath failed -- Traceback (most recent call last): File "/home/michaels/Python/Cvs/python/dist/src/Lib/test/test_posixpath.py", line 148, in test_islink os.symlink(test_support.TESTFN + "1", test_support.TESTFN + "2") OSError: [Errno 17] File exists 2 tests failed: test_inspect test_posixpath In this example the reason why test_posixpath failed is due to the temporary files left behind by the failed test_inspect. -- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-01-09 02:41 Message: Logged In: YES user_id=469548 The new test_inspect no longer writes temporary files, so I'm closing this bug. -- Comment By: Michael (ms_) Date: 2004-08-27 14:27 Message: Logged In: YES user_id=994316 Patch against current Anon CVS can be found here: * http://www.python.org/sf/1017550 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1017546&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-769569 ] weird/buggy inspect.getsource behavious
Bugs item #769569, was opened at 2003-07-11 12:42
Message generated for change (Comment added) made by jlgijsbers
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=769569&group_id=5470
Category: Python Library
Group: Python 2.2.2
>Status: Closed
>Resolution: Works For Me
Priority: 5
Submitted By: Sebastien de Menten (sdementen)
Assigned to: Nobody/Anonymous (nobody)
Summary: weird/buggy inspect.getsource behavious
Initial Comment:
Using python 2.2.2 on a mandrake 9.1 with the inspect.py of python
2.2.3 (correction for lambda keyword), I run the following code
"""
import inspect
a = [ None,
lambda x: x>1 and x<0,
None]
print "Ok",inspect.getsource(a[1])
if 1:
a = [ None,
lambda x: x>1 and x<0,
None]
print "Ko",inspect.getsource(a[1])
"""
Two weird behaviours occurs
1. The line "print "Ok",inspect.getsource(a[1])" prints
Ok lambda x: x>1 and x<0,
None]
It prints a superfluous line.
2. The line "print "Ko",inspect.getsource(a[1])" raises an
exception
Ko
Traceback (most recent call last):
File "bug-inspect.py", line 13, in ?
print "Ko",inspect.getsource(a[1])
File "/usr/lib/python2.2/inspect.py", line 523, in getsource
lines, lnum = getsourcelines(object)
File "/usr/lib/python2.2/inspect.py", line 515, in getsourcelines
else: return getblock(lines[lnum:]), lnum + 1
File "/usr/lib/python2.2/inspect.py", line 498, in getblock
tokenize.tokenize(ListReader(lines).readline,
BlockFinder().tokeneater)
File "/usr/lib/python2.2/tokenize.py", line 138, in tokenize
tokenize_loop(readline, tokeneater)
File "/usr/lib/python2.2/tokenize.py", line 144, in tokenize_loop
for token_info in generate_tokens(readline):
File "/usr/lib/python2.2/tokenize.py", line 218, in generate_tokens
raise TokenError, ("EOF in multi-line statement", (lnum, 0))
tokenize.TokenError: ('EOF in multi-line statement', (7, 0))
--
>Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2005-01-09 02:50
Message:
Logged In: YES
user_id=469548
Since patch #1011890 has been checked in, and problem 2 is
unreproducable, I'm closing this.
--
Comment By: Simon Percivall (percivall)
Date: 2004-08-19 03:14
Message:
Logged In: YES
user_id=329382
http://www.python.org/sf/1011890 fixes problem 1.
--
Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-15 14:57
Message:
Logged In: YES
user_id=469548
I can't reproduce problem 2 on today's CVS, but
http://python.org/sf/1006219 fixes problem 1.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=769569&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-769569 ] weird/buggy inspect.getsource behavious
Bugs item #769569, was opened at 2003-07-11 12:42
Message generated for change (Comment added) made by percivall
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=769569&group_id=5470
Category: Python Library
Group: Python 2.2.2
Status: Closed
Resolution: Works For Me
Priority: 5
Submitted By: Sebastien de Menten (sdementen)
Assigned to: Nobody/Anonymous (nobody)
Summary: weird/buggy inspect.getsource behavious
Initial Comment:
Using python 2.2.2 on a mandrake 9.1 with the inspect.py of python
2.2.3 (correction for lambda keyword), I run the following code
"""
import inspect
a = [ None,
lambda x: x>1 and x<0,
None]
print "Ok",inspect.getsource(a[1])
if 1:
a = [ None,
lambda x: x>1 and x<0,
None]
print "Ko",inspect.getsource(a[1])
"""
Two weird behaviours occurs
1. The line "print "Ok",inspect.getsource(a[1])" prints
Ok lambda x: x>1 and x<0,
None]
It prints a superfluous line.
2. The line "print "Ko",inspect.getsource(a[1])" raises an
exception
Ko
Traceback (most recent call last):
File "bug-inspect.py", line 13, in ?
print "Ko",inspect.getsource(a[1])
File "/usr/lib/python2.2/inspect.py", line 523, in getsource
lines, lnum = getsourcelines(object)
File "/usr/lib/python2.2/inspect.py", line 515, in getsourcelines
else: return getblock(lines[lnum:]), lnum + 1
File "/usr/lib/python2.2/inspect.py", line 498, in getblock
tokenize.tokenize(ListReader(lines).readline,
BlockFinder().tokeneater)
File "/usr/lib/python2.2/tokenize.py", line 138, in tokenize
tokenize_loop(readline, tokeneater)
File "/usr/lib/python2.2/tokenize.py", line 144, in tokenize_loop
for token_info in generate_tokens(readline):
File "/usr/lib/python2.2/tokenize.py", line 218, in generate_tokens
raise TokenError, ("EOF in multi-line statement", (lnum, 0))
tokenize.TokenError: ('EOF in multi-line statement', (7, 0))
--
Comment By: Simon Percivall (percivall)
Date: 2005-01-09 03:17
Message:
Logged In: YES
user_id=329382
Bug 2 is reproducable in Python 2.4, but not in CVS head, which stands to
reason, since the latest patch to BlockFinder was meant to deal with these
issues.
--
Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2005-01-09 02:50
Message:
Logged In: YES
user_id=469548
Since patch #1011890 has been checked in, and problem 2 is
unreproducable, I'm closing this.
--
Comment By: Simon Percivall (percivall)
Date: 2004-08-19 03:14
Message:
Logged In: YES
user_id=329382
http://www.python.org/sf/1011890 fixes problem 1.
--
Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-15 14:57
Message:
Logged In: YES
user_id=469548
I can't reproduce problem 2 on today's CVS, but
http://python.org/sf/1006219 fixes problem 1.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=769569&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-769569 ] weird/buggy inspect.getsource behavious
Bugs item #769569, was opened at 2003-07-11 12:42
Message generated for change (Comment added) made by jlgijsbers
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=769569&group_id=5470
Category: Python Library
Group: Python 2.2.2
Status: Closed
Resolution: Works For Me
Priority: 5
Submitted By: Sebastien de Menten (sdementen)
Assigned to: Nobody/Anonymous (nobody)
Summary: weird/buggy inspect.getsource behavious
Initial Comment:
Using python 2.2.2 on a mandrake 9.1 with the inspect.py of python
2.2.3 (correction for lambda keyword), I run the following code
"""
import inspect
a = [ None,
lambda x: x>1 and x<0,
None]
print "Ok",inspect.getsource(a[1])
if 1:
a = [ None,
lambda x: x>1 and x<0,
None]
print "Ko",inspect.getsource(a[1])
"""
Two weird behaviours occurs
1. The line "print "Ok",inspect.getsource(a[1])" prints
Ok lambda x: x>1 and x<0,
None]
It prints a superfluous line.
2. The line "print "Ko",inspect.getsource(a[1])" raises an
exception
Ko
Traceback (most recent call last):
File "bug-inspect.py", line 13, in ?
print "Ko",inspect.getsource(a[1])
File "/usr/lib/python2.2/inspect.py", line 523, in getsource
lines, lnum = getsourcelines(object)
File "/usr/lib/python2.2/inspect.py", line 515, in getsourcelines
else: return getblock(lines[lnum:]), lnum + 1
File "/usr/lib/python2.2/inspect.py", line 498, in getblock
tokenize.tokenize(ListReader(lines).readline,
BlockFinder().tokeneater)
File "/usr/lib/python2.2/tokenize.py", line 138, in tokenize
tokenize_loop(readline, tokeneater)
File "/usr/lib/python2.2/tokenize.py", line 144, in tokenize_loop
for token_info in generate_tokens(readline):
File "/usr/lib/python2.2/tokenize.py", line 218, in generate_tokens
raise TokenError, ("EOF in multi-line statement", (lnum, 0))
tokenize.TokenError: ('EOF in multi-line statement', (7, 0))
--
>Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2005-01-09 03:23
Message:
Logged In: YES
user_id=469548
Hmm, I couldn't and can't reproduce problem 2 under Python
2.4(.0). But this should be moot, as your BlockFinder patch
will be in 2.4.1.
--
Comment By: Simon Percivall (percivall)
Date: 2005-01-09 03:17
Message:
Logged In: YES
user_id=329382
Bug 2 is reproducable in Python 2.4, but not in CVS head, which stands to
reason, since the latest patch to BlockFinder was meant to deal with these
issues.
--
Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2005-01-09 02:50
Message:
Logged In: YES
user_id=469548
Since patch #1011890 has been checked in, and problem 2 is
unreproducable, I'm closing this.
--
Comment By: Simon Percivall (percivall)
Date: 2004-08-19 03:14
Message:
Logged In: YES
user_id=329382
http://www.python.org/sf/1011890 fixes problem 1.
--
Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-15 14:57
Message:
Logged In: YES
user_id=469548
I can't reproduce problem 2 on today's CVS, but
http://python.org/sf/1006219 fixes problem 1.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=769569&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-489256 ] Lib/profile.doc should be updated
Bugs item #489256, was opened at 2001-12-05 06:51 Message generated for change (Settings changed) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=489256&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) >Assigned to: Johannes Gijsbers (jlgijsbers) Summary: Lib/profile.doc should be updated Initial Comment: What's Lib/profile.doc doing there? Is it still needed? Why is it in Lib, anyway? (it seems very old - is it still up to date after all the hackery? doesn't seem so) -- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-01-09 02:27 Message: Logged In: YES user_id=469548 I would like to go ahead with removing profile.doc and the help() function from profile.py for Python 2.5. They're not really all that helpful, they're in an unexpected place, and they're undocumented. I'll remove them if there are no objections within some weeks. -- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-05 07:08 Message: Logged In: YES user_id=3066 profile.doc is used as the help file for profile.py, and is read by an external pager (sloppily) using the profile.help() function. Either the document should be updated and the help() function should be more intelligent about the pager, or... ...the document and the help() function should be removed. This is a possibility since help() is not documented. profile.doc should be updated for Python 2.2; other changes will need to wait for Python 2.3. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=489256&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
