The type of a buffer slice is either 'buffer' 
or 'str', depending on the slice parameters.
If the slice encompasses the entire buffer, the buffer 
itself is returned.
Otherwise, a string is returned.
Here is a sample session:
--------------------------
Python 2.2.1 (#34, Apr  9 2002, 19:34:33) [MSC 32 bit 
(Intel)] on win32
Type "copyright", "credits" or "license" for more 
information.
IDLE 0.8 -- press F1 for help
>>> a="0123456789"
>>> b = buffer(a, 1, 8)
>>> b
<read-only buffer for 0x0079B4B0, ptr 0x0079B4C5, size 
8 at 0x00A99F30>
>>> b[:]
<read-only buffer for 0x0079B4B0, ptr 0x0079B4C5, size 
8 at 0x00A99F30>
>>> b[:8]
<read-only buffer for 0x0079B4B0, ptr 0x0079B4C5, size 
8 at 0x00A99F30>
>>> b[2:4]
'34'
>>> b[5]
'6'
>>> c = buffer(a, 4, 1)
>>> c
<read-only buffer for 0x0079B4B0, ptr 0x0079B4C8, size 
1 at 0x00AAA370>
>>> c[0]
'4'
>>> c[0:1]
<read-only buffer for 0x0079B4B0, ptr 0x0079B4C8, size 
1 at 0x00AAA370>
--------------------------
Either b[:] should produce a string, or, more 
preferably, b[x:y] should be equivalent to buffer(b, 
x, y), and c[0] should be equivalent to buffer(c, 0, 
1).
The reason that the types should be similar is because 
if a buffer is passed to a function that's checking 
for strings, the function should always fail or always 
succeed.

This is especially important because types.BufferType 
isn't in the types.StringTypes list, so the 
expression "type(b) in types.StringTypes" will also 
behave inconsistantly.

Logged In: YES 
user_id=111611

Sorry about the formatting; the form wrapped the lines.
A slight correction:
  "b[x:y] should be equivalent to buffer(b, x, y)"
should be
"b[x:y] should be equivalent to buffer(b, x1, y1 - x1), 
where x1 == x if x is positive and len(b) + x if x is 
negative, and similarly for y and y1".

Logged In: YES 
user_id=80475

Added Py2.3 patch to make slicing and repetition always 
return a string.  Unsure if it is a 2.2 backport candidate.

Logged In: YES 
user_id=6380

Hm, shoudldn't slicing a buffer always return a buffer
object? That's what the OP requested and seems to be the
most consistent. (On the other hand getting a single item
with b[i] should return a character.)

I think that repetition on a buffer object should be an error.

This would be a semantic change that can't be backported to 2.2.

Logged In: YES 
user_id=80475

I can make a fix as you specified by nullifying the 
sq_repeat slot and having the slice routines always return 
a new buffer object.

Still, I'm not sure that that is right thing to do.  All other 
sequence behaviors are defined, so it seems weird to zap 
repetition (though I can't see a use case for it).

Also, I original opted to return strings instead of buffers for 
several reasons.  My reading of the OP was that either way 
was fine as long as it was consistent.  Also, I think it is 
more likely that existing code relies on returning a string 
instead of a buffer (impossible to verify though; I rarely 
see buffer used) as in: print mybuf[2:8].  Buffer appears to 
be designed to be as stringlike as possible so that it can 
be easily substituted in code originally designed for strings.

If you still think returning a buffer is the way to go, I'm 
happy to do it.  One other thought, currently mybuf[:] 
returns self but I think it should return a copy of self to be 
consistent with the idiom:  
   b = a[:]
   assert id(a) != id(b)

Do you want someone else to review this while your out or 
for me to just take care of it?

Logged In: YES 
user_id=6380

I think it's best to ask python-dev's opinion on this,
especially as I'm on vacation. :-)

Logged In: YES 
user_id=80475

I posted twice and got one reply from someone who has a 
deep interest in buffers.  We agreed that returning a string 
was the most useful behavior and that repetition should 
be left intact.  If anyone disagrees later, I will be happy to 
code some other behavior.

Committing the patch for Py2.3 only:  bufferobject.c 
1.434 and NEWS 2.19.  Closing the bug.