Repository navigation
int literal methods inaccessible #45754
Description
| BPO | 1413 |
|---|---|
| Nosy | @loewis, @tiran |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = None
closed_at = <Date 2007-11-09.21:29:41.427>
created_at = <Date 2007-11-09.14:43:27.255>
labels = ['type-bug', 'invalid']
title = 'int literal methods inaccessible'
updated_at = <Date 2007-11-09.23:28:37.768>
user = 'https://bugs.python.org/mykhal'bugs.python.org fields:
activity = <Date 2007-11-09.23:28:37.768>
actor = 'loewis'
assignee = 'none'
closed = True
closed_date = <Date 2007-11-09.21:29:41.427>
closer = 'loewis'
components = []
creation = <Date 2007-11-09.14:43:27.255>
creator = 'mykhal'
dependencies = []
files = []
hgrepos = []
issue_num = 1413
keywords = []
message_count = 12.0
messages = ['57304', '57308', '57323', '57324', '57325', '57326', '57327', '57328', '57329', '57334', '57335', '57340']
nosy_count = 3.0
nosy_names = ['loewis', 'christian.heimes', 'mykhal']
pr_nums = []
priority = 'normal'
resolution = 'not a bug'
stage = None
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue1413'
versions = ['Python 2.5']
Activity
mykhal commentedon Nov 9, 2007
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..
mykhal commentedon Nov 9, 2007
.. OK, now I see than (1).__str__() works..
however, could be the parser fixed to 1.__str__() work too ?
tiran commentedon Nov 9, 2007
It's a tricky problem because it's ambiguous:
What's going to happen here? Does it do getattr(1, 'j') or does it
create the imaginary number 1j?
mykhal commentedon Nov 9, 2007
I don't understand why 1.j is 1j .. because there's no int.j .. why then
1.L is not 1L ?
mykhal commentedon Nov 9, 2007
.. however, fixing this is not necessary - because no one would probably
use it, it's just a syntax inconsistency
mykhal commentedon Nov 9, 2007
(finally now I get it.. I have forgotten that complex numbers can be
float.. :) sorry )
tiran commentedon Nov 9, 2007
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 img.
A long or long int however is from number domain |Z which doesn't allow
fraction and hence no '.', too.
It should explain why 1.L is illegal but 1.j is 1.0 * 1j.
I don't if it's possible to fix the problem with Python's parser.
However the inconsistency should be documented. Is it explained in the
docs and do the docs also mention the (1).__attr__ trick? I wasn't aware
that it works.
Christian
mykhal commentedon Nov 9, 2007
I don't know it's in docs, it came into my mind, maybe logically (but
later) to put 1 into parentheses
mykhal commentedon Nov 9, 2007
.. 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 :)
loewis commentedon Nov 9, 2007
As now should be clear, there really is no bug here.
Notice that you can also write
1 .__str__()
mykhal commentedon Nov 9, 2007
interesting. I'm not sure I've read anywhere that it is allowed to place
a whitespace between object and attributes. Thanks
loewis commentedon Nov 9, 2007
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 attributeref (not so in a literal, where the . is part of the
floating point literal).