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
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
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>
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
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