Changes by Mark Dickinson dicki...@gmail.com:
--
versions: -Python 2.6, Python 3.1
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9011
___
___
Mark Dickinson added the comment:
New patch.
--
assignee: - mark.dickinson
Added file: http://bugs.python.org/file28118/issue9011_v2.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9011
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
___
Changes by Mark Dickinson dicki...@gmail.com:
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9011
___
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 rep...@bugs.python.org
http://bugs.python.org/issue9011
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
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
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
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:
Mark Dickinson added the comment:
And -1j.real is -(1j.real), of course, not (-1j).real. My bad.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9011
___
Mark Dickinson dicki...@gmail.com 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 -
R. David Murray rdmur...@bitdance.com added the comment:
Given the long projected lifetime of 2.7, I suppose it is.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9011
___
R. David Murray rdmur...@bitdance.com 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 rep...@bugs.python.org
Neil Schemenauer nas-pyt...@arctrix.com 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.
--
Mark Dickinson dicki...@gmail.com 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
Mark Dickinson dicki...@gmail.com added the comment:
r82044 reverted in r82389.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9011
___
___
Mark Dickinson dicki...@gmail.com 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.
--
Mark Dickinson dicki...@gmail.com 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
Changes by Meador Inge mead...@gmail.com:
--
nosy: +minge
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9011
___
___
Python-bugs-list mailing list
Mark Dickinson dicki...@gmail.com 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
Changes by Mark Dickinson dicki...@gmail.com:
--
nosy: +mark.dickinson
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9011
___
___
Python-bugs-list
Mark Dickinson dicki...@gmail.com 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
Changes by Mark Dickinson dicki...@gmail.com:
--
versions: -Python 2.5
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9011
___
___
Mark Dickinson dicki...@gmail.com 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
Mark Dickinson dicki...@gmail.com 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
Mark Dickinson dicki...@gmail.com 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
Changes by Mark Dickinson dicki...@gmail.com:
--
versions: -Python 3.1, Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9011
___
___
Alex Samuel a...@alexsamuel.net 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
Mark Dickinson dicki...@gmail.com 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
New submission from Alex Samuel a...@alexsamuel.net:
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 =
Changes by R. David Murray rdmur...@bitdance.com:
--
nosy: +benjamin.peterson
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9011
___
___
31 matches
Mail list logo
