Re: [Python-Dev] Let's update CObject API so it is safe and regular!

dev-bounces+kristjan=ccpgames@python.org] On Behalf Of Guido van Rossum Sent: 2. apríl 2009 17:19 To: Jim Fulton Cc: Python-Dev@python.org Subject: Re: [Python-Dev] Let's update CObject API so it is safe and regular! On Thu, Apr 2, 2009 at 6:22 AM, Jim Fulton wrote: > The original use

Re: [Python-Dev] Let's update CObject API so it is safe and regular!

Larry Hastings wrote: If we're adding type information, then please make it a Python object rather than a C string. That way the creator and the consumer can use a richer API to query the "type", such as by calling its methods or by inspecting it in some other way. I'm not writing my patch t

Re: [Python-Dev] Let's update CObject API so it is safe and regular!

Jim Fulton wrote: The original use case for CObjects was to export an API from a module, in which case, you'd be importing the API from the module. The presence in the module indicates the type. Sure, but it can't hurt to have an additional sanity check. Also, there are wider uses for CObje

Re: [Python-Dev] Let's update CObject API so it is safe and regular!

Hrvoje Niksic wrote: I thought the entire *point* of C object was that it's an opaque box without any info whatsoever, except that which is known and shared by its creator and its consumer. But there's no way of telling who created a given CObject, so *nobody* knows anything about it for cert

Re: [Python-Dev] Let's update CObject API so it is safe and regular!

Guido van Rossum wrote: OK, my proposal would be to agree on the value of this string too: "module.variable". That's a fine idea for cases where the CObject is stored as an attribute of a module; my next update of my patch will change the existing uses to use that format. Why would you

Re: [Python-Dev] Let's update CObject API so it is safe and regular!

Hrvoje Niksic wrote: If we're adding type information, then please make it a Python object rather than a C string. That way the creator and the consumer can use a richer API to query the "type", such as by calling its methods or by inspecting it in some other way. I'm not writing my patch t

Re: [Python-Dev] Let's update CObject API so it is safe and regular!

Guido van Rossum wrote: On Thu, Apr 2, 2009 at 6:22 AM, Jim Fulton wrote: The original use case for CObjects was to export an API from a module, in which case, you'd be importing the API from the module. I consider this the *only* use case. What other use cases are there? Exporting a

Re: [Python-Dev] Let's update CObject API so it is safe and regular!

On Thu, Apr 2, 2009 at 10:24 AM, Antoine Pitrou wrote: > Guido van Rossum python.org> writes: >> >> On Thu, Apr 2, 2009 at 6:22 AM, Jim Fulton zope.com> wrote: >> > The original use case for CObjects was to export an API from a module, in >> > which case, you'd be importing the API from the modu

Re: [Python-Dev] Let's update CObject API so it is safe and regular!

Guido van Rossum python.org> writes: > > On Thu, Apr 2, 2009 at 6:22 AM, Jim Fulton zope.com> wrote: > > The original use case for CObjects was to export an API from a module, in > > which case, you'd be importing the API from the module. > > I consider this the *only* use case. What other use

Re: [Python-Dev] Let's update CObject API so it is safe and regular!

On Thu, Apr 2, 2009 at 6:22 AM, Jim Fulton wrote: > The original use case for CObjects was to export an API from a module, in > which case, you'd be importing the API from the module. I consider this the *only* use case. What other use cases are there? > The presence in the > module indicates th

Re: [Python-Dev] Let's update CObject API so it is safe and regular!

On Apr 2, 2009, at 7:28 AM, Greg Ewing wrote: Jim Fulton wrote: The only type-safety mechanism for a CObject is it's identity. If you want to make sure you're using the foomodule api, make sure the address of the CObject is the same as the address of the api object exported by the mo

Re: [Python-Dev] Let's update CObject API so it is safe and regular!

On Apr 1, 2009, at 11:51 PM, Guido van Rossum wrote: ... Note also this cheap exported-vtable hack isn't the only use of CObjects; for example _ctypes uses them to wrap plenty of one-off objects which are never set as attributes of the _ctypes module. We'd like a solution that enforces some s

Re: [Python-Dev] Let's update CObject API so it is safe and regular!

Greg Ewing wrote: Attaching some kind of type info to a CObject and having an easy way of checking it makes sense to me. If the existing CObject API can't be changed, maybe a new enhanced one could be added. I thought the entire *point* of C object was that it's an opaque box without any info

Re: [Python-Dev] Let's update CObject API so it is safe and regular!

Jim Fulton wrote: The only type-safety mechanism for a CObject is it's identity. If you want to make sure you're using the foomodule api, make sure the address of the CObject is the same as the address of the api object exported by the module. I don't follow that. If you already have the

