[issue1413] int literal methods inaccessible

Martin v. Löwis added the comment: See http://www.python.org/doc/2.5/ref/whitespace.html which says that you can put spaces between arbitrary tokens, and http://www.python.org/doc/2.5/ref/attribute-references.html which says that all of primary, ".", and identifier are separate tokens in an a

[issue1413] int literal methods inaccessible

Michal Božoň added the comment: interesting. I'm not sure I've read anywhere that it is allowed to place a whitespace between object and attributes. Thanks __ Tracker <[EMAIL PROTECTED]> __ ___

[issue1413] int literal methods inaccessible

Martin v. Löwis added the comment: As now should be clear, there really is no bug here. Notice that you can also write 1 .__str__() -- nosy: +loewis resolution: -> invalid status: open -> closed __ Tracker <[EMAIL PROTECTED]>

[issue1413] int literal methods inaccessible

Michal Božoň added the comment: .. I remember.. it came onto my mind when I tried also -1.__str__() and found out that the dot has higher priority than unary minus :) __ Tracker <[EMAIL PROTECTED]> ___

[issue1413] int literal methods inaccessible

Michal Božoň added the comment: I don't know it's in docs, it came into my mind, maybe logically (but later) to put 1 into parentheses __ Tracker <[EMAIL PROTECTED]> __

[issue1413] int literal methods inaccessible

Christian Heimes added the comment: > I don't understand why 1.j is 1j .. because there's no int.j .. why then > 1.L is not 1L ? Complex numbers from the number domain |C which supersets |R. Complex numbers are usually implemented and viewed as 2d vectors made from two floating numbers real and

[issue1413] int literal methods inaccessible

Michal Božoň added the comment: (finally now I get it.. I have forgotten that complex numbers can be float.. :) sorry ) __ Tracker <[EMAIL PROTECTED]> __ ___

[issue1413] int literal methods inaccessible

Michal Božoň added the comment: .. however, fixing this is not necessary - because no one would probably use it, it's just a syntax inconsistency __ Tracker <[EMAIL PROTECTED]> __ _

[issue1413] int literal methods inaccessible

Michal Božoň added the comment: I don't understand why 1.j is 1j .. because there's no int.j .. why then 1.L is not 1L ? __ Tracker <[EMAIL PROTECTED]> __ __

[issue1413] int literal methods inaccessible

Christian Heimes added the comment: It's a tricky problem because it's ambiguous: >>> 1.j What's going to happen here? Does it do getattr(1, 'j') or does it create the imaginary number 1j? -- nosy: +tiran __ Tracker <[EMAIL PROTECTED]>

[issue1413] int literal methods inaccessible

Michal Božoň added the comment: .. OK, now I see than (1).__str__() works.. however, could be the parser fixed to 1.__str__() work too ? __ Tracker <[EMAIL PROTECTED]> __ __

[issue1413] int literal methods inaccessible

New submission from Michal Božoň: It's impossible to call methods of int literals directly e.g. 1.__str__() (the same for oct literals). Even through it works for float, hex, literals, etc.. >>> 0x1.__str__() '1' >>> 1e0.__str__() '1.0' >>> 1..__str__() '1.0' >>> hasattr(1, '__str__') True >>> 1