that can be expressed as floats
> can be expressed EXACTLY as floats.
Yes, OK this makes sense.
My point is that, regardless of this answer, as a python user I should not
be worried by such details. At least: the doc string for round() should be
expanded to mention the int(round(x)) use case.
Simo
bothersome.
It's not even clear to me that int(round(x)) is always the
nearest integer to x.
Is it always true that float(some_int)>=some_int ? (for positive values).
(ie. I am wondering if truncating the float representation
of an int always gives back the original int).
Simon.
DECREF's, so yes, it is leaking a lot of references.
I won't make it to PyCon (it's a long way for me to come), but gee I've left
all the fun stuff for you to do !
:)
Even if AST transforms are not allowed, I see it as the strongest form of
code reflection, and long over-due in
he
overhead of
branching on opcodes would be insignificant. It seems that this is true indeed.
The patch id is 1408710.
[1]
http://developer.apple.com/documentation/DeveloperTools/gcc-4.0.1/gcc/Labels-as-Values.html
[2] http://mail.python.org/pipermail/python-dev/2003-February/033705.html
S
On Tue, 22 Nov 2005 11:31:34 -0800
Brett Cannon <[EMAIL PROTECTED]> wrote:
>
> On 11/21/05, Simon Burton <[EMAIL PROTECTED]> wrote:
> > On Thu, 17 Nov 2005 13:36:36 +1300
> > Tony Meyer <[EMAIL PROTECTED]> wrote:
> >
>
ntax much
> easier, as well as allowing some optimizations that were difficult
> with the previous Concrete Syntax Tree (CST).
> While there is no
> Python interface to the AST yet, one is intended for the not-so-
> distant future.
OK, who is doing this ? I am mad keen to get t
ke functionality should be straight forward now. I also
> hope some of the namespace optimizations get explored (e.g. PEP
> 267).
Is there a python interface ?
Simon.
--
Simon Burton, B.Sc.
Licensed PO Box 8066
ANU Canberra 2601
Australia
Ph. 61 02
