On 10/15/07, Terry Reedy <[EMAIL PROTECTED]> wrote: > > > "Guido van Rossum" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > | > > > As I work on these.. Should the mutable PyBytes_ (buffer) objects > implement > | > > > the following methods inplace and return an additional reference > to > self? > | > > | > > > .capitalize(), .center(), .expandtabs(), .rjust(), .swapcase(), > .title(), > | > > > .upper(), .zfill() > | > > | > > No... That would be a huge trap to fall in at all sorts of > occasions. > > At this point, I though your objection was to returning the buffer instead > of None, as with list mutations, and for the same reason. But admittedly, > some people do not like this feature of lists. > > | > So would returning a different object. I expect a mutation operation > | > on an explicitly mutable object to mutate the object, instead of > | > creating something new. > > So was I. > > | Since these methods with these very names already exist for strings > | and return new values there, I don't see the gotcha unless you never > | use strings. > > The real question is what is more useful? I would think that being able > to > edit in place would be a reason to use a buffer rather than (immutable) > bytes. > > tjr
I agree, thats a benefit of a mutable object. But I think the point about not reusing the names with a different behavior is valid so that some code can be written to operate on objects with duck type without having to know if its mutable or not. -gps
_______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
