This comes from a refactor of the work on CEP 1000: A PEP proposal, with a hack for use in current Python versions and in the case of PEP rejection, that allows 3rd party libraries to agree on extensions to PyTypeObject. http://wiki.cython.org/enhancements/cep1001 If this makes it as a PEP, I don't think we need to think about having CEP 1000 accepted as a PEP. Comments? Dag
On Fri, May 11, 2012 at 2:25 PM, Dag Sverre Seljebotn <d.s.seljebotn@...> wrote: > This comes from a refactor of the work on CEP 1000: A PEP proposal, with a > hack for use in current Python versions and in the case of PEP rejection, > that allows 3rd party libraries to agree on extensions to PyTypeObject. > > http://wiki.cython.org/enhancements/cep1001 > > If this makes it as a PEP, I don't think we need to think about having CEP > 1000 accepted as a PEP. > > Comments? There should probably be some discussion of memory management for the tpe_data pointers. (I assume it's "guaranteed to be valid for as long as the associated PyTypeObject, and the PyTypeObject is responsible for making sure any necessary cleanup happens if it gets deallocated", but a note to this effect would be good.) What happens if I want to inherit from PyTypeObject (a "metaclass") and also implement this interface? It is possible? What if I want to inherit from an existing subclass of PyTypeObject and add on this interface? I don't know enough gnarly details about how new style classes are implemented to tell. Would it make sense to make this memory-layout-equivalent to a PyTypeObject subclass with extra fields? -- Nathaniel
On 05/12/2012 08:44 PM, Nathaniel Smith wrote: > On Fri, May 11, 2012 at 2:25 PM, Dag Sverre Seljebotn > <d.s.seljebotn@...> wrote: >> This comes from a refactor of the work on CEP 1000: A PEP proposal, with a >> hack for use in current Python versions and in the case of PEP rejection, >> that allows 3rd party libraries to agree on extensions to PyTypeObject. >> >> http://wiki.cython.org/enhancements/cep1001 >> >> If this makes it as a PEP, I don't think we need to think about having CEP >> 1000 accepted as a PEP. >> >> Comments? > > There should probably be some discussion of memory management for the > tpe_data pointers. (I assume it's "guaranteed to be valid for as long > as the associated PyTypeObject, and the PyTypeObject is responsible > for making sure any necessary cleanup happens if it gets deallocated", > but a note to this effect would be good.) > > What happens if I want to inherit from PyTypeObject (a "metaclass") > and also implement this interface? It is possible? What if I want to > inherit from an existing subclass of PyTypeObject and add on this > interface? I don't know enough gnarly details about how new style > classes are implemented to tell. Would it make sense to make this > memory-layout-equivalent to a PyTypeObject subclass with extra fields? Hmm. You know what -- this whole thing could probably be a metaclass. Except I think a PyObject_TypeCheck on the type would be a bit more expensive than just checking a flag. I think I like having a flag better...(Continue reading)
On 05/13/2012 09:35 PM, Dag Sverre Seljebotn wrote: > On 05/12/2012 08:44 PM, Nathaniel Smith wrote: >> On Fri, May 11, 2012 at 2:25 PM, Dag Sverre Seljebotn >> <d.s.seljebotn@...> wrote: >>> This comes from a refactor of the work on CEP 1000: A PEP proposal, >>> with a >>> hack for use in current Python versions and in the case of PEP >>> rejection, >>> that allows 3rd party libraries to agree on extensions to PyTypeObject. >>> >>> http://wiki.cython.org/enhancements/cep1001 >>> >>> If this makes it as a PEP, I don't think we need to think about >>> having CEP >>> 1000 accepted as a PEP. >>> >>> Comments? >> >> There should probably be some discussion of memory management for the >> tpe_data pointers. (I assume it's "guaranteed to be valid for as long >> as the associated PyTypeObject, and the PyTypeObject is responsible >> for making sure any necessary cleanup happens if it gets deallocated", >> but a note to this effect would be good.) >> >> What happens if I want to inherit from PyTypeObject (a "metaclass") >> and also implement this interface? It is possible? What if I want to >> inherit from an existing subclass of PyTypeObject and add on this >> interface? I don't know enough gnarly details about how new style >> classes are implemented to tell. Would it make sense to make this >> memory-layout-equivalent to a PyTypeObject subclass with extra fields?(Continue reading)
Dag Sverre Seljebotn, 13.05.2012 21:37: > Anyway, thanks for the heads up, this seems to need a bit more work. Input > from somebody more familiar with this corner of the CPython API very welcome. Wouldn't you consider python-dev an appropriate place to discuss this? Stefan
On 05/14/2012 01:34 PM, Stefan Behnel wrote: > Dag Sverre Seljebotn, 13.05.2012 21:37: >> Anyway, thanks for the heads up, this seems to need a bit more work. Input >> from somebody more familiar with this corner of the CPython API very welcome. > > Wouldn't you consider python-dev an appropriate place to discuss this? Propose something for a PEP that's primarily useful to Cython without even understanding the full implications myself first? I'd rather try to not annoy people; I figured the time I have the CPython patches ready and tested is the time I ping python-dev... Dag
On Mon, May 14, 2012 at 3:23 PM, Dag Sverre Seljebotn <d.s.seljebotn@...> wrote: > On 05/14/2012 01:34 PM, Stefan Behnel wrote: >> >> Dag Sverre Seljebotn, 13.05.2012 21:37: >>> >>> Anyway, thanks for the heads up, this seems to need a bit more work. >>> Input >>> from somebody more familiar with this corner of the CPython API very >>> welcome. >> >> >> Wouldn't you consider python-dev an appropriate place to discuss this? > > > Propose something for a PEP that's primarily useful to Cython without even > understanding the full implications myself first? > > I'd rather try to not annoy people; I figured the time I have the CPython > patches ready and tested is the time I ping python-dev... If you want to eventually propose a PEP, you really really really should be talking to them before. Otherwise you'll get everything worked out just the way you want and they'll be like "what is this? re-do it all totally differently". And they might be wrong, but then you have to reconstruct for them the whole debate and reasoning process and implicit assumptions that you're making and not realizing you need to articulate, so easier to just get all the interested people at the table to begin with. And they might be right, in which case you just wasted however much time digging yourself into a hole(Continue reading)
Nathaniel Smith, 14.05.2012 19:05: > On Mon, May 14, 2012 at 3:23 PM, Dag Sverre Seljebotn wrote: >> On 05/14/2012 01:34 PM, Stefan Behnel wrote: >>> Dag Sverre Seljebotn, 13.05.2012 21:37: >>>> Anyway, thanks for the heads up, this seems to need a bit more work. >>>> Input >>>> from somebody more familiar with this corner of the CPython API very >>>> welcome. >>> >>> Wouldn't you consider python-dev an appropriate place to discuss this? >> >> Propose something for a PEP that's primarily useful to Cython without even >> understanding the full implications myself first? >> >> I'd rather try to not annoy people; I figured the time I have the CPython >> patches ready and tested is the time I ping python-dev... > > If you want to eventually propose a PEP, you really really really > should be talking to them before. Otherwise you'll get everything > worked out just the way you want and they'll be like "what is this? > re-do it all totally differently". And they might be wrong, but then > you have to reconstruct for them the whole debate and reasoning > process and implicit assumptions that you're making and not realizing > you need to articulate, so easier to just get all the interested > people at the table to begin with. And they might be right, in which > case you just wasted however much time digging yourself into a hole > and reverse-engineering bits of CPython. > > Don't propose it as a PEP, just say "hey, we have this problem and > these constraints, and we're thinking we could solve them by something(Continue reading)
On Mon, May 14, 2012 at 10:05 AM, Nathaniel Smith <njs@...> wrote: > On Mon, May 14, 2012 at 3:23 PM, Dag Sverre Seljebotn > <d.s.seljebotn@...> wrote: >> On 05/14/2012 01:34 PM, Stefan Behnel wrote: >>> >>> Dag Sverre Seljebotn, 13.05.2012 21:37: >>>> >>>> Anyway, thanks for the heads up, this seems to need a bit more work. >>>> Input >>>> from somebody more familiar with this corner of the CPython API very >>>> welcome. >>> >>> >>> Wouldn't you consider python-dev an appropriate place to discuss this? >> >> >> Propose something for a PEP that's primarily useful to Cython without even >> understanding the full implications myself first? >> >> I'd rather try to not annoy people; I figured the time I have the CPython >> patches ready and tested is the time I ping python-dev... > > If you want to eventually propose a PEP, you really really really > should be talking to them before. Otherwise you'll get everything > worked out just the way you want and they'll be like "what is this? > re-do it all totally differently". And they might be wrong, but then > you have to reconstruct for them the whole debate and reasoning > process and implicit assumptions that you're making and not realizing > you need to articulate, so easier to just get all the interested > people at the table to begin with. And they might be right, in which(Continue reading)
On 05/14/2012 08:01 PM, Robert Bradshaw wrote: > On Mon, May 14, 2012 at 10:05 AM, Nathaniel Smith<njs@...> wrote: >> On Mon, May 14, 2012 at 3:23 PM, Dag Sverre Seljebotn >> <d.s.seljebotn@...> wrote: >>> On 05/14/2012 01:34 PM, Stefan Behnel wrote: >>>> >>>> Dag Sverre Seljebotn, 13.05.2012 21:37: >>>>> >>>>> Anyway, thanks for the heads up, this seems to need a bit more work. >>>>> Input >>>>> from somebody more familiar with this corner of the CPython API very >>>>> welcome. >>>> >>>> >>>> Wouldn't you consider python-dev an appropriate place to discuss this? >>> >>> >>> Propose something for a PEP that's primarily useful to Cython without even >>> understanding the full implications myself first? >>> >>> I'd rather try to not annoy people; I figured the time I have the CPython >>> patches ready and tested is the time I ping python-dev... >> >> If you want to eventually propose a PEP, you really really really >> should be talking to them before. Otherwise you'll get everything >> worked out just the way you want and they'll be like "what is this? >> re-do it all totally differently". And they might be wrong, but then >> you have to reconstruct for them the whole debate and reasoning >> process and implicit assumptions that you're making and not realizing >> you need to articulate, so easier to just get all the interested(Continue reading)
On 16 May 2012 12:20, Dag Sverre Seljebotn <d.s.seljebotn <at> astro.uio.no> wrote: > On 05/14/2012 08:01 PM, Robert Bradshaw wrote: >> >> On Mon, May 14, 2012 at 10:05 AM, Nathaniel Smith<njs <at> pobox.com> wrote: >>> >>> On Mon, May 14, 2012 at 3:23 PM, Dag Sverre Seljebotn >>> <d.s.seljebotn <at> astro.uio.no> wrote: >>>> >>>> On 05/14/2012 01:34 PM, Stefan Behnel wrote: >>>>> >>>>> >>>>> Dag Sverre Seljebotn, 13.05.2012 21:37: >>>>>> >>>>>> >>>>>> Anyway, thanks for the heads up, this seems to need a bit more work. >>>>>> Input >>>>>> from somebody more familiar with this corner of the CPython API very >>>>>> welcome. >>>>> >>>>> >>>>> >>>>> Wouldn't you consider python-dev an appropriate place to discuss this? >>>> >>>> >>>> >>>> Propose something for a PEP that's primarily useful to Cython without >>>> even >>>> understanding the full implications myself first? >>>> >>>> I'd rather try to not annoy people; I figured the time I have the(Continue reading)
On 16 May 2012 14:03, mark florisson <markflorisson88 <at> gmail.com> wrote: > On 16 May 2012 12:20, Dag Sverre Seljebotn <d.s.seljebotn <at> astro.uio.no> wrote: >> On 05/14/2012 08:01 PM, Robert Bradshaw wrote: >>> >>> On Mon, May 14, 2012 at 10:05 AM, Nathaniel Smith<njs <at> pobox.com> wrote: >>>> >>>> On Mon, May 14, 2012 at 3:23 PM, Dag Sverre Seljebotn >>>> <d.s.seljebotn <at> astro.uio.no> wrote: >>>>> >>>>> On 05/14/2012 01:34 PM, Stefan Behnel wrote: >>>>>> >>>>>> >>>>>> Dag Sverre Seljebotn, 13.05.2012 21:37: >>>>>>> >>>>>>> >>>>>>> Anyway, thanks for the heads up, this seems to need a bit more work. >>>>>>> Input >>>>>>> from somebody more familiar with this corner of the CPython API very >>>>>>> welcome. >>>>>> >>>>>> >>>>>> >>>>>> Wouldn't you consider python-dev an appropriate place to discuss this? >>>>> >>>>> >>>>> >>>>> Propose something for a PEP that's primarily useful to Cython without >>>>> even >>>>> understanding the full implications myself first? >>>>>(Continue reading)
On 16 May 2012 14:25, mark florisson <markflorisson88 <at> gmail.com> wrote: > On 16 May 2012 14:03, mark florisson <markflorisson88 <at> gmail.com> wrote: >> On 16 May 2012 12:20, Dag Sverre Seljebotn <d.s.seljebotn <at> astro.uio.no> wrote: >>> On 05/14/2012 08:01 PM, Robert Bradshaw wrote: >>>> >>>> On Mon, May 14, 2012 at 10:05 AM, Nathaniel Smith<njs <at> pobox.com> wrote: >>>>> >>>>> On Mon, May 14, 2012 at 3:23 PM, Dag Sverre Seljebotn >>>>> <d.s.seljebotn <at> astro.uio.no> wrote: >>>>>> >>>>>> On 05/14/2012 01:34 PM, Stefan Behnel wrote: >>>>>>> >>>>>>> >>>>>>> Dag Sverre Seljebotn, 13.05.2012 21:37: >>>>>>>> >>>>>>>> >>>>>>>> Anyway, thanks for the heads up, this seems to need a bit more work. >>>>>>>> Input >>>>>>>> from somebody more familiar with this corner of the CPython API very >>>>>>>> welcome. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Wouldn't you consider python-dev an appropriate place to discuss this? >>>>>> >>>>>> >>>>>> >>>>>> Propose something for a PEP that's primarily useful to Cython without >>>>>> even >>>>>> understanding the full implications myself first?(Continue reading)
On 16 May 2012 14:25, mark florisson <markflorisson88 <at> gmail.com> wrote: > On 16 May 2012 14:03, mark florisson <markflorisson88 <at> gmail.com> wrote: >> On 16 May 2012 12:20, Dag Sverre Seljebotn <d.s.seljebotn <at> astro.uio.no> wrote: >>> On 05/14/2012 08:01 PM, Robert Bradshaw wrote: >>>> >>>> On Mon, May 14, 2012 at 10:05 AM, Nathaniel Smith<njs <at> pobox.com> wrote: >>>>> >>>>> On Mon, May 14, 2012 at 3:23 PM, Dag Sverre Seljebotn >>>>> <d.s.seljebotn <at> astro.uio.no> wrote: >>>>>> >>>>>> On 05/14/2012 01:34 PM, Stefan Behnel wrote: >>>>>>> >>>>>>> >>>>>>> Dag Sverre Seljebotn, 13.05.2012 21:37: >>>>>>>> >>>>>>>> >>>>>>>> Anyway, thanks for the heads up, this seems to need a bit more work. >>>>>>>> Input >>>>>>>> from somebody more familiar with this corner of the CPython API very >>>>>>>> welcome. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Wouldn't you consider python-dev an appropriate place to discuss this? >>>>>> >>>>>> >>>>>> >>>>>> Propose something for a PEP that's primarily useful to Cython without >>>>>> even >>>>>> understanding the full implications myself first?(Continue reading)
On Sun, May 13, 2012 at 8:35 PM, Dag Sverre Seljebotn <d.s.seljebotn <at> astro.uio.no> wrote: > On 05/12/2012 08:44 PM, Nathaniel Smith wrote: >> >> On Fri, May 11, 2012 at 2:25 PM, Dag Sverre Seljebotn >> <d.s.seljebotn <at> astro.uio.no> wrote: >>> >>> This comes from a refactor of the work on CEP 1000: A PEP proposal, with >>> a >>> hack for use in current Python versions and in the case of PEP rejection, >>> that allows 3rd party libraries to agree on extensions to PyTypeObject. >>> >>> http://wiki.cython.org/enhancements/cep1001 >>> >>> If this makes it as a PEP, I don't think we need to think about having >>> CEP >>> 1000 accepted as a PEP. >>> >>> Comments? >> >> >> There should probably be some discussion of memory management for the >> tpe_data pointers. (I assume it's "guaranteed to be valid for as long >> as the associated PyTypeObject, and the PyTypeObject is responsible >> for making sure any necessary cleanup happens if it gets deallocated", >> but a note to this effect would be good.) >> >> What happens if I want to inherit from PyTypeObject (a "metaclass") >> and also implement this interface? It is possible? What if I want to >> inherit from an existing subclass of PyTypeObject and add on this(Continue reading)
RSS Feed