Noam Raphael wrote:
>>The setentry typedef clearly violates the principles of the API, so
>>it should be renamed.
>
> (And so will _setobject, although I think it will be much easier to remove
> it.)
That's not that certain. setentry is a typedef; _setobject is a tag
name of a struct. The documentation is silent as to whether tag names
also follow the prefixing rules. Many tag names don't, e.g. PyObject
is a typedef for struct _object.
>>That would not be conforming to the C language standard (although
>>accepted by most compilers).
>
>
> Can you explain why it is not conforming to the standard? Can't a
> typedef be used intechangably with the original type?
6.2.7 of ISO C says
6.2.7 Compatible type and composite type
[#1] Two types have compatible type if their types are the
same. Additional rules for determining whether two types
are compatible are described in 6.7.2 for type specifiers,
in 6.7.3 for type qualifiers, and in 6.7.5 for
declarators.46) Moreover, two structure, union, or
enumerated types declared in separate translation units ...
We are not dealing with separate translation units here, so I cut
the paragraph. I'm also ommitting several other exceptions where
types are compatible (e.g. enum types are compatible with the
underlying integral type). Pointer types are compatible if the
underlying types are compatible, and the types have the same
qualifiers.
So if you mention an equally-layouted struct twice in the
same translation unit, you still get incompatible types. As a result,
pointers to these structs are also incompatible, so you cannot
assign between them.
> The first: All user visible names defined by Python.h (except those
> defined by the included standard headers) have one of the prefixes
> "Py" or "_Py".
> The third: Structure member names do not have a reserved prefix.
>
> I think that "structure member names" refers to things like setentry.
Ah. It doesn't. It means things like hash and key (for setentry),
or fill, used, mask, table, ... (for struct _setobject).
That they don't use a name prefix means that there could be a
collision with macro names (and indeed, that has happened).
> The third sentence contradicts the first since structure member names
> are user visible names. Anyway, it seems to me best if the third
> sentence will be removed and all names will start with Py or _Py.
No. Do you really want ob_type to be renamed to Py_ob_type?
Regards,
Martin
_______________________________________________
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/archive%40mail-archive.com
