Re: [Python-Dev] Complexity documentation request
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 of specific operations. > > http://en.wikipedia.org/wiki/Amortized_analysis > Thanks for this, I understand now what it means. However given that for the list and deque types both columns have exactly the same values, wouldn't it be more useful if we simply mentioned the worst case in the second, or another, column? 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). Thanks, Dimitris ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] The Case Against Floating Point ==
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 point numbers with ==. If you want to check floating point equality, you usually decide on a precision, and check either the absolute error, or the relative error. Another option is to use the decimal module. Hence, floating point == isn’t used, maybe except for rare circumstances. I would even venture to say that when possible, static checkers should emit warnings on floating point ==. On the other hand there are the beginner programmers. They usually use == by mistake, and will be surprised by the strange results they sometimes get back. 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 string suggesting using precision comparison, or the decimal module. Since this change is not backwards compatible, I suggest it be added only to Python 3. Personally, I prefer the second option (== to raise an exception). It is clearer, and less confusing. Arguments against this suggestion are: 1. This change breaks existing programs: I believe it most likely triggers hidden bugs. Since the suggestion is to change it only in Python 3, Those programs will most likely be broken by other changes as well, and will need to be changed anyway. 2. This change breaks compatibility with C-like languages: I agree. However, the already agreed on change of the / operator is even a stronger break. Most arguments for changing the / operator apply here as well. 3. Programmers will still need the regular ==: Maybe, and even then, only for very rare cases. For these, a special function\method might be used, which could be named floating_exact_eq. I tried looking up other material about this subject, and while there is plenty of material about how to do floating point code right, I didn't find any suggestion similar to this one. I also wrote this suggestion at my blog, and discussed it a little bit on #python. I'll be glad to read other peoples' thoughts on this. Cheers, Imri -- - Imri Goldberg www.algorithm.co.il/blogs www.imri.co.il - Insert Signature Here - ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Complexity documentation request
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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Why .index() is not a method of all sequence types ?
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 little difference in > | the interpreter's code, if .index() would be a method of any sequence, > | mutable or not. Such a small difference, that this minor change wouldn't > | deserve a PEP. > > I believe .index() is part of the 3.0 sequence protocol and hence has been > added to tuples for 3.0. Don't know if has been or will be backported to > 2.6. Python 2.6a1+ (trunk:61289M, Mar 7 2008, 19:45:46) [GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> 'index' in dir(tuple) True Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Complexity documentation request
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, with some neat ideas to make the best-case O(n). I just made the word "Sort" into a hyperlink, pointing to the link that Duncan Booth pointed out in another response. -- Daniel Stutzbach, Ph.D. President, Stutzbach Enterprises LLC ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The Case Against Floating Point ==
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 string > suggesting using precision comparison, or the decimal module. This is an interesting idea, but python-dev is the wrong place. You should probably start with python-ideas, then move to c.l.python, then finally bring it up on python-3000. But in any event, it probably doesn't matter: it's too late. Although we have not released a beta, we are far along the alpha cycle and this is too big a change. Remember that Python 3.0 is scheduled to have final release in August. -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "All problems in computer science can be solved by another level of indirection." --Butler Lampson ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The Case Against Floating Point ==
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 exception, with an error string > suggesting using precision comparison, or the decimal module. > I don't much like either of these; I think option 1 would cause a lot of confusion and difficulty---it changes a conceptually simple operation into something more complicated. As for option 2., I'd agree that there are situations where having a warning (not an exception) for floating-point equality (and inequality) tests might be helpful; but that warning should be off by default, or at least easily turned off. Some Fortran compilers have such a (compile-time) warning, I believe. But Fortran's users are much more likely to be writing the sort of code that cares about this. > Since this change is not backwards compatible, I suggest it be added > only to Python 3. > It's already too late for Python 3.0. > > 3. Programmers will still need the regular ==: > Maybe, and even then, only for very rare cases. For these, a special > function\method might be used, which could be named floating_exact_eq. > I disagree with the 'very rare' here. I've seen, and written, code like: if a == 0.0: # deal with exceptional case else: b = c/a ... or similarly, a test (a==b) before doing a division by a-b. That one's kind of dodgy, by the way: a != b doesn't always guarantee that a-b is nonzero, though you're okay if you're on an IEEE 754 platform and a and b are both finite numbers. Or what if you wanted to generate random numbers in the open interval (0.0, 1.0). random.random gives you numbers in [0.0, 1.0), so a careful programmer might well write: while True: x = random.random() if x != 0.0: break (A less fussy programmer might just say that the chance of getting 0.0 is about 1 in 2**53, so it's never going to happen...) Other thoughts: - what should x == x do? - what should 1.0 in set([0.0, 1.0, 2.0]) and 3.0 in set([0.0, 1.0, 2.0]) do? Mark ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] How best to handle test_errno?
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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] How best to handle test_errno?
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 all the values; is that really true? > > -Brett Half-answering your email.. ENOTOBACCO is missing here, Linux. -- -- Guilherme H. Polo Goncalves ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The Case Against Floating Point ==
"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 change is the idea that expressions involving integral values should, insofar as possible, have the same value result regardless of the types used to carry the input (or output) values. Hence 1/2 should equal 1.0/2.0 == .5. The idea that 1 == 1 and 1.0 == 1.0 should give a different answer goes against this principle and the 2.x project of number unification. tjr ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Windows x64 & bsddb 4.4.20 woes
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, I'll deal
with that in a separate thread or roundup issue).
Unfortunately, though, we're back to more bsddb issues. I got about 15 tests
in without error before test_whichdb ran, which results in the following being
called in dbhash.py:
return bsddb.hashopen(file, flag, mode)
I can trace that call to DBEnv_open() in _bsddb.c:
static PyObject*
DBEnv_open(DBEnvObject* self, PyObject* args)
{
int err, flags=0, mode=0660;
char *db_home;
if (!PyArg_ParseTuple(args, "z|ii:open", &db_home, &flags, &mode))
return NULL;
CHECK_ENV_NOT_CLOSED(self);
MYDB_BEGIN_ALLOW_THREADS;
err = self->db_env->open(self->db_env, db_home, flags, mode);
^
Placing a breakpoint at the line above and stepping in results in Visual Studio
reporting: " A buffer overrun has occurred in python_d.exe which has corrupted
the program's internal state. Press Break to debug the program or Continue to
terminate the program.". FWIW, the exception is being raised as part of the
/GS buffer overflow checks (implemented in gs_result.c, which is provided in my
VS9 installation).
This has been annoyingly awkward to debug. I can't break down that call into
multiple steps in order to try place breakpoints in the db_static module. The
callstack isn't that useful either:
_bsddb_d.pyd!__crt_debugger_hook()
_bsddb_d.pyd!__report_gsfailure(unsigned __int64 StackCookie=2211040)
_bsddb_d.pyd!__GSHandlerCheckCommon(void * EstablisherFrame=0x0021bce0,
...)
_bsddb_d.pyd!__GSHandlerCheck(_EXCEPTION_RECORD *
ExceptionRecord=0x0021bbc0, ...)
ntdll.dll!773ae13d()
[Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]
ntdll.dll!773aea57()
ntdll.dll!773b59f8()
_bsddb_d.pyd!__os_strdup() + 0x18 bytes
_bsddb_d.pyd!__os_tmpdir() + 0x281 bytes
You'd think placing breakpoints in db 4.4.20's __os_strdup and __os_tmpdir
methods would do something, but alas, the bufferoverflow exception is raised
before any breakpoints are set. This makes me suspect there's something funky
going on with the entire build and linking of db_static (VS should honour those
breakpoints if the code is being entered, I even added db_static to pcbuild.sln
and rebuilt but no dice). I've noticed that they're not using consistent
compiler flags by default (we use /GS, they use /GS-, we allow function level
linking, they don't -- note that I did change db_static's options to align with
_bsddb's but the bufferoverflow exception is still being thrown).
Greg, Jesús, I'm CC'ing you guys as stfw'ing seems to bring back you two the
most when it comes to bsddb issues. I've still got a list of things to try
with regarding to debugging this x64 issue, but I wanted to reach out now to
see if anyone else had encountered it before. Has bsddb ever been built
successfully on Win64 and passed all tests or am I venturing into new ground?
Martin, you've changed externals/bsddb-4.4.20 with regards to x64 builds
recently -- have you been able to get things working in your x64 environments?
Regards,
Trent.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.5.1 error when running cvs2svn [SEC=UNCLASSIFIED]
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 that libz.so is not found. Either rebuild Python using the -R flag to hard-code the location of various low-level libraries in Python's .so files or set LD_LIBRARY_PATH at runtime so the dynamic linker can find them. One other thing (well, two). python-dev@python.org is not the correct place for these sorts of questions. Try [EMAIL PROTECTED] instead. Also, note that many of us who might read this are at PyCon (http://us.pycon.org/) which starts this morning and continues through the middle of next week. Response rates from this list will be reduced. -- Skip Montanaro - [EMAIL PROTECTED] - http://www.webfast.com/~skip/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Windows x64 & bsddb 4.4.20 woes
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
BerkeleyDB (though it sounds like you may have tried that already?). Next
off in the debugging i'd take a look at the assembly to see what exactly it
was failing to do.
If you're at PyCon right now we should meet up and try to figure it out (I
just arrived).
On 3/13/08, Trent Nelson <[EMAIL PROTECTED]> wrote:
>
> 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,
> I'll deal with that in a separate thread or roundup issue).
>
> Unfortunately, though, we're back to more bsddb issues. I got about 15
> tests in without error before test_whichdb ran, which results in the
> following being called in dbhash.py:
>
> return bsddb.hashopen(file, flag, mode)
>
> I can trace that call to DBEnv_open() in _bsddb.c:
>
> static PyObject*
> DBEnv_open(DBEnvObject* self, PyObject* args)
> {
> int err, flags=0, mode=0660;
> char *db_home;
>
> if (!PyArg_ParseTuple(args, "z|ii:open", &db_home, &flags, &mode))
> return NULL;
>
> CHECK_ENV_NOT_CLOSED(self);
>
> MYDB_BEGIN_ALLOW_THREADS;
> err = self->db_env->open(self->db_env, db_home, flags, mode);
> ^
>
> Placing a breakpoint at the line above and stepping in results in Visual
> Studio reporting: " A buffer overrun has occurred in python_d.exe which has
> corrupted the program's internal state. Press Break to debug the program or
> Continue to terminate the program.". FWIW, the exception is being raised as
> part of the /GS buffer overflow checks (implemented in gs_result.c, which is
> provided in my VS9 installation).
>
> This has been annoyingly awkward to debug. I can't break down that call
> into multiple steps in order to try place breakpoints in the db_static
> module. The callstack isn't that useful either:
>
> _bsddb_d.pyd!__crt_debugger_hook()
> _bsddb_d.pyd!__report_gsfailure(unsigned __int64 StackCookie=2211040)
> _bsddb_d.pyd!__GSHandlerCheckCommon(void *
> EstablisherFrame=0x0021bce0, ...)
> _bsddb_d.pyd!__GSHandlerCheck(_EXCEPTION_RECORD *
> ExceptionRecord=0x0021bbc0, ...)
> ntdll.dll!773ae13d()
> [Frames below may be incorrect and/or missing, no symbols loaded for
> ntdll.dll]
> ntdll.dll!773aea57()
> ntdll.dll!773b59f8()
> _bsddb_d.pyd!__os_strdup() + 0x18 bytes
> _bsddb_d.pyd!__os_tmpdir() + 0x281 bytes
>
> You'd think placing breakpoints in db 4.4.20's __os_strdup and __os_tmpdir
> methods would do something, but alas, the bufferoverflow exception is raised
> before any breakpoints are set. This makes me suspect there's something
> funky going on with the entire build and linking of db_static (VS should
> honour those breakpoints if the code is being entered, I even added
> db_static to pcbuild.sln and rebuilt but no dice). I've noticed that
> they're not using consistent compiler flags by default (we use /GS, they use
> /GS-, we allow function level linking, they don't -- note that I did change
> db_static's options to align with _bsddb's but the bufferoverflow exception
> is still being thrown).
>
> Greg, Jesús, I'm CC'ing you guys as stfw'ing seems to bring back you two
> the most when it comes to bsddb issues. I've still got a list of things to
> try with regarding to debugging this x64 issue, but I wanted to reach out
> now to see if anyone else had encountered it before. Has bsddb ever been
> built successfully on Win64 and passed all tests or am I venturing into new
> ground?
>
> Martin, you've changed externals/bsddb-4.4.20 with regards to x64 builds
> recently -- have you been able to get things working in your x64
> environments?
>
> Regards,
>
>
> Trent.
>
>
>
>
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Windows x64 & bsddb 4.4.20 woes
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 newer versions? Martin/Jesus, any thoughts on this?
Regarding the db_static build and conflicting compile/link options -- I'm going
to bring the db_static source directly into the _bsddb project (for now) which
should make this a lot easier to debug.
Trent.
From: Gregory P. Smith [EMAIL PROTECTED]
Sent: 13 March 2008 22:00
To: Trent Nelson
Cc: python-dev@python.org; Jesus Cea
Subject: Re: Windows x64 & bsddb 4.4.20 woes
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 BerkeleyDB
(though it sounds like you may have tried that already?). Next off in the
debugging i'd take a look at the assembly to see what exactly it was failing to
do.
If you're at PyCon right now we should meet up and try to figure it out (I just
arrived).
On 3/13/08, Trent Nelson <[EMAIL PROTECTED]> wrote:
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, I'll deal
with that in a separate thread or roundup issue).
Unfortunately, though, we're back to more bsddb issues. I got about 15 tests
in without error before test_whichdb ran, which results in the following being
called in dbhash.py:
return bsddb.hashopen(file, flag, mode)
I can trace that call to DBEnv_open() in _bsddb.c:
static PyObject*
DBEnv_open(DBEnvObject* self, PyObject* args)
{
int err, flags=0, mode=0660;
char *db_home;
if (!PyArg_ParseTuple(args, "z|ii:open", &db_home, &flags, &mode))
return NULL;
CHECK_ENV_NOT_CLOSED(self);
MYDB_BEGIN_ALLOW_THREADS;
err = self->db_env->open(self->db_env, db_home, flags, mode);
^
Placing a breakpoint at the line above and stepping in results in Visual Studio
reporting: " A buffer overrun has occurred in python_d.exe which has corrupted
the program's internal state. Press Break to debug the program or Continue to
terminate the program.". FWIW, the exception is being raised as part of the
/GS buffer overflow checks (implemented in gs_result.c, which is provided in my
VS9 installation).
This has been annoyingly awkward to debug. I can't break down that call into
multiple steps in order to try place breakpoints in the db_static module. The
callstack isn't that useful either:
_bsddb_d.pyd!__crt_debugger_hook()
_bsddb_d.pyd!__report_gsfailure(unsigned __int64 StackCookie=2211040)
_bsddb_d.pyd!__GSHandlerCheckCommon(void * EstablisherFrame=0x0021bce0,
...)
_bsddb_d.pyd!__GSHandlerCheck(_EXCEPTION_RECORD *
ExceptionRecord=0x0021bbc0, ...)
ntdll.dll!773ae13d()
[Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]
ntdll.dll!773aea57()
ntdll.dll!773b59f8()
_bsddb_d.pyd!__os_strdup() + 0x18 bytes
_bsddb_d.pyd!__os_tmpdir() + 0x281 bytes
You'd think placing breakpoints in db 4.4.20's __os_strdup and __os_tmpdir
methods would do something, but alas, the bufferoverflow exception is raised
before any breakpoints are set. This makes me suspect there's something funky
going on with the entire build and linking of db_static (VS should honour those
breakpoints if the code is being entered, I even added db_static to pcbuild.sln
and rebuilt but no dice). I've noticed that they're not using consistent
compiler flags by default (we use /GS, they use /GS-, we allow function level
linking, they don't -- note that I did change db_static's options to align with
_bsddb's but the bufferoverflow exception is still being thrown).
Greg, Jesús, I'm CC'ing you guys as stfw'ing seems to bring back you two the
most when it comes to bsddb issues. I've still got a list of things to try
with regarding to debugging this x64 issue, but I wanted to reach out now to
see if anyone else had encountered it before. Has bsddb ever been built
successfully on Win64 and passed all tests or am I venturing into new ground?
Martin, you've changed externals/bsddb-4.4.20 with regards to x64 builds
recently -- have you been able to get things working in your x64 environments?
Regards,
Trent.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/ma
Re: [Python-Dev] The Case Against Floating Point ==
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:[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 change is the idea that expressions > involving integral values should, insofar as possible, have the same value > result regardless of the types used to carry the input (or output) values. > Hence 1/2 should equal 1.0/2.0 == .5. The idea that 1 == 1 and 1.0 == 1.0 > should give a different answer goes against this principle and the 2.x > project of number unification. > > tjr > > > > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/tiagoaoa%40cos.ufrj.br > > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Windows x64 & bsddb 4.4.20 woes
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 4.4.20 (or 4.4.x?) for 2.6/3.0 or is it
> worth investigating newer versions? Martin/Jesus, any thoughts on this?
>
Python 2.6/3.0 should be built on Windows using BerkeleyDB 4.5.x for now.
4.6.x is out but has some bugs on some platforms so i don't recommend
shipping our release using it; 4.7.x is in beta and some bugs are being
worked on; if its out and shows no signs of obvious issues before the 2.6/3.0
beta period is over I recommend we build our binary releases using it.
Otherwise 4.5 it will be. There is no reason to use 4.4.x.
Regarding the db_static build and conflicting compile/link options -- I'm
> going to bring the db_static source directly into the _bsddb project (for
> now) which should make this a lot easier to debug.
>
> Trent.
>
>
> From: Gregory P. Smith [EMAIL PROTECTED]
> Sent: 13 March 2008 22:00
> To: Trent Nelson
> Cc: python-dev@python.org; Jesus Cea
> Subject: Re: Windows x64 & bsddb 4.4.20 woes
>
>
>
> 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
> BerkeleyDB (though it sounds like you may have tried that already?). Next
> off in the debugging i'd take a look at the assembly to see what exactly it
> was failing to do.
>
> If you're at PyCon right now we should meet up and try to figure it out (I
> just arrived).
>
>
> On 3/13/08, Trent Nelson <[EMAIL PROTECTED]> wrote:
> 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,
> I'll deal with that in a separate thread or roundup issue).
>
> Unfortunately, though, we're back to more bsddb issues. I got about 15
> tests in without error before test_whichdb ran, which results in the
> following being called in dbhash.py:
>
> return bsddb.hashopen(file, flag, mode)
>
> I can trace that call to DBEnv_open() in _bsddb.c:
>
> static PyObject*
> DBEnv_open(DBEnvObject* self, PyObject* args)
> {
> int err, flags=0, mode=0660;
> char *db_home;
>
> if (!PyArg_ParseTuple(args, "z|ii:open", &db_home, &flags, &mode))
> return NULL;
>
> CHECK_ENV_NOT_CLOSED(self);
>
> MYDB_BEGIN_ALLOW_THREADS;
> err = self->db_env->open(self->db_env, db_home, flags, mode);
> ^
>
> Placing a breakpoint at the line above and stepping in results in Visual
> Studio reporting: " A buffer overrun has occurred in python_d.exe which has
> corrupted the program's internal state. Press Break to debug the program or
> Continue to terminate the program.". FWIW, the exception is being raised as
> part of the /GS buffer overflow checks (implemented in gs_result.c, which is
> provided in my VS9 installation).
>
> This has been annoyingly awkward to debug. I can't break down that call
> into multiple steps in order to try place breakpoints in the db_static
> module. The callstack isn't that useful either:
>
> _bsddb_d.pyd!__crt_debugger_hook()
> _bsddb_d.pyd!__report_gsfailure(unsigned __int64 StackCookie=2211040)
> _bsddb_d.pyd!__GSHandlerCheckCommon(void *
> EstablisherFrame=0x0021bce0, ...)
> _bsddb_d.pyd!__GSHandlerCheck(_EXCEPTION_RECORD *
> ExceptionRecord=0x0021bbc0, ...)
> ntdll.dll!773ae13d()
> [Frames below may be incorrect and/or missing, no symbols loaded for
> ntdll.dll]
> ntdll.dll!773aea57()
> ntdll.dll!773b59f8()
> _bsddb_d.pyd!__os_strdup() + 0x18 bytes
> _bsddb_d.pyd!__os_tmpdir() + 0x281 bytes
>
> You'd think placing breakpoints in db 4.4.20's __os_strdup and __os_tmpdir
> methods would do something, but alas, the bufferoverflow exception is raised
> before any breakpoints are set. This makes me suspect there's something
> funky going on with the entire build and linking of db_static (VS should
> honour those breakpoints if the code is being entered, I even added
> db_static to pcbuild.sln and rebuilt but no dice). I've noticed that
> they're not using consistent compiler flags by default (we use /GS, they use
> /GS-, we allow function level linking, they don't -- note that I did change
> db_static's options to align with _bsddb's but the bufferoverflow exception
> is still being thrown).
>
> Greg, Jesús, I'm CC'ing you guys as stfw'ing seems to bring back you two
> the most when it comes to bsddb issues. I've st
Re: [Python-Dev] Windows x64 & bsddb 4.4.20 woes
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, considering that this approach (i.e. bringing their source
files into our build instead of linking against a static lib compiled with
wildly incompatible flags) only took me about two minutes to implement and
immediately fixed every bsddb problem I was encoutering, I'm convinced it's the
right way to go. (I can separate the dependencies easily enough.)
Woeful PyCon/hotel connectivity is preventing me from getting to
bugs.python.org at the moment; I'll raise a ticket later to capture this stuff
and we can move the discussion there once I've attached some patches.
Trent.
From: Gregory P. Smith [EMAIL PROTECTED]
Sent: 14 March 2008 00:23
To: Trent Nelson
Cc: python-dev@python.org; Jesus Cea
Subject: Re: Windows x64 & bsddb 4.4.20 woes
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 4.4.20 (or 4.4.x?) for 2.6/3.0 or is it worth
investigating newer versions? Martin/Jesus, any thoughts on this?
Python 2.6/3.0 should be built on Windows using BerkeleyDB 4.5.x for now.
4.6.x is out but has some bugs on some platforms so i don't recommend shipping
our release using it; 4.7.x is in beta and some bugs are being worked on; if
its out and shows no signs of obvious issues before the 2.6/3.0 beta period is
over I recommend we build our binary releases using it. Otherwise 4.5 it will
be. There is no reason to use 4.4.x.
Regarding the db_static build and conflicting compile/link options -- I'm going
to bring the db_static source directly into the _bsddb project (for now) which
should make this a lot easier to debug.
Trent.
From: Gregory P. Smith [EMAIL PROTECTED]
Sent: 13 March 2008 22:00
To: Trent Nelson
Cc: python-dev@python.org; Jesus Cea
Subject: Re: Windows x64 & bsddb 4.4.20 woes
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 BerkeleyDB
(though it sounds like you may have tried that already?). Next off in the
debugging i'd take a look at the assembly to see what exactly it was failing to
do.
If you're at PyCon right now we should meet up and try to figure it out (I just
arrived).
On 3/13/08, Trent Nelson <[EMAIL PROTECTED]> wrote:
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, I'll deal
with that in a separate thread or roundup issue).
Unfortunately, though, we're back to more bsddb issues. I got about 15 tests
in without error before test_whichdb ran, which results in the following being
called in dbhash.py:
return bsddb.hashopen(file, flag, mode)
I can trace that call to DBEnv_open() in _bsddb.c:
static PyObject*
DBEnv_open(DBEnvObject* self, PyObject* args)
{
int err, flags=0, mode=0660;
char *db_home;
if (!PyArg_ParseTuple(args, "z|ii:open", &db_home, &flags, &mode))
return NULL;
CHECK_ENV_NOT_CLOSED(self);
MYDB_BEGIN_ALLOW_THREADS;
err = self->db_env->open(self->db_env, db_home, flags, mode);
^
Placing a breakpoint at the line above and stepping in results in Visual Studio
reporting: " A buffer overrun has occurred in python_d.exe which has corrupted
the program's internal state. Press Break to debug the program or Continue to
terminate the program.". FWIW, the exception is being raised as part of the
/GS buffer overflow checks (implemented in gs_result.c, which is provided in my
VS9 installation).
This has been annoyingly awkward to debug. I can't break down that call into
multiple steps in order to try place breakpoints in the db_static module. The
callstack isn't that useful either:
_bsddb_d.pyd!__crt_debugger_hook()
_bsddb_d.pyd!__report_gsfailure(unsigned __int64 StackCookie=2211040)
_bsddb_d.pyd!__GSHandlerCheckCommon(void * EstablisherFrame=0x0021bce0,
...)
_bsddb_d.pyd!__GSHandlerCheck(_EXCEPTION_RECORD *
ExceptionRecord=0x0021bbc0, ...)
ntdll.dll!773ae13d()
[Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]
ntdll.dll!773aea57()
ntdll.dll!000
