service-life prediction algorithms for rocket motors in
Fortran 77 during several long summers. I've been using Python for
more than ten years, mainly for teaching but also occasionally for
research purposes.
Mark Dickinson
___
Python-Dev mailing list
On 9/17/07, Facundo Batista [EMAIL PROTECTED] wrote:
In the Tracker Issue...
http://bugs.python.org/issue1772851
... Mark Dickinson came with a patch that alters in a very corner case
how the hash is calculated to a long integer.
Much as I'd like this patch to be applied, I feel
On 10/2/07, Facundo Batista [EMAIL PROTECTED] wrote:
2007/10/2, Raymond Hettinger [EMAIL PROTECTED]:
Yes! We have guaranteed that spec updates are to be treated as bug
fixes and backported. This is especially important in this case
because other errors have been fixed and the test cases
On 10/15/07, Mateusz Rukowicz [EMAIL PROTECTED] wrote:
[...] I
would like to know if there is still interest in C version of Decimal.
If so - should I write PEP, or just code and 'we'll see later'?
I'd be happy to see decimal.py replaced by a C version giving
essentially the same
On 10/16/07, Mateusz Rukowicz [EMAIL PROTECTED] wrote:
Well, I am pretty sure, that addition works in linear time in Python
version :.
Unfortunately not. Here are some timings from my laptop:
from timeit import Timer
Timer(x+x, from decimal import Decimal; x =
Decimal('1'*5000)).timeit(100)
On 10/16/07, Fredrik Johansson [EMAIL PROTECTED] wrote:
There is another alternative, which is to use integers exclusively for
both representation and arithmetic, and only compute an explicit digit
tuple or string in special cases. I'm doing this in in mpmath
On 10/16/07, Daniel Stutzbach [EMAIL PROTECTED] wrote:
On 10/16/07, Mark Dickinson [EMAIL PROTECTED] wrote:
the reverse conversion to get a Decimal result; both of these
conversions (tuple of digits - integer) take time quadratic in the
size of the tuple/integer.
Instead
On Jan 4, 2008 11:14 AM, Jeffrey Yasskin [EMAIL PROTECTED] wrote:
On Jan 4, 2008 4:40 AM, Facundo Batista [EMAIL PROTECTED] wrote:
Do you mean that the response in the following case is of type float?:
round(decimal.Decimal(2.5))
3.0
Yes.
That seems a little peculiar to me: wouldn't
On Jan 5, 2008 5:54 PM, [EMAIL PROTECTED] wrote:
At first I didn't realize why I'd missed this feature. While the
rounding *modes* are well documented, though, after 20 minutes of
reading documentation I still haven't found a method or function that
simply rounds a decimal to a given
Hello all,
I've recently been granted commit privileges; so, following the usual
protocol, here's a quick introduction. I'm a mathematician by day; my
degree is in number theory, but five summers of Fortran 77 programming and
two semesters of teaching numerical analysis have given me a taste for
On Jan 19, 2008 3:06 PM, Jeffrey Yasskin [EMAIL PROTECTED] wrote:
In the Rational class that I've recently checked into Python 2.6
(http://bugs.python.org/issue1682), it might be nice to provide a
method that, given a particular rational number, returns a nearby
number that's nicer in some
On Jan 21, 2008 3:44 AM, Paul Moore [EMAIL PROTECTED] wrote:
On 21/01/2008, Tim Peters [EMAIL PROTECTED] wrote: By useful I
don't mean lots of people will use it ;-) I mean /some/
people will use it -- a way to generate the sequence of convergents is
a fundamental tool that can be used for
A request for information:
What non IEEE 754 platforms exist that people care about running Python 2.6,
Python 3.0 and higher on?
By non IEEE 754 platform, I mean a platform where either the C double is not
the usual 64-bit IEEE floating-point format, or where the C double is IEEE
format but the
On Feb 1, 2008 8:04 PM, Christian Heimes [EMAIL PROTECTED] wrote:
I spoke to Mikko Ohtamaa (Moo-- on #pys60) and he gave me the name of a
Nokia developer and this link
http://discussion.forum.nokia.com/forum/showthread.php?t=97263. I
already contacted the developer and asked him to reply
On Thu, Feb 14, 2008 at 11:21 AM, Ronald Oussoren [EMAIL PROTECTED]
wrote:
Hi,
I've just filed issue2114 (http://bugs.python.org/issue2114) because
test_decimal.py fails on OSX 10.3 with Python 2.5.2c1.
It looks like you've got a file Lib/test/decimaltestdata/normalize.decTest
(or possible
Dear all,
I'd like to draw your attention to some of the work that's been going on in
the trunk-math branch. Christian Heimes and I have been working on various
aspects of Python mathematics, and we're hoping to get at least some of this
work into Python 2.6/3.0. Most of the changes are
Apologies for the bad formatting. Here's a repost with shorter lines.
Dear all,
I'd like to draw your attention to some of the work that's been going on in
the trunk-math branch. Christian Heimes and I have been working on various
aspects of Python mathematics, and we're hoping to get at least
Aargh. Extra long lines again. Here's a repost.
An update: after some discussion, we're planning a PEP for the with
ieee754
and related ideas, perhaps aimed at Python 3.1; there are lots of difficult
decisions to be made, and plenty that would benefit from community feedback.
In the
An update: after some discussion, we're planning a PEP for the with
ieee754 and related ideas, perhaps aimed at Python 3.1; there are lots of
difficult decisions to be made, and plenty that would benefit from community
feedback. In the meantime, we'll get the rest of the fixes/additions tidied
On Feb 17, 2008 2:42 PM, Raymond Hettinger [EMAIL PROTECTED] wrote:
There are some modules like Decimal that make a promise to run on earlier
versions of Python. In those cases only the first change (backwards
compatible)
should be made. Our 5,000 line Decimal package will need to wait for
On Feb 17, 2:42 pm, Raymond Hettinger [EMAIL PROTECTED] wrote:
There are some modules like Decimal that make a promise to run on earlier
versions of Python. In those cases only the first change (backwards
compatible)
should be made. Our 5,000 line Decimal package will need to wait for 3.0
On Thu, Mar 13, 2008 at 4:20 AM, Imri Goldberg [EMAIL PROTECTED] wrote:
My suggestion is to do either of the following:
1. Change floating point == to behave like a valid floating point
comparison. That means using precision and some error measure.
2. Change floating point == to raise an
On Sun, Mar 16, 2008 at 1:32 PM, Neal Norwitz [EMAIL PROTECTED] wrote:
I think this is possible, though considerable work. Probably the
biggest win will be creating a mock for socket and using mock sockets
in the tests for asyn{core,chat}, smtplib, xmlrpc, etc. That will fix
about 75% of the
On Sun, Mar 16, 2008 at 7:19 PM, Trent Nelson [EMAIL PROTECTED] wrote:
Yeah test_tokenize is weird, I've been looking into it as well. Here's a
sample failure from a Windows buildbot:
[failure log snipped...]
On that first line, 'f' is lib/test/tokenize_tests.txt, so basically, it's
On Mon, Jan 5, 2009 at 3:12 PM, Jim Jewett jimjjew...@gmail.com wrote:
Our of curiousity, why are these constants for internal use only?
I don't think anyone ever thought about deliberately making them
public---I suspect they were introduced as a speed optimization.
I can see that having things
I noticed that the builtin numeric types (int, float, complex) all still
have a __long__ method in 3.x. Shouldn't this have disappeared as
part of the int/long unification? Is there any reason not to remove this
(by setting the nb_long entry to 0 in all three cases)?
Mark
On Sun, Jan 11, 2009 at 7:43 PM, Benjamin Peterson benja...@python.org wrote:
On Sun, Jan 11, 2009 at 12:40 PM, Martin v. Löwis mar...@v.loewis.de
wrote:
There are, apparently, still callers of the nb_long slot, so I would be
cautious.
We should remove all usage of it and rename it to
On Thu, Jan 15, 2009 at 9:13 AM, Kristján Valur Jónsson
krist...@ccpgames.com wrote:
However, these:
==
ERROR: test_ftruncate (test.test_os.TestInvalidFD)
--
On Thu, Jan 15, 2009 at 4:19 PM, Kristján Valur Jónsson
krist...@ccpgames.com wrote:
Well, all the other functions raise OSError when the file descriptor is
invalid. IOError usually means that the IO itself failed.
I wonder if it is platform specific? Does it raise IOError on all platforms?
On Thu, Jan 15, 2009 at 5:06 PM, Kristján Valur Jónsson
krist...@ccpgames.com wrote:
Interesting.
Looks like a bug, really. It's the only function that sets IOError. All
others use posix_error which raises an OSError.
Maybe. But changing it risks breaking existing code, so would certainly
On Thu, Jan 15, 2009 at 10:40 PM, Kristján Valur Jónsson
krist...@ccpgames.com wrote:
Right. I've fixed the remainder, things should quiet down now.
K
Thank you!
___
Python-Dev mailing list
Python-Dev@python.org
Now that all uses of nb_long and __long__ have disappeared from
the 3.x codebase, would it make sense to mark PyNumber_Long
as deprecated in the c-api documentation, and convert all existing
uses (I count a grand total of 3 uses in the py3k branch!) to
PyNumber_Int?
(The two functions behave
On Fri, Jan 16, 2009 at 10:42 PM, Brett Cannon br...@python.org wrote:
Assuming we have been moving the C API usage to PyInt and not PyLong,
then yes it makes sense.
Hmm. I don't think there's been any such move. Maybe there
should be.
Benjamin wondered aloud about deprecating PyNumber_Long
This is probably a stupid question, but here goes:
Can anyone suggest good strategies for debugging buildbot
test failures, for problems that aren't reproducible locally?
There have been various times in the past that I've wanted
to be able to do this. Right now, I'm thinking particularly of
On Sun, Jan 18, 2009 at 11:03 PM, scott mc scott...@gmail.com wrote:
I built 2.7 on Haiku, but am getting failures in the regression tests.
Many of them are in math related tests, failing in the 15th decimal
place on test_decimal and a few others like that, I posted a ticket on
Haiku's trac
Thanks for all the feedback.
[Michael Foord]
At Resolver Systems we regularly extend the test framework purely
to provide more diagnostic information in the event of test failures.
We do a lot of functional testing through the UI, which is particularly
prone to intermittent and hard to
On Fri, Jan 30, 2009 at 4:03 PM, Barry Warsaw ba...@python.org wrote:
To clarify: cruft that should have been removed 3.0 is fine to remove for
3.0.1, for some definition of should have been.
Just to double check, can I take this as a green light to continue
with the cmp removal
Here's a question (actually, three questions) for python-dev that
came up in the issue 1717 (removing cmp) discussion.
Once the cmp removal is complete, the type object's tp_compare
slot will no longer be used. The current plan is to rename it to
tp_reserved, change its type to (void *), and
On Sat, Jan 31, 2009 at 9:28 PM, Martin v. Löwis mar...@v.loewis.de wrote:
tp_reserved sounds fine. In 3.0.1, filling it with a function pointer
should give no error, since that would be a binary-incompatible change.
I'm not sure I understand you here. Are you saying that in your
opinion it
On Sun, Feb 1, 2009 at 4:21 PM, Guido van Rossum gu...@python.org wrote:
Sounds like Martin is referring to your suggestion to raise an
exception when initializing a type that has a non-NULL thing here. I
agree with him.
Got it. Thank you.
Mark
___
On Sun, Feb 1, 2009 at 6:03 PM, Martin v. Löwis mar...@v.loewis.de wrote:
No. I thought someone (you?) proposed that it should cause a runtime
error if a type definitions fills the tp_compare slot. I say that
3.0.1 must not produce such an error.
Thanks. I'm with you now. I'll get rid of the
On Mon, Feb 2, 2009 at 11:38 AM, Nick Coghlan ncogh...@gmail.com wrote:
That's what the -3 command line switch is for - it sets a boolean flag
that C code can check to see if it should emit warnings for things that
are going to break in Python 3.x.
Understood. My worry was that we'd get a lot
On Mon, Feb 2, 2009 at 10:36 AM, Nick Coghlan ncogh...@gmail.com wrote:
I'm wondering if Mark should add the exception he recently removed back
in as a Deprecation Warning when tp_compare is defined, but
tp_richcompare is not.
This sounds reasonable to me. A third-party module that implements
On Fri, Feb 6, 2009 at 9:04 PM, Lisandro Dalcin dalc...@gmail.com wrote:
At Objects/longobject.c, you should see that in almost all cases
OverflowError is raised when a unsigned integral is requested from a
negative PyLong. However, See this one:
[...]
if (!is_signed) {
On Fri, Feb 6, 2009 at 11:38 PM, Lisandro Dalcin dalc...@gmail.com wrote:
Done, http://bugs.python.org/issue5175
Thank you!
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
A few months ago there was a discussion [1] about changing
Python's long integer type to use base 2**30 instead of base
2**15. http://bugs.python.org/issue4258 was opened for this.
With much help from many people (but especially Antoine
and Victor), I've finally managed to put together an
On Tue, Feb 17, 2009 at 7:49 PM, Martin v. Löwis mar...@v.loewis.de wrote:
Can you please upload it to Rietveld also?
Will do. I'm getting a 500 Server Error at the moment, but I'll keep trying.
Mark
___
Python-Dev mailing list
Python-Dev@python.org
On Tue, Feb 17, 2009 at 8:42 PM, Guido van Rossum gu...@python.org wrote:
Use the upload.py script (/static/upload.py) rather than the Create Issue
page.
Thanks. That worked.
http://codereview.appspot.com/14105
___
Python-Dev mailing list
On Wed, Feb 25, 2009 at 2:23 PM, Barry Warsaw ba...@python.org wrote:
This is now done. Please let me know if you have any problems with the
mirrors.
Is the cron job that's supposed to update the bzr repository still running?
I'm getting 'No revisions to pull' when I do 'bzr pull' for the py3k
On Fri, Feb 27, 2009 at 7:26 PM, Barry Warsaw ba...@python.org wrote:
On Feb 25, 2009, at 2:03 PM, Mark Dickinson wrote:
Is the cron job that's supposed to update the bzr repository still
running?
I think I have this fixed now. The branch updater is running on dinsdale
now, but I'm currently
2009/3/24 Daniel Stutzbach dan...@stutzbachenterprises.com:
[...]
100 nanoseconds, py3k trunk:
ceval - PyObject_GetItem (object.c) - list_subscript (listobject.c) -
PyNumber_AsSsize_t (object.c) - PyLong_AsSsize_t (longobject.c)
[more timings snipped]
Does removing the PyLong_Check call in
On Tue, Mar 24, 2009 at 3:50 PM, Daniel Stutzbach
dan...@stutzbachenterprises.com wrote:
On Tue, Mar 24, 2009 at 10:13 AM, Mark Dickinson dicki...@gmail.com wrote:
Does removing the PyLong_Check call in PyLong_AsSsize_t
make any noticeable difference to these timings?
Making no other changes
[Antoine]
- Issue #5593: code like 1e16+2. is optimized away and its result stored
as
a constant (again), but the result can vary slightly depending on the internal
FPU precision.
[Guido]
I would just not bother constant folding involving FP, or only if the
values involved have an exact
On Mon, Apr 6, 2009 at 9:05 PM, Raymond Hettinger pyt...@rcn.com wrote:
The code for the lsum() recipe is more readable with a line like:
exp = long(mant * 2.0 ** 53)
than with
exp = long(mant * 9007199254740992.0)
It would be ashamed if code written like the former suddenly
started
Executive summary (details and discussion points below)
=
Some time ago, Noam Raphael pointed out that for a float x,
repr(x) can often be much shorter than it currently is, without
sacrificing the property that eval(repr(x)) == x, and proposed
changing Python accordingly. See
On Wed, Apr 8, 2009 at 7:13 AM, John Barham jbar...@gmail.com wrote:
If you play around a bit it becomes clear that what set.pop() returns
is independent of the insertion order:
It might look like that, but I don't think this is
true in general (at least, with the current implementation):
foo
On Sat, Apr 11, 2009 at 11:14 AM, Chris Withers ch...@simplistix.co.uk wrote:
Also got the following failure from a py3k checkout:
test test_cmd_line failed -- Traceback (most recent call last):
File /Users/chris/py3k/Lib/test/test_cmd_line.py, line 143, in
test_run_code
0)
On Fri, Apr 10, 2009 at 2:31 PM, Barry Warsaw ba...@python.org wrote:
bugs.python.org is apparently down right now, but I set issue 5724 to
release blocker for 2.6.2. This is waiting for input from Mark Dickinson,
and it relates to test_cmath failing on Solaris 10.
I'd prefer to leave
On Tue, Apr 14, 2009 at 9:45 AM, Ned Deily n...@acm.org wrote:
Ned Deily n...@acm.org wrote:
Eric Smith e...@trueblade.com wrote:
Before then, if anyone could build and test the py3k-short-float-repr
branch on any of the following machines, that would be great:
[...]
Something
By the way, a simple native build on OS X 10.4/PPC passed all tests (that
we're already failing before).
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
On Tue, Apr 14, 2009 at 11:37 AM, Mark Dickinson dicki...@gmail.com wrote:
By the way, a simple native build on OS X 10.4/PPC passed all tests (that
we're already failing before).
s/we're/weren't
___
Python-Dev mailing list
Python-Dev@python.org
http
On Tue, Apr 14, 2009 at 9:45 AM, Ned Deily n...@acm.org wrote:
FIrst attempt was a fat (32-bit i386 and ppc) build on 10.5 targeted for
10.3 and above; this is the similar to recent python.org OSX installers.
What's the proper way to create such a build? I've been trying:
./configure
Okay, I think I might have fixed up the float endianness detection for
universal builds on OS X. Ned, any chance you could give this
another try with an updated version of the py3k-short-float-repr branch?
One thing I don't understand:
Is it true that to produce a working universal/fat build of
On Tue, Apr 14, 2009 at 5:14 PM, Antoine Pitrou solip...@pitrou.net wrote:
If this approach is sane, could it be adopted for all other instances of
endianness detection in the py3k code base?
I think everything else is fine: float endianness detection (for marshal,
pickle, struct) is done at
On Tue, Apr 14, 2009 at 5:49 PM, Antoine Pitrou solip...@pitrou.net wrote:
Mark Dickinson dickinsm at gmail.com writes:
Do you know the right way to create a universal build?
Not at all, sorry.
No problem :). I might try asking on the pythonmac-sig list.
Mark
On Tue, Apr 14, 2009 at 6:55 PM, Martin v. Löwis mar...@v.loewis.de wrote:
The outcome of AC_C_BIGENDIAN isn't used on OSX. Depending on the exact
version you look at, things might work differently; in trunk,
Include/pymacconfig.h should be used [...]
Many thanks---that was the missing piece
On Tue, Apr 14, 2009 at 6:32 PM, Ned Deily n...@acm.org wrote:
The OSX installer script is in Mac/BuildScript/build-installer.py.
For 2-way builds, it essentially does:
export MACOSX_DEPLOYMENT_TARGET=10.3
configure -C --enable-framework
On Fri, Apr 17, 2009 at 3:58 PM, Scott David Daniels
scott.dani...@acm.org wrote:
Non-associativity is what makes for floating point headaches.
To my knowledge, floating point is at least commutative.
Well, mostly. :-)
from decimal import Decimal
x, y = Decimal('NaN123'), Decimal('-NaN456')
On Fri, Apr 24, 2009 at 9:25 PM, Terry Reedy tjre...@udel.edu wrote:
In going through this, I notice a lot of effort by Mark Dickenson and others
Many others, but Eric Smith's name needs to be in big lights here.
There's no way the short float repr would have been ready for 3.1 if
Eric hadn't
I'd like to propose two minor changes to float and complex
formatting, for 3.1. I don't think either change should prove
particularly disruptive.
(1) Currently, '%f' formatting automatically changes to '%g' formatting for
numbers larger than 1e50. For example:
'%f' % 2**166.
The bugs.python.org site seems to be down. ping gives me
the following (from Ireland):
Macintosh-4:py3k dickinsm$ ping bugs.python.org
PING bugs.python.org (88.198.142.26): 56 data bytes
36 bytes from et.2.16.rs3k6.rz5.hetzner.de (213.239.244.101):
Destination Host Unreachable
Vr HL TOS Len
On Sun, Apr 26, 2009 at 4:19 PM, Aahz a...@pythoncraft.com wrote:
On Sun, Apr 26, 2009, Mark Dickinson wrote:
The bugs.python.org site seems to be down.
Dunno -- forwarded to the people who can do something about it. (There's
a migration to a new mailserver going on, but I don't think
On Sun, Apr 26, 2009 at 5:59 PM, Eric Smith e...@trueblade.com wrote:
Mark Dickinson wrote:
I propose changing the complex str and repr to behave like the
float version. That is, repr(4. + 10.j) should be (4.0 + 10.0j)
rather than (4+10j).
I'm +0.5 on this. I'd probably be +1 if I were
On Sun, Apr 26, 2009 at 8:11 PM, Scott David Daniels
scott.dani...@acm.org wrote:
As a user of Idle, I would not like to see the change you seek of
having %f stay full-precision. When a number gets too long to print
on a single line, the wrap depends on the current window width, and
is
On Sun, Apr 26, 2009 at 10:42 PM, Scott David Daniels
scott.dani...@acm.org wrote:
I had also said (without explaining:
only the trailing zeroes with the e, so we wind up with:
1157920892373161954235709850086879078532699846656405640e+23
or
Here's one more proposed change, this time for formatting
of floats using format() and the empty presentation type.
To avoid repeating myself, here's the text from the issue
I just opened:
http://bugs.python.org/issue5864
In all versions of Python from 2.6 up, I get the following behaviour:
On Mon, May 4, 2009 at 10:10 AM, Larry Hastings la...@hastings.org wrote:
So: you don't need it, it clutters up our code (particularly typeobject.c),
and it adds overhead. The only good reason to keep it is backwards
compatibility, which I admit is a fine reason.
Presumably whoever added the
On Mon, May 4, 2009 at 8:11 PM, Daniel Stutzbach
dan...@stutzbachenterprises.com wrote:
If you make the change, will 3rd party code that relies on it fail in
unexpected ways, or will they just get a compile error?
I *think* that third party code that's recompiled for 3.1 and that
doesn't use
On Mon, May 4, 2009 at 9:15 PM, Antoine Pitrou solip...@pitrou.net wrote:
Mark Dickinson dickinsm at gmail.com writes:
I *think* that third party code that's recompiled for 3.1 and that
doesn't use the closure field will either just work, or will produce an
easily-fixed compile error. Larry
On Sat, Aug 1, 2009 at 11:40 PM, Vincent Legollvincent.leg...@gmail.com wrote:
Hello,
I've fed parts of the stdlib to pylint and after some filtering
there appears to be some things that looks strange, I've
filled a few bugs to the tracker for them.
buglist snipped
Is this useless and
Comments on some of the branches I've had involvement with...
On Mon, Aug 3, 2009 at 11:51 AM, Dirkjan Ochtmandirk...@ochtman.nl wrote:
py3k-short-float-repr: strip streamed-merge
Sounds fine.
py3k-issue1717: keep-clone
I don't think there's any need to keep this branch; its contents were
On Sat, Aug 15, 2009 at 8:54 PM, Scott David
Danielsscott.dani...@acm.org wrote:
[...] input to .setstate: old, new-short, and new-long. In trying to
get this to work, I found what might be a bug:
code says
mt[0] = 0x8000UL; /* MSB is 1; assuring non-zero initial array */
but probably
On Mon, Sep 7, 2009 at 11:10 PM, Eric Smithe...@trueblade.com wrote:
Hmm, I never noticed that. At this point, I think changing the formatting
for any types would break code, so we should just change the documentation
to reflect how currently works.
I think the alignment for Decimal *does*
On Fri, Jan 13, 2012 at 2:57 AM, Guido van Rossum gu...@python.org wrote:
How
pathological the data needs to be before the collision counter triggers? I'd
expect *very* pathological.
How pathological do you consider the set
{1 n for n in range(2000)}
to be? What about the set:
On Fri, Jan 13, 2012 at 5:43 PM, Guido van Rossum gu...@python.org wrote:
How pathological do you consider the set
{1 n for n in range(2000)}
to be? What about the set:
ieee754_powers_of_two = {2.0**n for n in range(-1074, 1024)}
? The 2000 elements of the latter set have only 61
On Mon, May 7, 2012 at 12:08 PM, victor.stinner
python-check...@python.org wrote:
http://hg.python.org/cpython/rev/ab500b297900
changeset: 76821:ab500b297900
user: Victor Stinner victor.stin...@gmail.com
date: Mon May 07 13:02:44 2012 +0200
summary:
Issue #14716: Change
On Mon, May 7, 2012 at 12:35 PM, Mark Dickinson dicki...@gmail.com wrote:
will almost always be one less than a power of 2 and powers of 2 are
always congruent to 1, 2 or 4 modulo 5, we're safe.
Bah. That should have read 1, 2, 3 or 4 modulo 5
On Tue, Mar 25, 2008 at 9:46 AM, Oleg Broytmann [EMAIL PROTECTED] wrote:
In 2.5.2 it prints
type 'str'
type 'unicode'
Why the change? Is it a bug or a feature? Shouldn't .to_eng_string()
always return a str?
I'd call this a bug. The change is an accident, a side-effect of the
On Tue, Mar 25, 2008 at 9:46 AM, Oleg Broytmann [EMAIL PROTECTED] wrote:
In 2.5.2 it prints
type 'str'
type 'unicode'
Why the change? Is it a bug or a feature? Shouldn't .to_eng_string()
always return a str?
I'd call this a bug. The change is an accident, a side-effect of the
On Tue, Mar 25, 2008 at 11:29 AM, Nick Coghlan [EMAIL PROTECTED] wrote:
I thought that might be what happened, but I couldn't remember if that
optimisation was a 2.6 only change or not (I suspect it was included in
2.5 as a prereq to the spec compliance updates).
Exactly.
Anyway, +1 on
On Tue, Mar 25, 2008 at 11:29 AM, Nick Coghlan [EMAIL PROTECTED] wrote:
The isinstance(value, str) check in Py3k is too restrictive - it needs
to accept bytes instances as well.
Hmm. There's not a lot of consistency here:
int(b'1')
1
float(b'1')
1.0
complex(b'1')
Traceback (most recent
On Tue, Mar 25, 2008 at 11:57 AM, Facundo Batista [EMAIL PROTECTED]
wrote:
2008/3/25, Mark Dickinson [EMAIL PROTECTED]:
So int and float accepts bytes, while complex, Decimal and Fraction do
not...
I'm -1 to accept bytes as input for Decimal, I don't see a case of
use, and I think
On Wed, Mar 26, 2008 at 2:57 AM, Nick Coghlan [EMAIL PROTECTED] wrote:
Greg Ewing wrote:
I thought Decimal was going to be replaced by a C
implementation soon anyway. If so, is it worth going
to much trouble over this?
I believe that was found to be more trouble than it was worth. So
On Thu, Mar 27, 2008 at 4:46 AM, Georg Brandl [EMAIL PROTECTED] wrote:
As Nick said, a drop-in replacement in C isn't feasible
But probably users of decimal won't really care if they have to slightly
adapt their code if they get the speed increase instead.
We had a SOC student working on
On Sun, Mar 30, 2008 at 5:54 PM, Martin v. Löwis [EMAIL PROTECTED]
wrote:
If you have the time to figure it all out, sure.
I found that quite a tedious task, and had to spent
on some patches quite a long time to figure out what
they do, and what the 3.x equivalent should be.
Is there any
On Sun, Mar 30, 2008 at 6:16 PM, Martin v. Löwis [EMAIL PROTECTED]
wrote:
Is there any easy way that the burden of trunk - py3k
merging could be moved to the original committers of
the trunk patches?
I'm not sure I understand the question. If the committer
of the original patch would do
Hello all,
test_math is currently failing on the Debian/alpha buildbots (trunk and
py3k).
I've been trying, unsuccessfully, to figure out what's going wrong, and I'm
starting to run out of ideas, so I thought I'd ask the list for help to see
if
anyone has any useful suggestions.
Details of the
On Sat, May 31, 2008 at 11:33 AM, Georg Brandl [EMAIL PROTECTED] wrote:
Now that the docs are reST, the source is almost pretty enough to display
it raw, but I could also imagine a text writer that removes the more
obscure markup to present a casual-reader-friendly text version.
The needed
On Sun, Jun 1, 2008 at 2:15 AM, Raymond Hettinger [EMAIL PROTECTED] wrote:
Proposal
Remove non-essential abstract methods like __index__, three argument
__pow__,
__lshift__, __rlshift__, __rshift__, __rrshift__, __and__, __rand__,
__xor__,
__rxor__, __or__, __ror__, and
On Tue, Jun 24, 2008 at 8:05 PM, Guido van Rossum [EMAIL PROTECTED] wrote:
Following the discussion in the issue tracker is really hard (since
most of the discussion apparently refers to earlier versions). I also
don't see any doc changes.
I think there may also still be room for some
1 - 100 of 375 matches
Mail list logo
