I get the following error trying to import _tkinter in a Python 2.0 build:
./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 \
-ltk8.3 -ltcl8.3 \
I got the Tcl/Tk 8.3 source from dev.scriptics.com, and ran
> ./configure --enable-gcc --enable-shared
> 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?
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
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
It seems that a new API is needed. I propose to add the following
method of match objects:
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/)
> 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
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.
Section 220.127.116.11 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?
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).
> 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.
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 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?
... 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
* rfc822 (several!)
And in the "Modules" category we have:
* re/sre (several)
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