On 2008-11-21 19:36, Adam Olsen wrote:
> On Fri, Nov 21, 2008 at 10:53 AM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
>> Yes, it's a different way of writing and accessing the resp. fields.
>> No, it's not a different memory layout.
>> Yes, this is binary compatible.
>> No, this is not going to help you, since the rest of Python 3 is not ;-)
> 
> You're comparing already compiled code.  The issue is with
> recompiling, ie source compatibility.
> 
> In 2.5 the macros expanded to look like this:
> 
> PyTypeObject PyUnicode_Type = {
>     1,                              /* ob_refcnt */
>     &PyType_Type,              /* ob_type */
>     0,                                    /* ob_size */
>     "unicode",                       /* tp_name */
>     sizeof(PyUnicodeObject),      /* tp_basicsize */
> 
> Try the same macro in 3.0 and it'll look like this:
> 
> PyTypeObject PyUnicode_Type = {
>     {
>         {
>             1,                              /* ob_refcnt */
>             &PyType_Type,              /* ob_type */
>         },
>         /* Trailing ob_size gets implicitly initialized to 0 */
>     },
>     0,                                        /* ob_size?  Nope, tp_name! */
>     "unicode",                      /* tp_name?  Nope, tp_basicsize! */
>     sizeof(PyUnicodeObject),            /* tp_basicsize?  Nope, tp_itemsize! 
> */
> 
> The compiler knows what layout a PyTypeObject should have, but the
> initializer doesn't match up.

Well, yes, of course. That's the whole purpose of PEP 3123, isn't it ?

Starting with Python 3, you have to use PyVarObject_HEAD_INIT()
on PyVarObjects and PyObject_HEAD_INIT() on PyObjects. I don't
see the problem. It's just another change to remember when porting
to Python 3.

The whole type slot interface has changed significantly between
Python 2 and 3, so this minor clarification is really harmless compared
to all the other changes:

 * PyNumberMethods have changed due to removal of the division,
   oct, hex and coercion slots

 * PySequenceMethods have changed, but maintained binary compatibility
   (why ?) by replacing the removed slice functions with dummy pointers

 * PyBufferProcs is a completely new design

 * A lot type flags were removed.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Nov 21 2008)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________
2008-11-12: Released mxODBC.Connect 0.9.3      http://python.egenix.com/

:::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! ::::


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe: 
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com

Reply via email to