Re: [Python-Dev] Let's update CObject API so it is safe and regular!

Thanks Larry. I didn't notice the patch, or indeed the defect, hence my question. A clarification in the documentation that a string comparison is indeed used might be useful. As a user of CObject I appreciate this effort. K -Original Message- From: Larry Hastings [mailto:la...@hastings.o

Re: [Python-Dev] Let's update CObject API so it is safe and regular!

On Wed, Apr 1, 2009 at 7:58 PM, Larry Hastings wrote: > Guido van Rossum wrote: >> Yeah, any two CAPI objects can be used to play this trick, as long as >> you have some place that calls them. :-( > > FWIW, I can't take credit for this observation.  Neal Norwitz threw me at > this class of problem

Re: [Python-Dev] Let's update CObject API so it is safe and regular!

On Wed, Apr 1, 2009 at 11:58 PM, Larry Hastings wrote: > > Guido van Rossum wrote: >> >> Yeah, any two CAPI objects can be used to play this trick, as long as >> you have some place that calls them. :-( > > FWIW, I can't take credit for this observation.  Neal Norwitz threw me at > this class of p

Re: [Python-Dev] Let's update CObject API so it is safe and regular!

Guido van Rossum wrote: Yeah, any two CAPI objects can be used to play this trick, as long as you have some place that calls them. :-( FWIW, I can't take credit for this observation. Neal Norwitz threw me at this class of problem at the Py3k sprints in August 2007 at Google Mountain View, s

Re: [Python-Dev] Let's update CObject API so it is safe and regular!

On Wed, Apr 1, 2009 at 5:39 PM, Larry Hastings wrote: > > Guido van Rossum wrote: > > This is a bug in cPickle. It calls the PycString_IMPORT macro at the > very end of its init_stuff() function without checking for success. > > > The bug you cite is a genuine bug, but that's not what I'm exploiti

Re: [Python-Dev] Let's update CObject API so it is safe and regular!

Guido van Rossum wrote: This is a bug in cPickle. It calls the PycString_IMPORT macro at the very end of its init_stuff() function without checking for success. The bug you cite is a genuine bug, but that's not what I'm exploiting. % python >>> import _socket >>> _socket.CAPI The PyCObje

Re: [Python-Dev] Let's update CObject API so it is safe and regular!

2009/4/1 Larry Hastings : > > Jim Fulton wrote: > > The only type-safety mechanism for a CObject is it's identity.  If you want > to make sure you're using the foomodule api, make sure the address of the > CObject is the same as the address of the api object exported by the module. > > That doesn't

Re: [Python-Dev] Let's update CObject API so it is safe and regular!

Jim Fulton wrote: The only type-safety mechanism for a CObject is it's identity. If you want to make sure you're using the foomodule api, make sure the address of the CObject is the same as the address of the api object exported by the module. That doesn't help. Here's a program that crashes

Re: [Python-Dev] Let's update CObject API so it is safe and regular!

On Mar 31, 2009, at 3:14 PM, Larry Hastings wrote: (Thanks for calling my attention to this. :) 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 coul

Re: [Python-Dev] Let's update CObject API so it is safe and regular!

Kristján Valur Jónsson wrote: What are the semantics of the "type" argument for PyCObject_FromVoidPtr()? From the patch, from the documentation comment above the prototype for PyCObject_FromVoidPtr() in Include/cobject.h: The "type" string must point to a legal C string of non-zero len

Re: [Python-Dev] Let's update CObject API so it is safe and regular!

Brett Cannon wrote: On Tue, Mar 31, 2009 at 20:34, Guido van Rossum > wrote: Can you get Jim Fulton's feedback? ISTR he originated this. I thought Neal started this idea? The earliest revision spotted in "svn blame cobject.[ch]" is 5782: svn log -r 5782 -

Re: [Python-Dev] Let's update CObject API so it is safe and regular!

python-dev-bounces+kristjan=ccpgames@python.org [mailto:python-dev-bounces+kristjan=ccpgames@python.org] On Behalf Of Larry Hastings Sent: 31. mars 2009 19:15 To: Python-Dev@python.org Subject: [Python-Dev] Let's update CObject API so it is safe and regular! * The constructors and th

Re: [Python-Dev] Let's update CObject API so it is safe and regular!

On Tue, Mar 31, 2009 at 20:34, Guido van Rossum 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 > wrote: > > > > The CObject API has two flaws. > > > > First, there is no usab

Re: [Python-Dev] Let's update CObject API so it is safe and regular!

Can you get Jim Fulton's feedback? ISTR he originated this. On Tue, Mar 31, 2009 at 12:14 PM, Larry Hastings 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

[Python-Dev] Let's update CObject API so it is safe and regular!

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