[Python-3000] PEP 3137 plan of attack

[Gregory P. Smith]

On 10/15/07, Terry Reedy <tjreedy at udel.edu> wrote:
>
>
> "Guido van Rossum" <guido at python.org> wrote in message
> news:ca471dc20710150749y70ba12cfmadf1c59974c61926 at mail.gmail.com...
> | > > > 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20071015/b505de4e/attachment.htm