homepage

The following code prints out "I L" when run with python 2.5 and current SVN trunk (if you silence the DeprecationWarnings):
"""
import struct
for c in "bBhHiIlLqQdf":
 try:
 struct.pack(c, "foo bar")
 except struct.error:
 pass
 else:
 print c
"""
It works correctly (prints nothing) in Python 2.4.

Cannot confirm for trunk.

While the behavior cannot be reproduced in the trunk, in can be 
reproduced in the 2.6 release:
$ python -W ignore
Python 2.6.1 (r261:67515, Dec 6 2008, 16:42:21) 
[GCC 4.0.1 (Apple Computer, Inc. build 5370)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import struct
>>> struct.pack('L', 'foobar')
'\x00\x00\x00\x00'
>>> struct.pack('I', 'foobar')
'\x00\x00\x00\x00'
>>> struct.pack('i', 'foobar')
Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
struct.error: required argument is not an integer
>>>

It looks as though this was sort-of fixed sometime between 2.6.1 and 
2.6.2. In 2.6.2, I get the following (and results from trunk and 3.0.1 
are similar):
Python 2.6.2+ (release26-maint:71755, Apr 19 2009, 22:06:02) 
[GCC 4.0.1 (Apple Inc. build 5490)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import struct
>>> struct.pack('L', 'not an integer')
Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for &: 'str' and 'long'
That error message suggests that there's something nasty happening 
somewhere, though. It looks as though we're getting the right type of 
exception, but for the wrong reasons.

Mark, Virgil: Thanks for correcting my wrong assessment!
The lucky TypeError comes from rev 68120.
It looks like that error message in trunk is due to a "PyNumber_And(v,
pylong_ulong_mask)" when v isn't a PyNumber. I've added a "get_pylong(v)
== NULL" check in the attached patch, but my C is weak :)

Thanks for the patch, Daniel! It certainly fixes the problem. I was 
planning something a little more drastic, though---I think the struct 
module could do with a bit of a cleanup in this area.
At the moment it's not clear exactly what types should be accepted by
struct.pack with an integer format. Just ints and longs (and their 
subclases)? Anything implementing an __index__ method? Anything 
implementing an __int__ method (e.g., Decimal instances)?
I propose doing a little bit of rewriting so that
 (1) all attempted conversions of a PyObject to a C integer
 go through PyNumber_Index; thus anything with an __index__
 method can be packed.
 (2) If PY_STRUCT_FLOAT_COERCE is defined, instances of float or
 subclasses of float (i.e., everything that passes PyFloat_Check)
 are also accepted, for backwards compatibility.
Does this seem reasonable?

Here's a patch that does some general cleanup of the object->integer 
helper functions in the struct module; in the process, it fixes this 
bug. With this patch, all conversions from a PyObject to a C integer go 
through get_pylong, so they're all treated the same way. Currently 
(i.e., without the patch) there's a lack of consistency in the way the 
various integer codes are handled---some codes emit a warning for float 
conversions and some ('q', 'Q') don't; some codes will happily convert 
a Decimal instance, and others won't. Some codes produce this strange 
'unsupported operand types' message and some don't, etc.

Strange TypeError message fixed in r73858: those pack operations now raise 
struct.error, like they do for all other integer codes.