[Python-Dev] Win64, 64 Bit Version and 32 Bit version parallel install not possible
Hello, I tried to install the 64 Bit python version (2.5.1) and the 32 Bit version on my computer. But it is not possible because the installer complains that this version of python is already installed. Is it in general not possible to install both versions (in separate directories) ? Or is it a bug ? Wolfgang ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] new metaclass error condition checks
On 4/17/07, Jean-Paul Calderone <[EMAIL PROTECTED]> wrote: I just noticed r53997 (from some unit tests it broke), which disallowed things like this: class X(object): def __repr__(self): return "blah" class Y(X, type): pass class Z: __metaclass__ = Y Making X classic eliminates the TypeError, and is probably an acceptable fix in a lot of cases (at least as long as classic classes are available). I wonder if the ability to override type special methods like this was considered when the change was made, though? Probably not, or at least not consciously. I think the point is that 'type' and its subclasses are special enough that this warrants a separate 'X' that inherits from 'type' rather than 'object'. Reduced reusability, but how badly does this affect you in the real world, really? -- Thomas Wouters <[EMAIL PROTECTED]> Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] FW: static analysis of python source
I just ran some static analysis of the python core 2.5 with Visual Studio team
system.
There was the stray error discovered. I will update the most obvious ones.
Some questions, though:
This code in binascii.c, line 1168 (and again 1238) is wrong:
while (in < datalen) {
if ((data[in] > 126) ||
(data[in] == '=') ||
(header && data[in] == '_') ||
((data[in] == '.') && (linelen == 1)) ||
(!istext && ((data[in] == '\r') || (data[in] == '\n'))) ||
((data[in] == '\t' || data[in] == ' ') && (in + 1 == datalen))
||
((data[in] < 33) &&
(data[in] != '\r') && (data[in] != '\n') &&
(quotetabs && ((data[in] != '\t') || (data[in] != ' ')
The final ((data[in] != '\t') || (data[in] != ' ')) is always true. What
is the right form? ((data[in] == '\t') || (data[in] == ' ')) ?
1)
2) There is a lot of code that goes like this:
f->buf = PyMem_Realloc(f->buf, newsize);
if (!f->buf)
return PyErr_NoMemory(), 0;
Now, this if Realloc fails, this causes a memory leak. Is there any interest
to fix this flawed pattern wholesale?
Cheers,
Kristjan
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Deallocation of a pointer not malloced, any tips?
I get this warning from my test suite when I introduced a segment of code: python(18603,0xa000d000) malloc: *** Deallocation of a pointer not malloced: 0x310caa3; This could be a double free(), or free() called with the middle of an allocated block; Try setting environment variable MallocHelp to see tools to help debug Always the same warning; sometimes it even segfaults python, but rarely. I only see it on Mac OS X (two separate machines), python 2.4.3 both built from source via Darwin Ports. The same suite gives no such warning on a 2.4.3 production machine running Free BSD. I know what segment of code causes it but can't for the life of me think of writing it a different way in this specific application. In a nutshell, it's two sets of two nested try blocks (try, try, except, except * 2) where the inner except can re-raise a new exception if a rescue function wants to. it sounds convoluted because it is! :( I tried really hard recreating it in a test case outside of my application but of course there is something too deeply buried that I can't catch. I turned on MallocHelp but just stared blankly at heaps and stack options. Is there anything I can switch on that would be helpful to anyone who might be interested in this problem? :) I also wanted to put out some feelers in case it sounds like something that is fixed elsewhere (I'm having trouble running my existing suite in 2.5 due to setuptools not working and me not having enough time to fiddle with it). Sorry if this is all very vague, I'm just a bit stumped and wanted to see if anyone had some suggestions. -Kumar ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] static analysis of python source
I just ran some static analysis of the python core 2.5 with Visual Studio team
system.
There was the stray error discovered. I will update the most obvious ones.
Some questions, though:
This code in binascii.c, line 1168 (and again 1238) is wrong:
while (in < datalen) {
if ((data[in] > 126) ||
(data[in] == '=') ||
(header && data[in] == '_') ||
((data[in] == '.') && (linelen == 1)) ||
(!istext && ((data[in] == '\r') || (data[in] == '\n'))) ||
((data[in] == '\t' || data[in] == ' ') && (in + 1 == datalen))
||
((data[in] < 33) &&
(data[in] != '\r') && (data[in] != '\n') &&
(quotetabs && ((data[in] != '\t') || (data[in] != ' ')
The final ((data[in] != '\t') || (data[in] != ' ')) is always true. What
is the right form? ((data[in] == '\t') || (data[in] == ' ')) ?
1)
2) There is a lot of code that goes like this:
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Deallocation of a pointer not malloced, any tips?
"Kumar McMillan" <[EMAIL PROTECTED]> wrote: > I get this warning from my test suite when I introduced a segment of code: > > python(18603,0xa000d000) malloc: *** Deallocation of a pointer not > malloced: 0x310caa3; This could be a double free(), or free() called > with the middle of an allocated block; Try setting environment > variable MallocHelp to see tools to help debug [snip] > Sorry if this is all very vague, I'm just a bit stumped and wanted to > see if anyone had some suggestions. You may want the python-list mailing list or the equivalent comp.lang.python newsgroup, unless this is a bug with Python itself (you may try running Python 2.4.4, which is the next bugfix of the Python 2.4 series). Regardless, you can help those who want to help you by providing the code that you have written that causes the error. A doubly nested try/except isn't all that exciting, so I would guess many would be surprised that you are getting double free errors. - Josiah ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] FW: static analysis of python source
Kristján Valur Jónsson <[EMAIL PROTECTED]> wrote: > > I just ran some static analysis of the python core 2.5 with Visual Studio > team system. > There was the stray error discovered. I will update the most obvious ones. [snip] > 2) There is a lot of code that goes like this: > f->buf = PyMem_Realloc(f->buf, newsize); > if (!f->buf) > return PyErr_NoMemory(), 0; > Now, this if Realloc fails, this causes a memory leak. Is there any > interest to fix this flawed pattern wholesale? I believe the idea is that if you run into a MemoryError, in particular on linux (whose allocator will give you a nonzero pointer well beyond what was actually available), you can't really trust the state of the interpreter, so it is expected that Python will be ending shortly. Forcing the leak (leaving the code as-is) basically encourages the interpreter to have more and more errors before the expected, possibly inevitable (and perhaps desireable) quitting of the Python interpreter. - Josiah ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Fwd: AMD64 version of Python
>From Walter Beck <[EMAIL PROTECTED]> to webmaster: >I tried to install the AMD64 version of python on my new laptop, Vista >system. The installer said the processor was not correct. My processor >is a Turion64x2. 32 bit Python installed and ran fine. Is there a bug >in the installer or doesn't it like Vista or is this the wrong ADM64? Can anyone help him out? --amk ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Deallocation of a pointer not malloced, any tips?
Kumar> Always the same warning; sometimes it even segfaults python, but Kumar> rarely. I only see it on Mac OS X (two separate machines), python Kumar> 2.4.3 both built from source via Darwin Ports. The same suite gives no Kumar> such warning on a 2.4.3 production machine running Free BSD. In addition to Josiah's response I will note that the warning you get is specific to the Mac's malloc implementation (or maybe more generally to Darwin or *BSD). It's not necessarily that the problem doesn't occur on other platforms, just that the malloc implementation doesn't include that sort of check by default. Kumar> I turned on MallocHelp but just stared blankly at heaps and stack Kumar> options. I've used that stuff but it's been awhile. Try "man malloc" in a terminal window. If that doesn't get you going post your questions [EMAIL PROTECTED] mailing list. That's were most of the Mac-head Python developers hang out. Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] .dll import
I was surprised when 2.5 stopped importing our custom modules. So, I found this in dyload_win.c: /* Temporarily disable .dll, to avoid conflicts between sqlite3.dll and the sqlite3 package. If this needs to be reverted for 2.5, some other solution for the naming conflict must be found. This temporary fix seems to have been forgotten. Isn't it time it was fixed back? K ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Win64, 64 Bit Version and 32 Bit version parallel install not possible
> I tried to install the 64 Bit python version (2.5.1) and the 32 Bit > version on my computer. > But it is not possible because the installer complains that this > version of python is already installed. > > Is it in general not possible to install both versions (in separate > directories) ? > > Or is it a bug ? It's not possible, because they use the same program GUID. You can use an MSI editor to change the program GUID, then you should be able to install them simultaneously (you may have to change the UpgradeCode as well, as otherwise installing one might silently uninstall the other). Of course, both installations will stomp on each other's registry keys, so while this MSI conflict is not deliberate (I never considered that setup), it may be a good thing that it already breaks at installation time. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] FW: static analysis of python source
> I believe the idea is that if you run into a MemoryError, in particular > on linux (whose allocator will give you a nonzero pointer well beyond > what was actually available), you can't really trust the state of the > interpreter, so it is expected that Python will be ending shortly. > Forcing the leak (leaving the code as-is) basically encourages the > interpreter to have more and more errors before the expected, possibly > inevitable (and perhaps desireable) quitting of the Python interpreter. I don't think that this is the intention (and if it is, I think this intention is flawed). If you really need to shut down ASAP, you should exit(), not raise an exception. Raising MemoryError will exit soon enough, anyway. So I don't think the leak is a good thing - but I don't think it is a bad thing, either, since the code is essentially dead (i.e. it is fairly unlikely that it ever triggers). Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: AMD64 version of Python
>>From Walter Beck <[EMAIL PROTECTED]> to webmaster: > >> I tried to install the AMD64 version of python on my new laptop, Vista >> system. The installer said the processor was not correct. My processor >> is a Turion64x2. 32 bit Python installed and ran fine. Is there a bug >> in the installer or doesn't it like Vista or is this the wrong ADM64? Walter, Most likely, there is indeed a problem with your system installation. You likely have the 32-bit (x86) version of Vista installed, not the x64 version. On the 32-bit windows, the AMD64 mode of the processor is not available, and 64-bit windows binaries cannot run on that system. HTH, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] .dll import
> /* Temporarily disable .dll, to avoid conflicts between sqlite3.dll > > and the sqlite3 package. If this needs to be reverted for 2.5, > > some other solution for the naming conflict must be found. > > > > This temporary fix seems to have been forgotten. Isn‘t it time it was > fixed back? It's time to remove the comment. The removal of .dll extensions for extension modules is now permanent. It hasn't caused too many problems, and no alternative solution to the sqlite3.dll problem has been implemented. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] New decimal branch - news and status
Ok, I cut a branch in svn to work with decimal.py (decimal-branch).
I commited the work I made during the last weeks. Right now, the state
is:
- All the operations that already existed pass ok the new tests (except
``power``). For this, I fixed some bugs, reordered some code (without changing
functionality), and made only one important change (see below).
- The ``power`` operation has been redefined to allow raising a number to a
non-integral power, that's why the old code does not pass the new tests.
- These are the new operations (see the spec for info about them, but basically
you have the logarithmic ones, and a lot that work with Decimal like a binary
number): and, class, compare-total, compare-total-magnitude, copy, copy-abs,
copy-negate, copy-sign, exp, fused-multiply-add, invert, ln, log10, logb,
max-magnitude, min-magnitude, next-minus, next-plus, next-toward, or, rotate,
scaleb, shift, to-integral-exact, trim, xor. Note that these names are from the
spec, not the definitive ones.
- Worked a bit in test_decimal, to make it a bit more debug-friendly: now, you
can call it with the name of the test(s) you want to execute, and it will only
execute that(those) test(s), and will *not* execute the doctests (normally, I
have "print"s in the code, so doctests will always fail). Also, you can call it
with --debug, and it will show the test number, and context, before executing
each test.
*Important change:* Added a "P" value to the valid exponents. See this test
(with a precision of 5 in the context), for example::
maxx670 max 11 -sNaN12345678901 -> -NaN78901 Invalid_operation
This is translated to something like::
Decimal('11').max(Decimal('-sNaN12345678901'))
Doing ``Decimal('-sNaN12345678901')`` must signal InvalidOperation, because the
payload has more digits that the context, and we can signal it through
ConversionSyntax or InvalidOperation itself.
ConversionSyntax must return a quiet NaN. In this case, the max operation will
return the number, and it's not the desired result in this case.
InvalidOperation must return a quiet NaN also, with the original sign, and an
optional diagnostic information.
The ``max`` operation, so, will always receive a quiet NaN, but it *must* know
that it was before signaled. And it must know it from the diagnostic
information.
So far, for diagnostic information we used the Decimal._int digits, because
that was all that was needed. I think it's more clear to leave there the
payload digits, and not make that structure more complex, and create the new
exponent.
"P" is from "phantom" signal, because for everybody asking self._isnan(), it
will return 1 (quiet NaN). But if you want to look at it in more detail, you
will now that in a past life, it was signaled...
Any help is greatly appreciated.
Thank you very much!
Regards,
--
. Facundo
.
Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
