[Skip Montanaro wrote]
>
> I wrote PEP 304, "Controlling Generation of Bytecode Files":
>
> http://www.python.org/peps/pep-0304.html
>
> ...
> So speak up folks, otherwise my recommendation is that it be put out of its
> misery.
I've had use for it before, but have managed to work around th
I wrote PEP 304, "Controlling Generation of Bytecode Files":
http://www.python.org/peps/pep-0304.html
quite awhile ago. The first version appeared in January 2003 in response to
questions from people about controlling/suppressing bytecode generation in
certain situations. It sat idle for a
Here's the May 01-15 draft. Sorry for the delay. Please check the
Unicode summary at the end especially closely; I'm not entirely sure I
got that one all right. Thanks!
As always, please let us know if you have any corrections!
Steve
==
Summary Announcements
==
On 6/22/05, Skip Montanaro <[EMAIL PROTECTED]> wrote:
> If nothing else, extension module code that executes
>
> f = PyFloat_AsDouble(o);
>
> or
>
> if (PyFloat_Check(o)) {
>...
> }
>
> would either have to change or those functions would have to be rewritten to
> accept Dec
Fredrik> Is there actually much code around that relies on the
Fredrik> particular precision of 32- or 64-bit binary floats for
Fredrik> arithmetic, and ceases working when higher precision is
Fredrik> available?
Umm, yeah... The path you take from one or more string literals
re
On Wednesday 2005-06-22 13:32, Nick Coghlan wrote:
> Gareth McCaughan wrote:
> > [Keith Dart:]
> >>By "normal" integer I mean the mathematical definition.
> >
> > Then you aren't (to me) making sense. You were distinguishing
> > this from a unified int/long. So far as I can see, a unified int/long
On 6/22/05, Michael McLay <[EMAIL PROTECTED]> wrote:
> This idea is dead on arrival. The change would break many applications and
> modules. A successful proposal cannot break backwards compatibility. Adding a
> dpython interpreter to the current code base is one possiblity.
Is there actually much
On 6/18/05 4:45 AM -0400 Raymond Hettinger <[EMAIL PROTECTED]>
wrote:
> The above recommendations should get the PEP ready for judgement day.
I thought judgement day already happened for this PEP in the "Parade of
PEPs". No?
> Also, I recommend tightening the PEP's motivation. There are only
Tony Meyer wrote:
> .. _PEP 3XX: http://members.iinet.net.au/~ncoghlan/public/pep-3XX.html
Now that PEP 346 is on python.org, it would be best to reference that,
rather than the PEP 3XX URL on my ISP web space (that URL is now just
a redirect to PEP 346 on python.org).
Cheers,
Nick.
--
Nick C
Dmitry Dvoinikov wrote:
> Now, back to original question then, do you think it'd be
> beneficial to have some sort of exception ignoring or expecting
> statement ?
Not really - as I said earlier, I usually have something non-trivial
in the except or else clause, so I'm not simply ignoring the exc
Gareth McCaughan wrote:
> [Keith Dart:]
>>By "normal" integer I mean the mathematical definition.
>
> Then you aren't (to me) making sense. You were distinguishing
> this from a unified int/long. So far as I can see, a unified int/long
> type *does* implement (modulo implementation limits and bugs
Hi all,
raymond.hettinger at verizon.net Fri Jun 17 10:36:01 2005 wrote:
> The future direction of the decimal module likely entails literals in
> the form of 123.45d with binary floats continuing to have the form
> 123.45. This conflicts with the rational literal proposal of having
> 123.45 in
[GvR:]
> > Huh? C unsigned ints don't flag overflow either -- they perform
> > perfect arithmetic mod 2**32.
[Keith Dart:]
> I was talking about signed ints. Sorry about the confusion. Other
> scripting languages (e.g. perl) do not error on overflow.
C signed ints also don't flag overflow, nor do
You may have noticed that the summaries have been absent for the last month
- apologies for that; Steve has been dutifully doing his part, but I've been
caught up with other things.
Anyway, Steve will post the May 01-15 draft shortly, and here's May 16-31.
We should be able to get the first June o
Skip Montanaro wrote:
> That's fine, so XML-RPC is slower than Gherkin. I can't run the Gherkin
> code, but my XML-RPC numbers are a bit different than yours:
>
> XMLRPC encode 0.65 seconds
> XMLRPC decode 2.61 seconds
>
> That leads me to believe you're not using any sort of C XML decode
15 matches
Mail list logo
