Casey Duncan wrote:
I think this is an important feature, which allows you to define
generic, reusable getter and setter functions and pass static metadata
to them at runtime. Admittedly I have never needed the full pointer,
my typical usage is to pass in an offset.
I think this should only
On May 4, 2009, at 3:10 AM, Larry Hastings wrote:
I should have brought this up to python-dev before--sorry for being
so slow. It's already in the tracker for a couple of days:
http://bugs.python.org/issue5880
The idea: PyGetSetDef has this "void *closure" field that acts like
a conte
Mark Dickinson wrote:
This doesn't sound right. The functions in the third party code will get
compiled with the wrong signature, so they can crash (or behave unexpectedly)
when called by Python.
Yes, of course the signature of the getters and setters changes. Please
ignore me. :-)
If t
Mark Dickinson wrote:
I *think* that third party code that's recompiled for 3.1 and that
doesn't use the closure field will either just work, or will produce an
easily-fixed compile error. Larry, does this sound right?
Yep.
But I guess the bigger issue is that extensions already compiled
On Mon, May 4, 2009 at 9:15 PM, Antoine Pitrou wrote:
> Mark Dickinson gmail.com> writes:
>>
>> I *think* that third party code that's recompiled for 3.1 and that
>> doesn't use the closure field will either just work, or will produce an
>> easily-fixed compile error. Larry, does this sound righ
Mark Dickinson gmail.com> writes:
>
> I *think* that third party code that's recompiled for 3.1 and that
> doesn't use the closure field will either just work, or will produce an
> easily-fixed compile error. Larry, does this sound right?
This doesn't sound right. The functions in the third par
On Mon, May 4, 2009 at 3:00 PM, Mark Dickinson wrote:
> But I guess the bigger issue is that extensions already compiled against
> 3.0
> that use PyGetSetDef (even if they don't make use of the closure field)
> won't work with 3.1 without a recompile: they'll segfault, or otherwise
> behave
> un
On Mon, May 4, 2009 at 8:11 PM, Daniel Stutzbach
wrote:
> If you make the change, will 3rd party code that relies on it fail in
> unexpected ways, or will they just get a compile error?
I *think* that third party code that's recompiled for 3.1 and that
doesn't use the closure field will either ju
On Mon, May 4, 2009 at 4:10 AM, Larry Hastings wrote:
> So: you don't need it, it clutters up our code (particularly typeobject.c),
> and it adds overhead. The only good reason to keep it is backwards
> compatibility, which I admit is a fine reason.
>
If you make the change, will 3rd party code
Amaury Forgeot d'Arc wrote:
Larry Hastings wrote:
My understanding is that there a) 2.x extension modules are not binary
compatible with 3.x, and b) there are essentially no 3.x extension modules
in the field. Is that accurate? If we don't have an installed base (yet)
to worry about, now's
Hi,
Larry Hastings wrote:
>
> Mark Dickinson wrote:
>>
>> Still, binary compatibility seems like a fairly strong reason not to
>> remove the closure field.
>
> My understanding is that there a) 2.x extension modules are not binary
> compatible with 3.x, and b) there are essentially no 3.x extensio
Mark Dickinson wrote:
Still, binary compatibility seems like a fairly strong reason not to
remove the closure field.
My understanding is that there a) 2.x extension modules are not binary
compatible with 3.x, and b) there are essentially no 3.x extension
modules in the field. Is that accura
On Mon, May 4, 2009 at 10:10 AM, Larry Hastings wrote:
> So: you don't need it, it clutters up our code (particularly typeobject.c),
> and it adds overhead. The only good reason to keep it is backwards
> compatibility, which I admit is a fine reason.
Presumably whoever added the context field h
I should have brought this up to python-dev before--sorry for being so
slow. It's already in the tracker for a couple of days:
http://bugs.python.org/issue5880
The idea: PyGetSetDef has this "void *closure" field that acts like a
context pointer. You stick it in the PyGetSetDef, and it
14 matches
Mail list logo
