Hack request: rational numbers

[Alex Martelli]

"Pearu Peterson" <pearu at ioc.ee> wrote in message
news:Pine.LNX.4.21.0101261251120.7303-100000 at kev.ioc.ee...
    [snip]
> And it makes me think that (some? most?) people want to keep
> Python usage only in web/gui based applications rather than extending its
> usage to scientific computing (both *numerical* and *symbolical*).

Can't speak for others, but, as for me: I'm quite keen using Python
for scientific computing (both numerical and symbolic -- it's my main
tool for my research on the fundamentals of contract-bridge) and in
applications which may have nothing to do with the web nor with guis.

Such usage does not require tampering with the lexical fundamentals
of Python for the purpose of little tweaks to syntax-sugar level
issues -- any more than usage for gui or web stuff does.  Keep it
simple; syntax sugar, we can do without.


> > Maybe.  I suspect not enough to make a difference.  It's mooted that
> >
> > 1/2
> >
> > will produce something other than "0" in Py3K, but I can't remember
> > whether a rational or a floating point result seemed most likely last
> > time this went around.
>
> Though, I'll wait (hope) for Alex's PEP about this and I'll probably try
> to implement `3r' hooks to Python myself (it's just too appeling to me;).

Sorry, I'm not going to write any PEP about this.  The PEP I mentioned
was NOT about this, but rather about having getattr/setattr support in
module objects (or equivalent functionality), and you have already
indicated that this is of no interest here (your current solution of
writing R*3/4 being at least as good as the one of writing r3/4 which
such a change would enable).  Nor am I probably going to write it.

Although having 'hooks on token-level syntax errors' *IS* in fact
quite appealing, I'll admit that -- it may be the dark side of the
force, but the idea of being able to extend (*NOT* _alter_, since
only on token-level syntax-errors would the hook be called) the
syntax sugar IS perversely fascinating (the hook would receive the
string of the token that would otherwise raise the error, and
either raise the error itself, OR return a different string [to
be reparsed], or maybe better a tuple-of-tokens).


Alex