Mailman 3 September 2000 - Python-Dev

problems importing _tkinter on Linux build
by Trent Mick 20 Sep '00

20 Sep '00

I get the following error trying to import _tkinter in a Python 2.0 build: > ./python ./python: error in loading shared libraries: libtk8.3.so: cannot open shared object file: No such file or directory Here is the relevant section of my Modules/Setup: _tkinter _tkinter.c tkappinit.c -DWITH_APPINIT \ -I/usr/local/include \ -I/usr/X11R6/include \ -L/usr/local/lib \ -ltk8.3 -ltcl8.3 \ -L/usr/X11R6/lib \ -lX11 I got the Tcl/Tk 8.3 source from dev.scriptics.com, and ran > ./configure --enable-gcc --enable-shared > make > make install # as root in the tcl and tk source directories. The tcl and tk libs are in /usr/local/lib: [trentm@molotok contrib]$ ls -alF /usr/local/lib ... -r-xr-xr-x 1 root root 579177 Sep 17 14:03 libtcl8.3.so* -rw-r--r-- 1 root root 1832 Sep 17 14:03 libtclstub8.3.a -r-xr-xr-x 1 root root 778034 Sep 17 14:10 libtk8.3.so* -rw-r--r-- 1 root root 3302 Sep 17 14:10 libtkstub8.3.a drwxr-xr-x 8 root root 4096 Sep 17 14:03 tcl8.3/ -rw-r--r-- 1 root root 6722 Sep 17 14:03 tclConfig.sh drwxr-xr-x 4 root root 4096 Sep 17 14:10 tk8.3/ -rw-r--r-- 1 root root 3385 Sep 17 14:10 tkConfig.sh Does anybody know what my problem is? Is the error from libtk8.3.so complaining that it cannot load a library on which it depends? Is there some system library dependency that I am likely missing? Thanks, Trent -- Trent Mick TrentM(a)ActiveState.com

3 4

Missing API in re modle
by Guido van Rossum 20 Sep '00

20 Sep '00

When investigating and fixing Tim's report that the Replace dialog in IDLE was broken, I realized that there's an API missing from the re module. For search-and-replace, IDLE uses a regular expression to find the next match, and then needs to do whatever sub() does to that match. But there's no API to spell "whatever sub() does"! It's not safe to call sub() on just the matching substring -- the match might depend on context. It seems that a new API is needed. I propose to add the following method of match objects: match.expand(repl) Return the string obtained by doing backslash substitution as for the sub() method in the replacement string: expansion of \n -> linefeed etc., and expansion of numeric backreferences (\1, \2, ...) and named backreferences (\g<1>, \g<name>, etc.); backreferences refer to groups in the match object. Or am I missing something and is there already a way to do this? (Side note: the SRE code does some kind of compilation on the replacement template; I'd like to see this cached, as otherwise IDLE's replace-all button will take forever...) --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/)

1 0

Python 1.5.2 modules need porting to 2.0 because of unicode - comments please
by Martin v. Loewis 20 Sep '00

20 Sep '00

> I doubt that we can fix all Unicode related bugs in the 2.0 > stdlib before the final release... let's make this a project > for 2.1. Exactly my feelings. Since we cannot possibly fix all problems, we may need to change the behaviour later. If we now silently do the wrong thing, silently changing it to the then-right thing in 2.1 may break peoples code. So I'm asking that cases where it does not clearly do the right thing produces an exception now; we can later fix it to accept more cases, should need occur. In the specific case, dropping support for Unicode output in binary files is the right thing. We don't know what the user expects, so it is better to produce an exception than to silently put incorrect bytes into the stream - that is a bug that we still can fix. The easiest way with the clearest impact is to drop the buffer interface in unicode objects. Alternatively, not supporting them in for s# also appears reasonable. Users experiencing the problem in testing will then need to make an explicit decision how they want to encode the Unicode objects. If any expedition of the issue is necessary, I can submit a bug report, and propose a patch. Regards, Martin

3 2

fileno function in file objects
by Martin von Loewis 19 Sep '00

19 Sep '00

