I think you forgot a dot after the float "3." value.

If you write 3..__long__() it works.


Simon | 07/03/10 - 2:24 pm | #

Ah - but it's an int.

Another fine example though. I didn't know that a double-dot could ever be valid.
Fuzzyman | Homepage | 07/03/10 - 2:45 pm | #

You could do (3).__long__() to disambiguate.
xtian | 07/03/10 - 4:47 pm | #

ok, that hurts my head.
Doug Napoleone | Homepage | 07/03/10 - 6:19 pm | #

I first saw this on the python-list. Someone (sorry, couldn't remember any way to dig back a name) gave an explanation that I found really reasonable: the space disambiguates that from a float e.g. 3.040 .

Yeah, I keep the '.' away from the '0', better be careful from now
Hieu Hoang | 07/03/10 - 6:50 pm | #

My point is that you shouldn't *need* to disambiguate - because the 'period' is followed by a method call the lexer (if it is a look ahead lexer - even just a single character) should be able to disambiguate *without* needing extra clues...
Fuzzyman | Homepage | 07/03/11 - 3:22 pm | #

A single character lookahead wouldn't necessarily work, because a float could legitimately be followed by alpha characters with no space:

>>> x = 3.0
>>> if x==3.and True:
... print 'Hi'
...
Hi

Note no space between the "3." and the "and".

Granted, there are no keywords that start with underscore, so the __long__ example could be disambiguated with a single-character lookahead. But what if the attribute you're looking up started with an alphabetic character? The only way to disambiguate "3.and" (a float followed by a keyword) from "3.myattr" (an attribute lookup on the int 3) would be to have lookahead that read a complete token.

Lookahead is complicated enough that it's probably best to just require that disambiguating space and keep the parser code simple. Simple code is, after all, easier to tweak and harder to introduce bugs into.
Robin Munn | Homepage | 07/03/13 - 3:02 am | #

Fair enough - more than one character lookup needed.
Fuzzyman | Homepage | 07/03/15 - 1:34 am | #