[ python-Bugs-1442493 ] IDLE shell window gets very slow when displaying long lines
Bugs item #1442493, was opened at 2006-03-03 14:45 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=1442493&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Heiko Selber (drhok) Assigned to: Nobody/Anonymous (nobody) Summary: IDLE shell window gets very slow when displaying long lines Initial Comment: I wrote a little python script that prints a large dictionary to stdout (simply using 'print mydictionary'). In fact, the type is irrelevant, what matters is that the resulting output had approx. 200,000 characters. The shell prints the dictionary into a single line, which causes the window to be almost non-responding, e.g. when I try to scroll the window. Even on a high-end PC it takes a minute or even longer to react to anything. I use Python 2.4.2 on Windows XP SP2. I am aware that it is not exactly wise to print such large objects, but I usually print return values to stdout when I debug a script, and I do not always expect an object to be that large. The average text editor handles such long lines much better. A quick workaround might be to break very long lines automagically (perhaps at around column 1000). PS: I already observed the bug some years ago. I think I even submitted it to python or idlefork a long time ago but I was unable to find it in the buglist. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1442493&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1437785 ] Problems w/ expat 1.95.7 vs. Python 2.4
Bugs item #1437785, was opened at 2006-02-24 00:59 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1437785&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: XML Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: Problems w/ expat 1.95.7 vs. Python 2.4 Initial Comment: This may apply to the trunk as well... Today I finished installing 2.4.2 and all our local libraries at work. Trying out the main application I use I discovered Python segfaulting when trying to import pyexpat. It turned out that during the import an earlier module (gtk.glade) also wanted libexpat. Apparently pyexpat was expecting to get Expat 1.95.8 (what's delivered with Python) but got 1.95.7 instead (what we had installed and what was already linked with all our other Expat-using code). The solution was rather simple. I just commented out those constants in the pyexpat initialization that were marked as 1.95.8. Fortunately there was a comment identifying the version dependency. Is there some way that Python's build process can detect the Expat version and conditionally include/exclude bits that are for later versions? -- >Comment By: Martin v. Löwis (loewis) Date: 2006-03-03 18:44 Message: Logged In: YES user_id=21627 I don't understand the problem. The build process should have picked-up the Python-provided expat, and should have ignored the system-installed one in all places (compiling, linking, running). What was the specific sequence of commands that you entered, what what the output you got, and what output would you have expected instead? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1437785&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1432525 ] os.listdir doesn't release GIL
Bugs item #1432525, was opened at 2006-02-15 23:45 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1432525&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.4 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Jonathan Ellis (ellisj) >Assigned to: Georg Brandl (gbrandl) Summary: os.listdir doesn't release GIL Initial Comment: posix_listdir in posixmodule.c does not release the global interpreter lock, blocking all other threads for the duration of the call. -- >Comment By: Martin v. Löwis (loewis) Date: 2006-03-03 18:48 Message: Logged In: YES user_id=21627 The patch looks fine. Please apply. -- Comment By: Georg Brandl (birkenfeld) Date: 2006-02-18 12:13 Message: Logged In: YES user_id=1188172 Attaching a patch. Please check. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1432525&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1421664 ] [win32] stderr atty encoding not set
Bugs item #1421664, was opened at 2006-02-01 18:25
Message generated for change (Settings changed) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1421664&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
>Priority: 6
Submitted By: Snaury (snaury)
>Assigned to: Martin v. Löwis (loewis)
Summary: [win32] stderr atty encoding not set
Initial Comment:
When starting python console application under windows,
output of unicode strings to console fails because of
ansi encoding. I found that in file
Python-2.4.2/Python/sysmodule, _PySys_Init functions,
setting encoding on stderr was forgotten:
#ifdef MS_WINDOWS
if(isatty(_fileno(stdin))){
sprintf(buf, "cp%d", GetConsoleCP());
if (!PyFile_SetEncoding(sysin, buf))
return NULL;
}
if(isatty(_fileno(stdout))) {
sprintf(buf, "cp%d", GetConsoleOutputCP());
if (!PyFile_SetEncoding(sysout, buf))
return NULL;
}
#endif
I think the following lines should be added:
if(isatty(_fileno(stderr))) {
sprintf(buf, "cp%d", GetConsoleOutputCP());
if (!PyFile_SetEncoding(syserr, buf))
return NULL;
}
Otherwise it's inconsistant, as if we set it to sysout,
why not on syserr? And, for example, this code will not
work properly:
#!/usr/bin/env python
# -*- encoding: mbcs -*-
import sys
reload(sys) # bring setdefaultencoding back!
sys.setdefaultencoding("mbcs")
sys.stderr.write(u"\n")
Instead of native text garbage will be printed (if you
change it to sys.stdout, proper text displayed), and
there is no way I know to properly determine and set
encoding just for stderr (file.encoding is read-only,
after all).
--
Comment By: Snaury (snaury)
Date: 2006-02-01 18:29
Message:
Logged In: YES
user_id=1197042
Ooops, sorry, in the example it should be:
print >>sys.stderr, u""
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1421664&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1441884 ] A (treaded) Python crash only on dual core machines
Bugs item #1441884, was opened at 2006-03-02 18:17
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1441884&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: Threads
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Robert Kiendl (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: A (treaded) Python crash only on dual core machines
Initial Comment:
There is a strange freeze/crash only on dual core machines:
I have a python app (Python 2.3.5 /Pythonwin build 203
/ Windows) running with no stability problems on normal
machines (Or a crash is so rare, that absolutely nobody
obverses it, though the overall majority of users uses
single core machines). Threads, network &
pythonwin/win32ui all in use.
Yet, from 3 users, _all_ using a Dual Processor System
(XEON, amd x2 3800+) computer, I have reports, that the
application freezes hard and/or crashes with a kind of
random stack dump (operating system). I cannot
experiment with those machines.
I found no hints other than:
http://groups.google.de/group/comp.lang.python/browse_frm/thread/64ca033e1a7f6c61/719b147e870bd5e6
http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=480325
.. both discussions remaining in uncertainty.
Are there (known) problems with Python/Pythonwin
specifically for dual core's (py2.3.5 / pywin203) ?
What could I do to find the problem?
Robert
--
PS: there is very little C extension-code (SWIG)
involved, yet I looked over that so often, I guess its
save:
//
#include "stdafx.h"
#include "commctrl.h"
#include "ext.h"
BOOL APIENTRY DllMain( HANDLE hModule,
DWORD ul_reason_for_call,
LPVOID lpReserved
)
{
return TRUE;
}
class CAllowThreads {
public:
PyThreadState *_save; \
CAllowThreads() {
_save = PyEval_SaveThread();
}
~CAllowThreads() {
PyEval_RestoreThread(_save);
}
};
PyObject* PyListView_GetSubItemRect(
HWND hwndLV,
int iItem,
int iSubItem,
int code
//LPRECT lpRect
)
{
RECT r;
{
CAllowThreads _t;
ListView_GetSubItemRect(
hwndLV,
iItem,
iSubItem,
code,
&r );
}
return Py_BuildValue("",
r.left,r.top,r.right,r.bottom);
}
int GetStringAddr(const char* s) {
return (int)s;
}
int PlaySoundResource(int resid, HMODULE hmod)
{
CAllowThreads _t;
return PlaySound(MAKEINTRESOURCE(resid), hmod,
SND_RESOURCE);
}
int PlaySoundFile(const char* fname, int flag)
{
CAllowThreads _t;
return PlaySound(fname, NULL, flag);
}
PyObject* py_ToolTipRelayMsg( PyObject* self,
PyObject* args )
{
MSG msg;
HWND hwTT;
if(!PyArg_ParseTuple(args,"i(i(ii)):ToolTipRelayMsg",
&hwTT,
&msg.hwnd,&msg.message,&msg.wParam,&msg.lParam,&msg.time,
&msg.pt, ((int*)&msg.pt)+1) )
return NULL;
{
CAllowThreads _t;
SendMessage(hwTT,TTM_RELAYEVENT,0,(LPARAM)&msg);
}
Py_INCREF( Py_None );
return Py_None;
}
---
"GetStringAddress" is used only once like this (leades
to correct NUL termination I think):
self.sb.SendMessage(commctrl.SB_SETTEXT,iPane,extension.GetStringAddr(text))
--- swig:
static PyObject *_wrap_GetStringAddr(PyObject *self,
PyObject *args) {
PyObject *resultobj;
char *arg0 ;
int result ;
if(!PyArg_ParseTuple(args,(char
*)"s:GetStringAddr",&arg0)) return NULL;
result = (int )GetStringAddr((char const *)arg0);
resultobj = PyInt_FromLong((long)result);
return resultobj;
}
--
>Comment By: Martin v. Löwis (loewis)
Date: 2006-03-03 18:40
Message:
Logged In: YES
user_id=21627
You don't provide complete source code for anybody to try to reproduce this
problem. My guess is that you are calling into the Python runtime without
holding the global interpreter lock. This can easily create all sorts of
problems.
Never release the GIL unless you are absolutely certain that no Python code
will
be executed; neither directly nor indirectly. Don't invoke Python API in a
thread
(e.g. while processing a Windows message) without acquiring the GIL first.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1441884&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1437785 ] Problems w/ expat 1.95.7 vs. Python 2.4
Bugs item #1437785, was opened at 2006-02-23 17:59 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1437785&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: XML Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: Problems w/ expat 1.95.7 vs. Python 2.4 Initial Comment: This may apply to the trunk as well... Today I finished installing 2.4.2 and all our local libraries at work. Trying out the main application I use I discovered Python segfaulting when trying to import pyexpat. It turned out that during the import an earlier module (gtk.glade) also wanted libexpat. Apparently pyexpat was expecting to get Expat 1.95.8 (what's delivered with Python) but got 1.95.7 instead (what we had installed and what was already linked with all our other Expat-using code). The solution was rather simple. I just commented out those constants in the pyexpat initialization that were marked as 1.95.8. Fortunately there was a comment identifying the version dependency. Is there some way that Python's build process can detect the Expat version and conditionally include/exclude bits that are for later versions? -- >Comment By: Skip Montanaro (montanaro) Date: 2006-03-03 14:15 Message: Logged In: YES user_id=44345 Martin, I'm sorry. If I understood it better I'd explain it better. Tell me if this helps. We have expat 1.95.7 installed. We have C++ libraries that link with that version and are wrapped for use with Python using SWIG. Python 2.4 comes with 1.95.8. Apparently setup.py finds that and compiles pyexpat against it. In the pyexpat init function I see this block of constant initialization: /* Added in Expat 1.95.8. */ MYCONST(XML_ERROR_UNDECLARING_PREFIX); MYCONST(XML_ERROR_INCOMPLETE_PE); MYCONST(XML_ERROR_XML_DECL); MYCONST(XML_ERROR_TEXT_DECL); MYCONST(XML_ERROR_PUBLICID); MYCONST(XML_ERROR_SUSPENDED); MYCONST(XML_ERROR_NOT_SUSPENDED); MYCONST(XML_ERROR_ABORTED); MYCONST(XML_ERROR_FINISHED); MYCONST(XML_ERROR_SUSPEND_PE); If they are left in there, Python reliably segfaults at the first of those lines. When I exclude those lines, everything works fine. If I run ldd over pyexpat.so I don't see that libexpat is dynamically linked in: % ldd pyexpat.so libgcc_s.so.1 => /opt/lang/gcc-3.3.2/lib/libgcc_s.so.1 libc.so.1 => /lib/libc.so.1 libm.so.2 => /lib/libm.so.2 I thus have a statically linked version of libexpat 1.95.8 which appears to be exporting symbols: % nm -p pyexpat.so | egrep XML 042312 T XML_DefaultCurrent 042380 T XML_ErrorString 042428 T XML_ExpatVersion 042452 T XML_ExpatVersionInfo 039164 T XML_ExternalEntityParserCreate 042232 T XML_FreeContentModel 040580 T XML_GetBase 041584 T XML_GetBuffer ... Elsewhere I have a C++ library that is dynamically linked to 1.95.7, so I essentially have libexpat linked into the system twice. Does that seem like a reasonable description of our setup? If so, I can understand that trying to use (for example) XML_ERROR_UNDECLARING_PREFIX (which is new to 1.95.8) with symbols from libexpat 1.95.7 might create problems. I don't see how it could cause problems during constant initialization, but it does, quite reliably. You're much more savvy about these things than I am. Maybe you can see how this would happen. How do we tell Python's build process not to use the bundled 1.95.8? My local C++ gurus tell me they are not willing to rebuild everything with 1.95.8 just to make pyexpat happy. If we tell it that, then those constant initialization lines need to be conditionally exposed to the compiler so that it works to compile with libexpat 1.95.7. -- Comment By: Martin v. Löwis (loewis) Date: 2006-03-03 11:44 Message: Logged In: YES user_id=21627 I don't understand the problem. The build process should have picked-up the Python-provided expat, and should have ignored the system-installed one in all places (compiling, linking, running). What was the specific sequence of commands that you entered, what what the output you got, and what output would you have expected instead? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1437785&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%
[ python-Bugs-1442767 ] docs for os.statvfs miss f_bsize parameter
Bugs item #1442767, was opened at 2006-03-03 22:42 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=1442767&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: Chris Cogdon (chriscog) Assigned to: Nobody/Anonymous (nobody) Summary: docs for os.statvfs miss f_bsize parameter Initial Comment: The documentation for os.statvfs miss the f_bsize parameter. On (for example) os-file-dir.html, it lists the parameters as follows: f_frsize, f_blocks, f_bfree, f_bavail ... (and so on). it SHOULD be: f_bsize, f_frsize, f_blocks, f_bfree, f_bavail ... -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1442767&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1442767 ] docs for os.statvfs miss f_bsize parameter
Bugs item #1442767, was opened at 2006-03-03 14:42 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1442767&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: Chris Cogdon (chriscog) >Assigned to: Neal Norwitz (nnorwitz) Summary: docs for os.statvfs miss f_bsize parameter Initial Comment: The documentation for os.statvfs miss the f_bsize parameter. On (for example) os-file-dir.html, it lists the parameters as follows: f_frsize, f_blocks, f_bfree, f_bavail ... (and so on). it SHOULD be: f_bsize, f_frsize, f_blocks, f_bfree, f_bavail ... -- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-03 15:13 Message: Logged In: YES user_id=33168 Thanks! Fixed. Committed revision 42820. Committed revision 42821. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1442767&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1442874 ] handling comments with markupbase and HTMLParser
Bugs item #1442874, was opened at 2006-03-03 19:15 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=1442874&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Daniel (danielx_) Assigned to: Nobody/Anonymous (nobody) Summary: handling comments with markupbase and HTMLParser Initial Comment: If the following webpage is correct about the definition of a comment, HTMLParser.HTMLParser reports valid (albiet strange) comments as being erroenous: http://www.htmlhelp.com/reference/wilbur/misc/comment.html This site gives '' as an example of a valid html comment. See attachment for what happens at the console. A similar thing happens with other (pathalogical) form of comments. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1442874&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1442874 ] handling comments with markupbase and HTMLParser
Bugs item #1442874, was opened at 2006-03-03 19:15 Message generated for change (Comment added) made by danielx_ You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1442874&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None >Priority: 3 Submitted By: Daniel (danielx_) Assigned to: Nobody/Anonymous (nobody) Summary: handling comments with markupbase and HTMLParser Initial Comment: If the following webpage is correct about the definition of a comment, HTMLParser.HTMLParser reports valid (albiet strange) comments as being erroenous: http://www.htmlhelp.com/reference/wilbur/misc/comment.html This site gives '' as an example of a valid html comment. See attachment for what happens at the console. A similar thing happens with other (pathalogical) form of comments. -- >Comment By: Daniel (danielx_) Date: 2006-03-03 19:17 Message: Logged In: YES user_id=1383230 Sorry, I'm unfamiliar with the bug reporting system and my attachment doesn't seem to have attached. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1442874&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1423082 ] lib-deprecated
Feature Requests item #1423082, was opened at 02/02/06 16:20 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1423082&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: lib-deprecated Initial Comment: obsolete modules are moved to lib-old. deprecated modules remain in the library. This makes the search for a relevant library more difficult. People browsing the code may not realize that they are deprecated. (Example, I found no notice of deprecation within the code for rfc822.) Even when the notice is there, the modules add to the number of alternatives, which hurts One-Obvious-Way-To-Do-It. If these modules were moved to a deprecated directory, these problems would be greatly reduced. (Ensure backwards compatibility by leaving the deprecated directory on the search path.) -- >Comment By: SourceForge Robot (sf-robot) Date: 03/03/06 19:23 Message: Logged In: YES user_id=1312539 This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). -- Comment By: Georg Brandl (birkenfeld) Date: 02/17/06 04:03 Message: Logged In: YES user_id=1188172 I think it's common practise to add a DeprecationWarning to those modules which are deprecated since one or two releases. That should be enough reminder. You should be reading the docs anyway :) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1423082&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1442937 ] Bad Coroutine link
Bugs item #1442937, was opened at 2006-03-04 07:26 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=1442937&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.5 Status: Open Resolution: None Priority: 5 Submitted By: Paddy McCarthy (paddy3118) Assigned to: Nobody/Anonymous (nobody) Summary: Bad Coroutine link Initial Comment: Page http://docs.python.org/dev/whatsnew/node4.html See also box. www.sidhe.org link should be to: http://www.sidhe.org/~dan/blog/archives/000178.html notice the squiggle, (tilde)?, '~' before dan above. Cheers. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1442937&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
