This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author meador.inge
Recipients gumtree, mark.dickinson, meador.inge
Date 2010-02-04.02:54:37
SpamBayes Score 1.374802e-09
Marked as misclassified No
Message-id <1265252081.2.0.993744240476.issue5211@psf.upfronthosting.co.za>
In-reply-to
Content
> 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.
History
Date User Action Args
2010-02-04 02:54:41meador.ingesetrecipients: + meador.inge, mark.dickinson, gumtree
2010-02-04 02:54:41meador.ingesetmessageid: <1265252081.2.0.993744240476.issue5211@psf.upfronthosting.co.za>
2010-02-04 02:54:39meador.ingelinkissue5211 messages
2010-02-04 02:54:38meador.ingecreate