On Sat, Nov 04, 2000 at 09:25:37AM -0600, Charles G Waldman wrote: > Thomas Wouters writes: > > Actually, no, it isn't easily fixable, if at all. The problem is mostly the > > scientific notation: > > 1.e5 > You could strongly encourage people to spell this 1.0e5 Oh, sure, but that isn't going to solve anything, unless you are proposing to break the common practice of not requiring zeros before or after decimal points entirely, and thus breaking gobs of code. The problem is simply that the syntax is truly ambiguous, and there is no way to tell whether the statement x = 1.e5 is meant to assign 100000 (as a float) to 'x', or assign the 'e5' attribute of the object '1' to 'x'. Not even full context-based parsing is going to solve that. This is an edge case, and not likely to happen in real life, but I don't think it's really worth the trouble, all in all. We'd have to rewrite the parser into something other than a look-ahead parser to be able to correctly parse the cases where the syntax isn't really ambiguous, such as x = 1.e42e or some such, and that would still leave unparseable syntax. And all that just to avoid forcing people to use parentheses around 'normal' integer literals when directly following them with an attribute dereference. After all, t = 1 x = t.e5 is perfectly valid, and probably a lot more common. Who needs to run a method on a literal anyway [don't mention the .join() war!] -- Thomas Wouters <thomas@xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4