[issue9011] ast_for_factor unary minus optimization changes AST

Changes by Mark Dickinson : -- resolution: -> fixed status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing list Un

[issue9011] ast_for_factor unary minus optimization changes AST

Roundup Robot added the comment: New changeset ea36de7926f8 by Mark Dickinson in branch '2.7': Issue #9011: AST creation no longer modifies CST for negated numeric literals. http://hg.python.org/cpython/rev/ea36de7926f8 -- nosy: +python-dev ___ Python

[issue9011] ast_for_factor unary minus optimization changes AST

Mark Dickinson added the comment: New patch. -- assignee: -> mark.dickinson Added file: http://bugs.python.org/file28118/issue9011_v2.patch ___ Python tracker ___ ___

[issue9011] ast_for_factor unary minus optimization changes AST

Changes by Mark Dickinson : -- versions: -Python 2.6, Python 3.1 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue9011] ast_for_factor unary minus optimization changes AST

Mark Dickinson added the comment: And -1j.real is -(1j.real), of course, not (-1j).real. My bad. -- ___ Python tracker ___ ___ Python-

[issue9011] ast_for_factor unary minus optimization changes AST

Amaury Forgeot d'Arc added the comment: Indeed, -1j is not a literal: >>> dis.dis(lambda :-1j.real) 1 0 LOAD_CONST 0 (1j) 3 LOAD_ATTR0 (real) 6 UNARY_NEGATIVE 7 RETURN_VALUE -- nosy: +amaury.forgeo

[issue9011] ast_for_factor unary minus optimization changes AST

Mark Dickinson added the comment: With the string, the minus sign applies only to the imaginary part; with the expression '-1j', it applies to the whole complex number (both real and imaginary parts). I don't see any sensible way to 'fix' the string to complex conversion; indeed, I think any

[issue9011] ast_for_factor unary minus optimization changes AST

Antonio Cuni added the comment: I would say that the complex-from-string constructor should be fixed to handle this special case "correctly". I find very confusing that we get a different result whether we use a string literal or not. For example, in pypy we use the same code for parsing liter

[issue9011] ast_for_factor unary minus optimization changes AST

Mark Dickinson added the comment: No, that's expected behaviour. 1j is complex(0.0, 1.0) -1j is complex(-0.0, -1.0) so -1j.real is -0.0. There's not really any other sensible way to handle this. The complex-from-string constructor, on the other hand, is more careful about interpreting signs.

[issue9011] ast_for_factor unary minus optimization changes AST

Antonio Cuni added the comment: there is still an inconsistency in handling negative imaginary literals: >>> -1j.real -0.0 >>> complex('-1j').real 0.0 -- nosy: +antocuni ___ Python tracker _

[issue9011] ast_for_factor unary minus optimization changes AST

R. David Murray added the comment: Given the long projected lifetime of 2.7, I suppose it is. -- ___ Python tracker ___ ___ Python-bug

[issue9011] ast_for_factor unary minus optimization changes AST

Mark Dickinson added the comment: Yes, sorry; I'm not likely to find time to do anything with this. Unassigning, and downgrading priority. Is it worth leaving this open in case anyone wants to do something about it? -- assignee: mark.dickinson -> priority: high -> normal _

[issue9011] ast_for_factor unary minus optimization changes AST

R. David Murray added the comment: Mark, are you still planning to do something for 3.1/2.7, or should this be closed? -- nosy: +r.david.murray stage: commit review -> needs patch ___ Python tracker __

[issue9011] ast_for_factor unary minus optimization changes AST

Neil Schemenauer added the comment: I'm late to the party but looks like Mark has a good handle on the issues. I would recommend not changing behavior in a bugfix release. I'm pretty sure code "in the wild" would be broken. -- ___ Python tracker

[issue9011] ast_for_factor unary minus optimization changes AST

Mark Dickinson added the comment: Added tests for Python 3.2's corrected treatment of negated imaginary literals in r82391, along with a Misc/NEWS entry indicating the changed behaviour. Restored version numbers for this issue, which I seem to have accidentally deleted earlier. (Including 3.

