I thought Neal started this idea?

-Brett
 
">

(original) (raw)



On Tue, Mar 31, 2009 at 20:34, Guido van Rossum <guido@python.org> wrote:

Can you get Jim Fulton's feedback? ISTR he originated this.


I thought Neal started this idea?

-Brett

On Tue, Mar 31, 2009 at 12:14 PM, Larry Hastings <larry@hastings.org> wrote:
>
> The CObject API has two flaws.
>
> First, there is no usable type safety mechanism. You can store a void
> \*object, and a void \*description. There is no established schema for
> the description; it could be an integer cast to a pointer, or it could
> point to memory of any configuration, or it could be NULL. Thus users
> of the CObject API generally ignore it--thus working without any type
> safety whatsoever. A programmer could crash the interpreter from pure
> Python by mixing and matching CObjects from different modules (e.g. give
> "curses" a CObject from "\_ctypes").
>
> Second, the destructor callback is defined as taking \*either\* one \*or\*
> two parameters, depending on whether the "descr" pointer is non-NULL. One
> can debate the finer points of what is and isn't defined behavior in
> C, but at its heart this is a sloppy API.
>
> MvL and I discussed this last night and decided to float a revision of
> the API. I wrote the patch, though, so don't blame Martin if you don't
> like my specific approach.
>
> The color of this particular bike shed is:
> \* The PyCObject is now a private data structure; you must use accessors.
> I added accessors for all the members.
> \* The constructors and the main accessor (PyCObject\_AsVoidPtr) now all
> \*require\* a "const char \*type" parameter, which must be a non-NULL C
> string of non-zero length. If you call that accessor and the "type"
> is invalid \*or doesn't match\*, it fails.
> \* The destructor now takes the PyObject \*, not the PyCObject \*. You
> must use accessors to get your hands on the data inside to free it.
>
> Yes, you can easily skip around the "matching type" restriction by
> calling PyCObject\_AsVoidPtr(cobj, PyCObject\_GetType(cobj)). The point
> of my API changes is to \*encourage\* correct use.
>
> I've posted a patch implementing this change in the 3.1 trunk to the
> bug tracker:
>
> http://bugs.python.org/issue5630
>
> I look forward to your comments!
>
>
> /larry/
>
> \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/guido%40python.org
>



\--
\--Guido van Rossum (home page: http://www.python.org/\~guido/)
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/brett%40python.org