Section 2.1.7.9 of the library reference explains that file objects support a fileno method. Is that a mandatory operation on file-like objects (e.g. StringIO)? If so, how should it be implemented? If not, shouldn't the documentation declare it optional? The same question for documented attributes: closed, mode, name, softspace: need file-like objects to support them? Regards, Martin

4 3

sizehint in readlines
by Martin von Loewis 19 Sep '00

19 Sep '00

I've added support for the sizehint parameter in all places where it was missing and the documentation referred to the file objects section (socket, StringIO, cStringIO). The only remaining place with a readlines function without sizehint is in multifile.py. I'll observe that the documentation of this module is quite confused: it mentions a str parameter for readline and readlines. Should multifile.MultiFile.readlines also support the sizehint? (note that read() deliberately does not support a size argument). Regards, Martin

4 3

Deja-Search on python.org defunct
by M.-A. Lemburg 19 Sep '00

19 Sep '00

The search button on python.org doesn't search the c.l.p newsgroup anymore, but instead doea a search over all newsgroups. This link works: http://www.deja.com/[ST_rn=ps]/qs.xp?ST=PS&svcclass=dnyr&firstsearch=yes&QR… -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/

1 0

Python 1.5.2 modules need porting to 2.0 because of unicode - comments please
by Martin v. Loewis 19 Sep '00

19 Sep '00

> The smtplib problem may be easily explained -- AFAIK, the SMTP > protocol doesn't support Unicode, and the module isn't > Unicode-aware, so it is probably writing garbage to the socket. I've investigated this somewhat, and noticed the cause of the problem. The send method of the socket passes the raw memory representation of the Unicode object to send(2). On i386, this comes out as UTF-16LE. It appears that this behaviour is not documented anywhere (where is the original specification of the Unicode type, anyway). I believe this behaviour is a bug, on the grounds of being confusing. The same holds for writing a Unicode string to a file in binary mode. Again, it should not write out the internal representation. Or else, why doesn't file.write(42) work? I want that it writes the internal representation in binary :-) So in essence, I suggest that the Unicode object does not implement the buffer interface. If that has any undesirable consequences (which ones?), I suggest that 'binary write' operations (sockets, files) explicitly check for Unicode objects, and either reject them, or invoke the system encoding (i.e. ASCII). In the case of smtplib, this would do the right thing: the protocol requires ASCII commands, so if anybody passes a Unicode string with characters outside ASCII, you'd get an error. Regards, Martin

4 4

Python 1.5.2 modules need porting to 2.0 because of unicode - comments please
by Barry Scott 19 Sep '00

19 Sep '00

I have managed to get all our critical python code up and running under 2.0b1#4, around 15,000 lines. We use win32com and wxPython extensions. The code drive SourceSafe and includes a Web server that schedules builds for us. The only problem I encounted was the problem of mixing string and unicode types. Using the smtplib I was passing in a unicode type as the body of the message. The send() call hangs. I use encode() and all is well. Is this a user error in the use of smtplib or a bug? I found that I had a lot of unicode floating around from win32com that I was passing into wxPython. It checks for string and raises exceptions. More use of encode() and we are up and running. Is this what you expected when you added unicode? Barry

4 5

test_minidom now failing on Windows
by Tim Peters 19 Sep '00

19 Sep '00

http://sourceforge.net/bugs/?func=detailbug&bug_id=114775&group_id=5470 Add info (fails on Linux? Windows-specific?) or fix or something; assigned to Paul.

2 1

Speaking of bug triage...
by Greg Ward 19 Sep '00

19 Sep '00

... just what are the different categories supposed to mean? Specifically, what's the difference between "Library" and "Modules"? The library-related open bugs in the "Library" category cover the following modules: * anydbm * rfc822 (several!) * mimedecode * urlparse * cmath * CGIHTTPServer And in the "Modules" category we have: * mailbox * socket/os * re/sre (several) * anydbm * xml/_xmlplus * cgi/xml Hmmm... looks to me like there's no difference between "Library" and "Modules" -- heck, I could have guessed that just from looking at the names. The library *is* modules! Was this perhaps meant to be a distinction between pure Python and extension modules? Greg

4 4