[issue9011] ast_for_factor unary minus optimization changes AST

Mark Dickinson added the comment: Added tests for the current Python < 3.2 treatment of imaginary literals in r82390 (release31-maint). These tests should be backported to trunk, but I'll wait until after the release of 2.7 for that. -- ___ Python

[issue9011] ast_for_factor unary minus optimization changes AST

Mark Dickinson added the comment: r82044 reverted in r82389. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue9011] ast_for_factor unary minus optimization changes AST

Mark Dickinson added the comment: 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

[issue9011] ast_for_factor unary minus optimization changes AST

Changes by Meador Inge : -- nosy: +minge ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/

[issue9011] ast_for_factor unary minus optimization changes AST

Mark Dickinson added the comment: Summary of brief discussion on #python-dev: - This is a hacky patch; it would be better to rewrite that portion of ast.c in a way that doesn't modify the original CST at all. With 2.7 so close, I daren't try anything more invasive than this patch, though. (I

[issue9011] ast_for_factor unary minus optimization changes AST

Mark Dickinson added the comment: That sounds like a reasonable quick fix. Here's a patch. -- keywords: +patch stage: -> commit review Added file: http://bugs.python.org/file17696/issue9011.patch ___ Python tracker

[issue9011] ast_for_factor unary minus optimization changes AST

Alex Samuel added the comment: How about saving the original value of STR(pnum) and restoring it after calling ast_for_atom()? This is not thread-safe, but I don't understand Python's threading model well enough to know whether the GIL is held in this function. On 6/17/2010 8:40 AM, Mark Dic

[issue9011] ast_for_factor unary minus optimization changes AST

Changes by Mark Dickinson : -- versions: -Python 3.1, Python 3.2 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue9011] ast_for_factor unary minus optimization changes AST

Mark Dickinson added the comment: Fixed in r82043 (py3k) and r82044 (release31-maint), simply by removing the relevant 'if' block. For 2.x, Antoine (on IRC) pointed out that there might well be third party code that depends on -0x8000 being an int rather than a long (32-bit machine), so

[issue9011] ast_for_factor unary minus optimization changes AST

Mark Dickinson added the comment: Results from Jython: newton:jython2.5.1 dickinsm$ ./jython Jython 2.5.1 (Release_2_5_1:6813, Sep 26 2009, 13:47:54) [Java HotSpot(TM) 64-Bit Server VM (Apple Inc.)] on java1.6.0_20 Type "help", "copyright", "credits" or "license" for more information. >>> -214

[issue9011] ast_for_factor unary minus optimization changes AST

Mark Dickinson added the comment: N.B. That if block isn't pure optimization: removing it gives a minor change in behaviour: Currently (Python 2.7, on a 64-bit machine): >>> -9223372036854775808 -9223372036854775808 And with the optimization removed: >>> -9223372036854775808 -922337203685

[issue9011] ast_for_factor unary minus optimization changes AST

Changes by Mark Dickinson : -- versions: -Python 2.5 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mai

[issue9011] ast_for_factor unary minus optimization changes AST

Mark Dickinson added the comment: Confirmed in trunk and py3k, both of which raise ValueError on the second compile: Python 2.7rc1+ (trunk:82042, Jun 17 2010, 09:52:12) [GCC 4.0.1 (Apple Inc. build 5490)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> imp

[issue9011] ast_for_factor unary minus optimization changes AST

Changes by Mark Dickinson : -- nosy: +mark.dickinson ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail

[issue9011] ast_for_factor unary minus optimization changes AST

Changes by R. David Murray : -- nosy: +benjamin.peterson ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://

[issue9011] ast_for_factor unary minus optimization changes AST

New submission from Alex Samuel : The unary negative optimization in ast_for_factor() seems to modify the ST in a way changes its meaning. In Python 3.1.2, the ST is no longer compilable: $ cat exprbug.py import parser st = parser.expr("-3") print(st.totuple()) compiled = st.compile() print(e