On Tue, Nov 28, 2000 at 02:13:47PM -0800, Guido van Rossum wrote:
>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...)
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
just stumbled upon yet another (high-profile) python newbie
confused a "TypeError: read-only character buffer, dictionary"
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"
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
Now you get an error message like:
TypeError: getsockaddrarg: AF_INET address must be tuple, not string
I have gathered a posie of other men's flowers, and nothing but the
thread that binds them is my own. -- Montaigne
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)
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
"All models are wrong; some models are useful."
-- George Box