Mailman 3 December 2000 - Python-Dev

Another Python Developer Missing
by Moshe Zadka Dec. 3, 2000

Dec. 3, 2000

Gordon McMillan is not a possible assignee in the assign_to field. -- Moshe Zadka <moshez(a)zadka.site.co.il> -- 95855124 http://moshez.org

2 1

Re: [Python-checkins] CVS: python/nondist/peps pep-0000.txt,1.50,1.51 pep-0207.txt,1.3,1.4
by Andrew Kuchling Dec. 1, 2000

Dec. 1, 2000

On Tue, Nov 28, 2000 at 02:13:47PM -0800, Guido van Rossum wrote: >229 >is not sufficiently worked out and doesn't seem a priority. (This can >still make it into 2.1 if the author does the work.) I was waiting for further comments on the idea before actually doing the work. Anyone see gaping holes in the basic idea? (I *can* just charge ahead and work on it anyway...) --amk

5 6

[OT] Change of Address
by Moshe Zadka Dec. 1, 2000

Dec. 1, 2000

I'm sorry to bother you all with this, but from time to time you might need to reach my by e-mail... 30 days from now, this e-mail address will no longer be valid. Please use anything(a)zadka.site.co.il to reach me. Thank you for your time. -- Moshe Zadka <moshez(a)zadka.site.co.il> -- 95855124 http://advogato.org/person/moshez

1 0

TypeError: foo, bar
by Fredrik Lundh Dec. 1, 2000

Dec. 1, 2000

just stumbled upon yet another (high-profile) python newbie confused a "TypeError: read-only character buffer, dictionary" message. how about changing "read-only character buffer" to "string or read-only character buffer", and the "foo, bar" format to "expected foo, found bar", so we get: "TypeError: expected string or read-only character buffer, found dictionary" </F>

4 3

Re: [Python-Dev] Cryptic error messages
by Michael Hudson Dec. 1, 2000

Dec. 1, 2000

Ka-Ping Yee <ping(a)lfw.org> writes: > An attempt to use sockets for the first time yesterday left a > friend of mine bewildered: > > >>> import socket > >>> s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) > >>> s.connect('localhost:234') > Traceback (most recent call last): > File "<stdin>", line 1, in ? > TypeError: 2-sequence, 13-sequence > >>> > > "What the heck does '2-sequence, 13-sequence' mean?" he rightfully asked. > I'm not sure about the general case, but in this case you could do something like: http://sourceforge.net/patch/?func=detailpatch&patch_id=102599&group_id=5470 Now you get an error message like: TypeError: getsockaddrarg: AF_INET address must be tuple, not string Cheers, M. -- I have gathered a posie of other men's flowers, and nothing but the thread that binds them is my own. -- Montaigne

1 0

Cryptic error messages
by Ka-Ping Yee Dec. 1, 2000

Dec. 1, 2000

An attempt to use sockets for the first time yesterday left a friend of mine bewildered: >>> import socket >>> s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) >>> s.connect('localhost:234') Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: 2-sequence, 13-sequence >>> "What the heck does '2-sequence, 13-sequence' mean?" he rightfully asked. I see in getargs.c (line 275) that this type of message is documented: /* Convert a tuple argument. [...] If the argument is invalid: [...] *msgbuf contains an error message, whose format is: "<typename1>, <typename2>", where: <typename1> is the name of the expected type, and <typename2> is the name of the actual type, (so you can surround it by "expected ... found"), and msgbuf is returned. */ It's clear that the socketmodule is not prepending "expected" and appending "found", as the author of converttuple intended. But when i grepped through the source code, i couldn't find anyone applying this "expected %s found" % msgbuf convention outside of getargs.c. Is it really in use? Could we just change getargs.c so that converttuple() returns a message like "expected ..., got ..." instead of seterror()? Additionally it would be nice to say '13-character string' instead of '13-sequence'... -- ?!ng "All models are wrong; some models are useful." -- George Box

1 0