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 mark.dickinson
Recipients alexhsamuel, benjamin.peterson, mark.dickinson, meador.inge, nascheme
Date 2010-06-30.10:21:41
SpamBayes Score 2.0198963e-09
Marked as misclassified No
Message-id <1277893303.61.0.806441132906.issue9011@psf.upfronthosting.co.za>
In-reply-to
Content
It turns out that removing this code from py3k wasn't a no-op.  It changed the semantics for complex literals.  In Python 3.1.2:

>>> -7j
-7j
>>> (-7j).real
0.0

But in current release31-maint branch, and in 3.2a0:

Python 3.2a0 (py3k:82347M, Jun 28 2010, 22:25:11) 
[GCC 4.2.1 (Apple Inc. build 5659)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> -7j
(-0-7j)
>>> (-7j).real
-0.0

So IMO r82044 (the release31-maint branch) should be reverted, to avoid nasty surprises when people upgrade from 3.1.2 to 3.1.3.

But I'd like to keep this change in py3k:  I consider that the 3.1 behaviour is buggy, and that the 3.2 behaviour is more correct (strange though it may seem at first sight), so I'd prefer to leave the current py3k behaviour as is, and add a Misc/NEWS entry describing the change if necessary.

Assigning this to me because I don't want it to get forgotten.  But if anyone else is interested in producing a patch for the cleanup of the CST->AST code, please do!
History
Date User Action Args
2010-06-30 10:21:43mark.dickinsonsetrecipients: + mark.dickinson, nascheme, benjamin.peterson, alexhsamuel, meador.inge
2010-06-30 10:21:43mark.dickinsonsetmessageid: <1277893303.61.0.806441132906.issue9011@psf.upfronthosting.co.za>
2010-06-30 10:21:42mark.dickinsonlinkissue9011 messages
2010-06-30 10:21:41mark.dickinsoncreate