Ah, and to think I just fixed 4.4.20 ;-)
Removing the dependency on db_static.vcproj and merging the relevant source
code files into _bsddb.vcproj did the trick -- all x64 bsddb-related tests now
pass. The only issue with this approach is that it locks _bsddb.vcproj into
4.4.20. However, con
On 3/13/08, Trent Nelson <[EMAIL PROTECTED]> wrote:
>
> Hey Greg,
>
> I'm at PyCon indeed, staying through the sprints 'til next Thursday. I'll
> drop you a note offline re catching up.
>
> The other query I had was whether or not I should try a later version of
> BerkeleyDB -- are we committed to
I would suggest something like a ~= b, for "approximately equal to". How
approximately? Well, there would be a default that could be changed
somewhere.
Don't know if it's all that useful, though.
Tiago A.O.A.
Terry Reedy escreveu:
> "Imri Goldberg" <[EMAIL PROTECTED]> wrote in message
> news
Hey Greg,
I'm at PyCon indeed, staying through the sprints 'til next Thursday. I'll drop
you a note offline re catching up.
The other query I had was whether or not I should try a later version of
BerkeleyDB -- are we committed to 4.4.20 (or 4.4.x?) for 2.6/3.0 or is it worth
investigating ne
I haven't built the bsddb stuff on windows myself in a few years and have
never had access to a windows x64 system so I'm no silver bullet. Making
the BerkeleyDB compile and link options match with those of python is the
first place I'd start. Also you should be able to make a debug build of
Berk
Paul> import zlib
Paul> ImportError: ld.so.1: python: fatal: relocation error: file
Paul> /usr/local/lib/python2.5/lib-dynload/zlib.so: symbol inflateCopy:
Paul> referenced symbol not found
Paul,
Try running
ldd /usr/local/lib/python2.5/lib-dynload/zlib.so
I'll wager
I've been trying to give the Windows x64 builds a bit of TLC the past few
evenings. I managed to get a successful build with all external modules last
night (Tcl/Tk required about a half a dozen code/configuration changes each in
order to build in a Windows x64 environment with Visual Studio 9,
"Imri Goldberg" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| Most experienced programmers know that you shouldn't compare floating
| point numbers with ==.
As a general statement, this is wrong. Mark gave examples.
Please drop the proposal.
The reason for the int division chan
2008/3/13, Brett Cannon <[EMAIL PROTECTED]>:
> I am going through my backlog of GHOP work and noticed that test_errno
> is essentially a no-op at the moment. I was wondering if anyone knew
> if there are any guaranteed values for the errno module? If not, the
> test current says that Linux has a
I am going through my backlog of GHOP work and noticed that test_errno
is essentially a no-op at the moment. I was wondering if anyone knew
if there are any guaranteed values for the errno module? If not, the
test current says that Linux has all the values; is that really true?
-Brett
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 Thu, Mar 13, 2008, Imri Goldberg 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 exception, with an error str
On Thu, Mar 13, 2008 at 3:16 AM, Dimitrios Apostolou <[EMAIL PROTECTED]> wrote:
> On another note which sorting algorithm is python using? Perhaps we can
> add this as a footnote. I always thought it was quicksort, with a worst
> case of O(n^2).
It's a highly optimized variant of mergesort, wit
Terry Reedy wrote:
> "Joost Behrends" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> | With such a tuple tp i tried 'ix = tp.index(...)' recently and was
> | astonished to learn, that this doesn't work. Since we have '... in tp'
> | for me it seems, that it should make very li
Dimitrios Apostolou <[EMAIL PROTECTED]> wrote:
> On another note which sorting algorithm is python using? Perhaps we can
> add this as a footnote. I always thought it was quicksort, with a worst
> case of O(n^2).
See http://svn.python.org/projects/python/trunk/Objects/listsort.txt
Heya
I've been using Python for development for some years now, but up until
now, I didn't participate much in work on Python itself. I've decided to
'take a shot at it', even if a small one at first.
To the subject at hand:
Most experienced programmers know that you shouldn’t compare floating
Daniel Stutzbach wrote:
> On Wed, Mar 12, 2008 at 2:52 PM, Dimitrios Apostolou <[EMAIL PROTECTED]>
> wrote:
>> Just one quick note. What exactly do you mean by "Amortized worst case"?
>> Shouldn't it just be "Worst case"? I think that the word "amortized"
>> better describes the time complexity
17 matches
Mail list logo
