[Python-3000] patch: bytes object PyBUF_LOCKDATA read-only and immutable support

[Guido van Rossum]

I'd like to see Travis's response to this. It's setting a precedent
regarding locking objects in read-only mode; I haven't found other
examples of objects using LOCKDATA (the only mentions of it seem to be
rejecting it :). I keep getting confused by the two separate lock
counts (and I think in this version the comment is inconsistent with
the code). So I'm hoping Travis has a particular way in mind of
handling LOCKDATA that can be used as a template.

Travis?

--Guido

On 9/8/07, Gregory P. Smith <greg at krypto.org> wrote:
> A new version is attached; cleaned up and simplified based on your original
> comments.
>
> On 8/29/07, Guido van Rossum < guido at python.org> wrote:
> > That's a huge patch to land so close before a release. I'm not sure I
> > like the immutability API -- it won't be useful unless we add a hash
> > method, and then we have all sorts of difficulties again -- the
> > distinction between a hashable and an unhashable object should be made
> > by type, not by value (tuples containing unhashable values
> > notwithstanding).
>
> ok i've removed the immutable support in the most recent patch.  i still
> think it -might- be useful but isn't required and you're right that it could
> open a can of worms if people think it should also mean hashable.  immutable
> bytes may be best implemented as a subclass if its ever wanted.
>
> > I don't understand the comment about using PyBUF_WRITABLE in
> > _getbuffer() -- this is only used for data we're *reading* and I don't
> > think the GIL is even released while we're reading such things.
>
> that appears to be correct.  the comment was wrong.  fixed.
>
> -gps
>
>
> > If you think it's important to get this in the 3.0a1 release, we
> > should pair-program on it ASAP, preferable tomorrow morning.
> > Otherwise, let's do a review next week.
> >
> > --Guido
> >
> > On 8/29/07, Gregory P. Smith < greg at krypto.org> wrote:
> > > Attached is what I've come up with so far.  Only a single field is
> > > added to the PyBytesObject struct.  This adds support to the bytes
> > > object for PyBUF_LOCKDATA buffer API operation.  bytes objects can be
> > > marked temporarily read-only for use while the buffer api has handed
> > > them off to something which may run without the GIL (think IO).  Any
> > > attempt to modify them during that time will raise an exception as I
> > > believe Martin suggested earlier.
> > >
> > > As an added bonus because its been discussed here, support for setting
> > > a bytes object immutable has been added since its pretty trivial once
> > > the read only export support was in place.  Thats not required but was
> > > trivial to include.
> > >
> > > I'd appreciate any feedback.
> > >
> > > My TODO list for this patch:
> > >
> > >  0. Get feedback and make adjustments as necessary.
> > >
> > >  1. Deciding between PyBUF_SIMPLE and PyBUF_WRITEABLE for the internal
> > >     uses of the _getbuffer() function.  bytesobject.c contains both
> readonly
> > >     and read-write uses of the buffers, i'll add boolean parameter for
> > >     that.
> > >
> > >  2. More testing: a few tests in the test suite fail after this but the
> > >     number was low and I haven't had time to look at why or what the
> > >     failures were.
> > >
> > >  3. Exporting methods suggested in the TODO at the top of the file.
> > >
> > >  4. Unit tests for all of the functionality this adds.
> > >
> > > NOTE: after these changes I had to make clean and rm -rf build before
> > > things would not segfault on import.  I suspect some things (modules?)
> > > were not properly recompiled after the bytesobject.h struct change
> > > otherwise.
> > >
> > > -gps
> > >
> > >
> > > _______________________________________________
> > > Python-3000 mailing list
> > > Python-3000 at python.org
> > > http://mail.python.org/mailman/listinfo/python-3000
> > > Unsubscribe:
> http://mail.python.org/mailman/options/python-3000/guido%40python.org
> > >
> > >
> > >
> >
> >
> > --
> > --Guido van Rossum (home page: http://www.python.org/~guido/)
> >
>
>
>


-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)