Meador Inge <mead...@gmail.com> added the comment:
> Mark
>
> Yes, that was what I was proposing.
As you pointed out in issue 3734, the patch is basically:
===================================================================
--- Objects/complexobject.c (revision 77909)
+++ Objects/complexobject.c (working copy)
@@ -1282,7 +1282,8 @@
PyObject_GenericGetAttr, /* tp_getattro */
0, /* tp_setattro */
0, /* tp_as_buffer */
- Py_TPFLAGS_DEFAULT | Py_TPFLAGS_BASETYPE, /* tp_flags */
+ Py_TPFLAGS_DEFAULT | Py_TPFLAGS_CHECKTYPES
+ | Py_TPFLAGS_BASETYPE, /* tp_flags */
complex_doc, /* tp_doc */
0, /* tp_traverse */
0, /* tp_clear */
plus the relevant test cases and documentation changes.
> Mark
>
> That's not really an option: it has the potential to break existing
> code that uses coercion. Removing coercion in Python 2.x would
> require at least a PEP plus one version's worth of DeprecationWarning.
Ah, good point. In that case I am -1 on changing the behavior at all. For the
sole reason that cases like Blair originally reported would not work as
expected in version < 2.7, then would work in 2.7, and then would break again
in > 3.0. I think explaining and documenting the change in behavior would be
really confusing.
> Blair
>
> If I am correct in think that it would seem to be a step backward.
I disagree. I think type coercion (or implicit conversions) is hard to follow
and understand. I say this from many years of C and C++ programming. I see
bugs all of the time in these languages due to conversions silently happening
that the programmer was not aware of. Yes the feature is convenient, but
documenting and explaining these rules to programmers becomes very tedious and
requires that most programmers have deep understanding of the languages typing
rules. This typically leads to books like "Effective C++" that catalog a list
of things *not* to do in a language. The relevant case for C++ being to avoid
user defined conversions and use explicit constructers. As such, I am
definitely +1 on removing coercion.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue5211>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
