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.