Raymond Hettinger schrieb: >> the slightly obscure bit that requires some getting used to is >> that all these flags don't really mean "I have such and such >> feature" but just "I could have such and such >> feature, if the corresponding tp_xxx field were set". > > I would like to see that cleaned-up for Py3k. Ideally, the NULL or > non_NULL status of a slot should serve as its flag.
The flag indicates that the field is even present. If you have an extension module from an earlier Python release (in binary form), it won't *have* the field, so you can't test whether it's null. Accessing it will get to some other place in the data segment, and interpreting it as a function pointer will cause a crash. That's why the flags where initially introduced; presence of the flag indicates that the field was there at compile time. Of course, if everybody would always recompile all extension modules for a new Python feature release, those flags weren't necessary. 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
