[issue1191] bsddb does not build with bsddb lib v3.1.
Gregory P. Smith added the comment: BerkeleyDB 3.3 through 4.5 are supported. 4.6 support has been checked in and 4.7 (not yet released) support is supposedly on its way from someone at oracle. Versions older than 3.3 are too difficult (and too buggy) to support. You're on your own if you want to use them. Yes there are many lines of legacy code in _bsddb.c that have the old 3.1 and 3.2 feature ifdefs. Cleaning them up is very low priority and would just interfere with other peoples patches. They will be cleaned up out of the _bsddb.c module in the python 3000 branch. -- assignee: - gregory.p.smith nosy: +gregory.p.smith resolution: - wont fix status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1191 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue730938] Python bsddb docs need update
Gregory P. Smith added the comment: ReST format docs that cover what is actually implemented and wrapped in python would be good. We need a volunteer willing to go through and do it. -- assignee: gregory.p.smith - nosy: +jcea title: Python 2.3 bsddb docs need update - Python bsddb docs need update Tracker [EMAIL PROTECTED] http://bugs.python.org/issue730938 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1913] test_pep263 fails
New submission from Christian Heimes: $ ./python Lib/test/regrtest.py -v test_pep263 test_pep263 test_compilestring (test.test_pep263.PEP263Test) ... FAIL test_pep263 (test.test_pep263.PEP263Test) ... ok == FAIL: test_compilestring (test.test_pep263.PEP263Test) -- Traceback (most recent call last): File /home/heimes/dev/python/py3k/Lib/test/test_pep263.py, line 25, in test_compilestring AssertionError: '\xc3\xb3' != '\xf3' -- Ran 2 tests in 0.035s FAILED (failures=1) test test_pep263 failed -- Traceback (most recent call last): File /home/heimes/dev/python/py3k/Lib/test/test_pep263.py, line 25, in test_compilestring AssertionError: '\xc3\xb3' != '\xf3' 1 test failed: test_pep263 -- components: Interpreter Core, Tests messages: 61567 nosy: tiran priority: high severity: normal status: open title: test_pep263 fails type: crash versions: Python 3.0 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1913 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1202] zlib.crc32() and adler32() return value
Changes by Gregory P. Smith: -- assignee: - gregory.p.smith keywords: +64bit, easy nosy: +gregory.p.smith priority: - normal versions: +Python 2.6, Python 3.0 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1202 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1223] httplib does not handle ssl end of file properly
Changes by Gregory P. Smith: -- assignee: - janssen __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1223 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1789] incorrect assumption about unsigned long byte size
Gregory P. Smith added the comment: the docs I see in the URL you give are correct as it states 'two and four byte unsigned integer respectively' for H and L. However the example is missing the for little-endian; I'll add that. Also, I notice that the struct module documentation itself incorrectly uses the C terms 'int' and 'long' to assume 32bit and long long when it means 64bit. I'll fix that. -- assignee: - gregory.p.smith keywords: +easy nosy: +gregory.p.smith priority: - normal __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1789 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1223] httplib does not handle ssl end of file properly
Christian Heimes added the comment: I've set version to 2.6 and priority to high so we don't forget it. -- nosy: +tiran priority: - high versions: +Python 2.6 -Python 2.5 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1223 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1789] incorrect assumption about unsigned long byte size
Christopher Yeleighton added the comment:
Python 2.5.1 (r251:54863, Oct 5 2007, 13:50:07)
[GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2
Type help, copyright, credits or license for more information.
import struct
g_f = open('/dev/null')
struct.unpack('L', g_f.read(04))
Traceback (most recent call last):
File stdin, line 1, in module
File /usr/lib/python2.5/struct.py, line 87, in unpack
return o.unpack(s)
struct.error: unpack requires a string argument of length 8
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1789
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1910] Document that with is slower than try/finally
Christian Heimes added the comment: Oh, I didn't know that with is slower than try/finally. It should get documented that try/finally is better suited than with for performance critical code. -- assignee: - georg.brandl components: +Documentation -Library (Lib) keywords: -patch nosy: +georg.brandl status: closed - pending title: _threading_local should use with - Document that with is slower than try/finally __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1910 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1915] Python 2.5.1 compile failed with configure option --enable-unicode=no
New submission from Song Ma: In my platform I have to disable Unicode support in Python 2.5.1. The configure file provided a option --enable-unicode=no to allow me to do so. However, If I ran the configure with that option and then make, the following error showed: Python/ast.c:3168: undefined reference to `PyUnicode_DecodeRawUnicodeEscape' Python/ast.c:3170: undefined reference to `PyUnicode_DecodeUnicodeEscape' collect2: ld returned 1 exit status make: *** [python] Error 1 Python 2.4.4 can be compiled with this option and works well. Since ast.c was newly introduced in 2.5.1. Maybe we need put MACRO Py_USING_UNICODE in ast.c for function decode_unicode(). Otherwise it needs to modify the configure file to forbid --enable-unicode=no. However in ast.c decode_utf8() is using Py_USING_UNICODE to make it pluggable for not supporting utf8. Why not do the same thing for decode_unicode()? -- components: Build, Unicode messages: 61573 nosy: songma severity: urgent status: open title: Python 2.5.1 compile failed with configure option --enable-unicode=no type: compile error versions: Python 2.5 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1915 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1910] Document that with is slower than try/finally
Amaury Forgeot d'Arc added the comment: Raymond, does your comment also apply to change at r60189 ? It is exactly the same thing, in threading.py... OTOH, _threading_local.py is not used by the standard library, except by the dummy_threading module; threading.local normally comes from threadmodule.c. I don't think this module is performance critical. Maybe we can teach good practices there. -- nosy: +amaury.forgeotdarc __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1910 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1910] Document that with is slower than try/finally
Amaury Forgeot d'Arc added the comment: In ceval.c, the case WITH_CLEANUP contains the following lines: /* XXX Not the fastest way to call it... */ x = PyObject_CallFunctionObjArgs(x, u, v, w, NULL); Maybe this is something not too difficult to improve? __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1910 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1915] Python 2.5.1 compile failed with configure option --enable-unicode=no
Christian Heimes added the comment: Python/ast.c has been fixed but more code needs to be fixed: gcc -pthread -c -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -IInclude -I./Include -DPy_BUILD_CORE -o Parser/tokenizer.o Parser/tokenizer.c Parser/tokenizer.c: In function 'decode_str': Parser/tokenizer.c:607: warning: assignment discards qualifiers from pointer target type Parser/tokenizer.c: In function 'dec_utf8': Parser/tokenizer.c:1550: warning: implicit declaration of function 'PyUnicode_DecodeUTF8' Parser/tokenizer.c:1550: warning: initialization makes pointer from integer without a cast Parser/tokenizer.c:1552: warning: implicit declaration of function 'PyUnicode_AsEncodedString' Parser/tokenizer.c:1552: warning: assignment makes pointer from integer without a cast /home/heimes/dev/python/release25-maint/Parser/tokenizer.c:1550: undefined reference to `PyUnicode_DecodeUTF8' /home/heimes/dev/python/release25-maint/Parser/tokenizer.c:1552: undefined reference to `PyUnicode_AsEncodedString' /home/heimes/dev/python/release25-maint/Parser/tokenizer.c:1550: undefined reference to `PyUnicode_DecodeUTF8' /home/heimes/dev/python/release25-maint/Parser/tokenizer.c:1552: undefined reference to `PyUnicode_AsEncodedString' -- components: +Interpreter Core -Unicode nosy: +tiran priority: - high versions: +Python 2.6 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1915 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1916] Add inspect.isgenerator
New submission from Christian Heimes: The inspect module has no function isgenerator. -- components: Documentation, Library (Lib) keywords: easy messages: 61577 nosy: tiran priority: low severity: normal status: open title: Add inspect.isgenerator type: rfe versions: Python 2.6, Python 3.0 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1916 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1767511] SocketServer.DatagramRequestHandler
Ben Bass added the comment: I've just bumped into this issue. In my opinion the finish() method should only do anything if wfile is not empty, i.e: temp = self.wfile.getvalue() if temp: self.socket.sendto(temp, self.client_address) -- nosy: +bpb _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1767511 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1767511] SocketServer.DatagramRequestHandler
Christian Heimes added the comment: Can you provide a working patch with a unit test and doc updates? -- nosy: +tiran type: - behavior versions: +Python 2.6 _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1767511 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1754489] Non-portable address length calculation for AF_UNIX sockets
Armin Rigo added the comment: Checked in as r60214. -- resolution: - accepted status: open - closed _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1754489 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1736] Three bugs of FCICreate (PC/_msi.c)
Hirokazu Yamamoto added the comment: Umm, please forget previous comment. msilib.FCICreate(a * 256 + / + b * 255, []) crashed on debug build. (CB_MAX_CAB_PATH == 256) -- title: Two bugs of FCICreate (PC/_msi.c) - Three bugs of FCICreate (PC/_msi.c) __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1736 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1767511] SocketServer.DatagramRequestHandler
Ben Bass added the comment: Main issue here (as I see it) is that StreamRequestHandler and DatagramRequestHandler should behave in the same way. This is not the case in Python 2.5.1 for the case where the handle method does not respond to the request socket (e.g. in my case it is forwarding data to a different socket). While handler methods in StreamRequestHandler need not send any data back to the request socket, in DatagramRequestHandlers an attempt will be made to send data whether any is available or not. This causes a socket hang (for several minutes) on Windows with a '10040 Message too long' error. By only sending data back to the request if the handler has written to wfile, this is avoided, giving the twin fixes of avoiding a nasty socket error and providing compatibilty with StreamRequestHandler behaviour. Test has been updated to add tests of handlers which do not respond to the request; this causes a hang in Python2.5.1 stock (not sure how to avoid this and cleanly fail), test passes with changed SocketServer. p.s. this is my first patch submission to anything, so go easy :-) Added file: http://bugs.python.org/file9271/DatagramServer.diff _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1767511 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1577] shutil.move() does not use os.rename() if dst is a directory
Antoine Pitrou added the comment:
Before tackling this, I'd like a precision on os.rename(src, dst)
semantics. The documentation says If dst is a directory, OSError will
be raised. However, under Linux, if src is a directory and dst is an
empty directory, dst is overwritten with src:
$ mkdir src dst
$ touch dst/t
$ ./python -c import os; os.rename('src', 'dst')
Traceback (most recent call last):
File string, line 1, in module
OSError: [Errno 39] Directory not empty
$ rm dst/t
$ ./python -c import os; os.rename('src', 'dst')
$
Is this a bug, a misfeature, or just an imprecision in the documentation?
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1577
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1915] Python 2.5.1 compile failed with configure option --enable-unicode=no
Christian Heimes added the comment: I fixed it for Python 2.5 and 2.6. However several extensions and modules don't work w/o unicode support. Please contribute fixes if you need more support. r60215 r60216 -- priority: high - normal resolution: - fixed status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1915 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1577] shutil.move() does not use os.rename() if dst is a directory
Raghuram Devarakonda added the comment: Before tackling this, I'd like a precision on os.rename(src, dst) semantics. The documentation says If dst is a directory, OSError will be raised. However, under Linux, if src is a directory and dst is an empty directory, dst is overwritten with src: I think the doc is incorrect. The rename() man page doesn't explicitly say that destination can not be directory. In fact, a small C program directly calling rename() (on SuSE 10) behaves exactly as your python script. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1577 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1577] shutil.move() does not use os.rename() if dst is a directory
Antoine Pitrou added the comment: Does this mean we should preserve this behaviour for shutil.move() as well? Right now, shutil.move(src_dir, dst_dir) replaces dst_dir with src_dir if dst_dir is empty, but moves src_dir inside dst_dir otherwise. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1577 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1577] shutil.move() does not use os.rename() if dst is a directory
Raghuram Devarakonda added the comment: Does this mean we should preserve this behaviour for shutil.move() as well? I don't think so. The key is to remember that shutil.move() is os.rename() with some additional benefits (as stated by Guido in an earlier comment). Also, changing the behaviour of shutil.move() may break backwards compatibility. I thought this issue has reached a conclusion that all one need is a doc update. Some thing like (copying from my previous comment): If the destination is a fiile and is on same filesystem as that of src, then simply use rename. In fact, even the issue's component has been changed to Documentation. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1577 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1180193] broken pyc files
Antoine Pitrou added the comment: If code objects grew a __module__ attribute (which functions already have), wouldn't it be just a matter of falling back on sys.modules[my_code_object.__module__].__file__ when my_code_object.co_filename points to a non-existent file? -- nosy: +pitrou _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1180193 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1917] init_types() in Parser/asdl_c.py conflicts with init_types() in Modules/_typesmodule.c
New submission from Graeme Smecher:
On a BFLT (microblaze-uclinux) build of vanilla Python 2.5.1, startup
-v produces the following:
# python -v
Could not find platform dependent libraries exec_prefix
Consider setting $PYTHONHOME to prefix[:exec_prefix]
# installing zipimport hook
import zipimport # builtin
# installed zipimport hook
# /usr/local/lib/python2.5/site.pyc has bad mtime
import site # from /usr/local/lib/python2.5/site.py
# can't create /usr/local/lib/python2.5/site.pyc
# /usr/local/lib/python2.5/os.pyc has bad mtime
import os # from /usr/local/lib/python2.5/os.py
# can't create /usr/local/lib/python2.5/os.pyc
import posix # builtin
# /usr/local/lib/python2.5/posixpath.pyc has bad mtime
import posixpath # from /usr/local/lib/python2.5/posixpath.py
# can't create /usr/local/lib/python2.5/posixpath.pyc
# /usr/local/lib/python2.5/stat.pyc has bad mtime
import stat # from /usr/local/lib/python2.5/stat.py
# can't create /usr/local/lib/python2.5/stat.pyc
# /usr/local/lib/python2.5/UserDict.pyc has bad mtime
import UserDict # from /usr/local/lib/python2.5/UserDict.py
# can't create /usr/local/lib/python2.5/UserDict.pyc
# /usr/local/lib/python2.5/copy_reg.pyc has bad mtime
import copy_reg # from /usr/local/lib/python2.5/copy_reg.py
# can't create /usr/local/lib/python2.5/copy_reg.pyc
# /usr/local/lib/python2.5/types.pyc has bad mtime
import types # from /usr/local/lib/python2.5/types.py
# can't create /usr/local/lib/python2.5/types.pyc
import _types # builtin
'import site' failed; traceback:
Traceback (most recent call last):
File /usr/local/lib/python2.5/site.py, line 62, in module
import os
File /usr/local/lib/python2.5/os.py, line 696, in module
import copy_reg as _copy_reg
File /usr/local/lib/python2.5/copy_reg.py, line 7, in module
from types import ClassType as _ClassType
File /usr/local/lib/python2.5/types.py, line 93, in module
import _types
SystemError: _PyImport_FixupExtension: module _types not loaded
# /usr/local/lib/python2.5/warnings.pyc has bad mtime
import warnings # from /usr/local/lib/python2.5/warnings.py
# can't create /usr/local/lib/python2.5/warnings.pyc
# /usr/local/lib/python2.5/types.pyc has bad mtime
import types # from /usr/local/lib/python2.5/types.py
# can't create /usr/local/lib/python2.5/types.pyc
import _types # builtin
import encodings # directory /usr/local/lib/python2.5/encodings
# /usr/local/lib/python2.5/encodings/__init__.pyc has bad mtime
import encodings # from /usr/local/lib/python2.5/encodings/__init__.py
# can't create /usr/local/lib/python2.5/encodings/__init__.pyc
# /usr/local/lib/python2.5/codecs.pyc has bad mtime
import codecs # from /usr/local/lib/python2.5/codecs.py
# can't create /usr/local/lib/python2.5/codecs.pyc
import _codecs # builtin
# /usr/local/lib/python2.5/types.pyc has bad mtime
import types # from /usr/local/lib/python2.5/types.py
# can't create /usr/local/lib/python2.5/types.pyc
import _types # builtin
Python 2.5.1 (r251:54863, Jan 23 2008, 09:07:29)
[GCC 3.4.1 ( PetaLinux 0.20 Build -rc1 050607 )] on linux2
Type help, copyright, credits or license for more information.
This is happening because the autogenerated _PyImport_Inittab in
Modules/config.c (sensibly) contains the following startup definition:
/* This lives in Python/_types.c */
{_types, init_types},
The problem is that two distinct init_types() exist, and the
microblaze-uclinux-gcc toolchain is picking up the wrong one.
On x86 GCC producing ELF binaries, the linker picks up the correct
init_types() defined in Modules/_typesmodule.c. The above behaviour
does not occur, and the interpreter starts up successfully.
On Microblaze GCC producing BFLT binaries, the linker instead picks up
init_types() defined in Python/Python-ast.c, which is autogenerated
from Parser/asdl_c.py.
The obvious fix is to change one of the init_types() to something else.
I suspect this bug is related to Issue 1568243, which has been closed
(apparently a different fix was in order for PCs.) The doubly-defined
init_types() appears to still be present in the Subversion repository.
For reference, my cross-compiler is configured as follows:
$ microblaze-uclinux-gcc -v
Reading specs from
/lhome/gsmecher/petalinux-public/tools/linux-i386/microblaze-uclinux-tools/bin/../lib/gcc/microblaze-uclinux/3.4.1/specs
Configured with:
/home/jwilliams/PetaLogix/petalinux-test/toolchains/microblaze-uclinux/srcs/gcc/configure
--target=microblaze-uclinux
--prefix=/home/jwilliams/PetaLogix/petalinux-test/toolchains/microblaze-uclinux/microblaze-uclinux-tools
--enable-languages=c,c++ --enable-multilib --enable-target-optspace
--with-gnu-ld --disable-nls --disable-__cxa_atexit --disable-c99
--disable-clocale --disable-c-mbchar --disable-long-long
--enable-threads=posix
[issue1913] test_pep263 fails
Georg Brandl added the comment: Fixed in r60220. -- nosy: +georg.brandl resolution: - fixed status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1913 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1069410] import on Windows: please call SetErrorMode first
Christian Heimes added the comment: Applied in 60221 -- resolution: - fixed status: open - closed _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1069410 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1789] incorrect assumption about unsigned long byte size
Gregory P. Smith added the comment: eew, so the struct module does map as documented to the C types listed in the docs. yuck. regardless, changing the Ls to Is will fix the tutorial document code. I'll do that. I believe there are also other instances of wrong uses of L in struct in the code such as the zipfile module that will fail on LP64 platforms. I'll look for those (and why they weren't caught by unit tests). __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1789 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue618633] sys.execpthook not used in threads
Raghuram Devarakonda added the comment: This is a duplicate of a more recently opened #1230540. -- nosy: +draghuram resolution: - duplicate status: open - closed Tracker [EMAIL PROTECTED] http://bugs.python.org/issue618633 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1722225] Build on QNX 6
Matt Kraai added the comment:
If they're defined, TCGETA, TCSETA, TCSETAW, and TCSETAF are used on
lines 702, 714, 717, and 720 of Modules/termios.c as of r60219. They
are defined by sys/ioctl.h as
#define TCGETA _IOR('T', 1, struct termio)
#define TCSETA _IOW('T', 2, struct termio)
#define TCSETAW _IOW('T', 3, struct termio)
#define TCSETAF _IOW('T', 4, struct termio)
These macro definitions expand to
( 0x4000 | (( sizeof( struct termio ) 0x3fff ) 16) | ((
( 'T' ) ) 8) | ( ( 1 ) ))
( 0x8000 | (( sizeof( struct termio ) 0x3fff ) 16) | ((
( 'T' ) ) 8) | ( ( 2 ) ))
( 0x8000 | (( sizeof( struct termio ) 0x3fff ) 16) | ((
( 'T' ) ) 8) | ( ( 3 ) ))
( 0x8000 | (( sizeof( struct termio ) 0x3fff ) 16) | ((
( 'T' ) ) 8) | ( ( 4 ) ))
respectively, so struct termio must be declared if any of these macros
are used. struct termio is declared in sys/termio.h. Since
sys/termio.h isn't included, Modules/termios.c fails to compile with the
following error messages:
/home/m_kraai/src/python/Modules/termios.c:702: sizeof applied to an
incomplete type
/home/m_kraai/src/python/Modules/termios.c:714: sizeof applied to an
incomplete type
/home/m_kraai/src/python/Modules/termios.c:717: sizeof applied to an
incomplete type
/home/m_kraai/src/python/Modules/termios.c:720: sizeof applied to an
incomplete type
sys/termio.h checks that it's included before termios.h is first
included. If it's not included first, it produces the following error
message:
/usr/qnx630/target/qnx6/usr/include/sys/termio.h:109: #error
termio/termios incompatibility
What should configure test for?
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue175
_
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1568] PATCH: Armin's attribute lookup caching for 3.0
Neil Toronto added the comment: There's nothing it tests that standard unit tests don't, so it shouldn't stick around as a unit test. I used it to time different types of attribute lookups and left it in as an optimization aid. The main test groups are '.' access, successful hasattr (returns True), and failing hasattr (returns False). For each group it prints a header and then four test cases for each test class: metaclass attribute access (class.__class__), class attribute access (class.__init__), class attribute access via an instance (class().__class__), and instance attribute access (class().__init__). The test classes include a few built-ins and the classes of a made-up deep hierarchy. The main thing to notice is that, when you run this using the patched source, every number is no larger than when you run it using the trunk, and most are smaller. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1568 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1917] init_types() in Parser/asdl_c.py conflicts with init_types() in Modules/_typesmodule.c
Christian Heimes added the comment: The compiler should not pick up the init_types function in Python/Python-ast.c. It's declared as static. The init_types function in Modules/_typesmodule.c is declared as extern so that's the real deal. It sounds more like a compiler or linker bug in the tool chain than a Python bug. -- nosy: +tiran priority: - normal __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1917 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1918] weak references are removed before __del__ is called.
New submission from Jeff Foran: Not sure where to put example code, but here it goes: import weakref class MyObj(object): def __init__(self): self.ref = weakref.ref(self) def __del__(self): print HERE123, self.ref() o = MyObj() o = None -- components: Interpreter Core messages: 61597 nosy: jforan severity: normal status: open title: weak references are removed before __del__ is called. type: behavior versions: Python 2.5 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1918 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1917] init_types() in Parser/asdl_c.py conflicts with init_types() in Modules/_typesmodule.c
Graeme Smecher added the comment: Hm, sorry for the static -- you're absolutely correct, this has to be a compiler/linker/elf2flt bug. I'll patch my build instead of whining here. Thanks -- Feel free to close the report. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1917 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1917] init_types() in Parser/asdl_c.py conflicts with init_types() in Modules/_typesmodule.c
Changes by Brett Cannon: -- resolution: - invalid status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1917 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1745035] DoS smtpd vulnerability
Giampaolo Rodola' added the comment: I update this bug as GvR requested here: http://groups.google.it/group/python-dev2/browse_thread/thread/33cad7b7c1cdb19f?hl=it The patch in attachment fixes what discussed before. In addition it sets a smaller timeout for asyncore.loop() for permitting to stop the daemon via KeyboardInterrupt immediately. -- versions: +Python 2.5 Added file: http://bugs.python.org/file9272/smtpd.diff _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1745035 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1736190] asyncore/asynchat patches
Changes by Giampaolo Rodola': -- severity: normal - urgent type: - security versions: +Python 2.5 _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1736190 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1736190] asyncore/asynchat patches
Changes by Giampaolo Rodola': -- severity: urgent - normal type: security - versions: +Python 2.6 -Python 2.5 _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1736190 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1918] weak references are removed before __del__ is called.
Christian Heimes added the comment: The behavior is documented in the C code. I don't know how it is described in the docs. Objects/typeobject.c around line 820 says: /* If we added a weaklist, we clear it. Do this *before* calling the finalizer (__del__), clearing slots, or clearing the instance dict. */ -- nosy: +tiran priority: - normal resolution: - wont fix status: open - pending __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1918 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1789] incorrect assumption about unsigned long byte size
Gregory P. Smith added the comment: The documentation for the struct module says: short is 2 bytes; int and long are 4 bytes; long long (__int64 on Windows) is 8 bytes and lists 'l' and 'L' as the pack code for a C long. As it is implemented today, the documentation is incorrect. On an LP64 host (pretty much any 64-bit linux, bsd or unixish OS; not windows) a long is 8 bytes. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1789 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1303614] Bypassing __dict__ readonlyness
Guido van Rossum added the comment: Reopening, since test67.py still causes a segfault in the trunk. It is represented as Lib/test/crashers/loosing_dict_ref.py [sic]. -- nosy: +gvanrossum priority: normal - urgent status: closed - open _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1303614 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1918] weak references are removed before __del__ is called.
Guido van Rossum added the comment: Georg, can you update the docs? Weak references *to* an object are cleared before the object's __del__ is called, to ensure that the weak reference callback (if any) finds the object healthy. -- assignee: - georg.brandl nosy: +georg.brandl, gvanrossum status: pending - open versions: +Python 2.6, Python 3.0 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1918 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1722225] Build on QNX 6
Matt Kraai added the comment: This patch contains two improvements over the previous version: * it uses configure to check whether sys/termio.h is available and uses the result to determine whether to include it and * it makes malloc_closure.c use _SC_PAGESIZE instead of getpagesize if it's available. I believe there are two unresolved issues at this point, the wchar_t definition and the stack size. [n]curses.h defines wchar_t if _XOPEN_SOURCE_EXTENDED is defined and if _WCHAR_T is not defined: #ifdef _XOPEN_SOURCE_EXTENDED #ifndef _WCHAR_T typedef unsigned long wchar_t; #endif /* _WCHAR_T */ #ifndef _WINT_T typedef long int wint_t; #endif /* _WINT_T */ stdlib.h defines wchar_t if __WCHAR_T is defined: #if defined(__WCHAR_T) typedef __WCHAR_T wchar_t; #undef __WCHAR_T #endif I'm afraid I don't quite understand what configure should test for in this case either. Please help! Regarding the stack size, how can I test whether 2MiB is sufficient for the default recursion limit? Added file: http://bugs.python.org/file9273/patch _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue175 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1577] shutil.move() does not use os.rename() if dst is a directory
Guido van Rossum added the comment:
Before tackling this, I'd like a precision on os.rename(src, dst)
semantics. The documentation says If dst is a directory, OSError will
be raised. However, under Linux, if src is a directory and dst is an
empty directory, dst is overwritten with src:
$ mkdir src dst
$ touch dst/t
$ ./python -c import os; os.rename('src', 'dst')
Traceback (most recent call last):
File string, line 1, in module
OSError: [Errno 39] Directory not empty
$ rm dst/t
$ ./python -c import os; os.rename('src', 'dst')
$
Is this a bug, a misfeature, or just an imprecision in the documentation?
To be honest, I wasn't aware of this behavior of the rename() system
call for directories on Unix. It is most certainly a feature (of the
system call) that should be maintained (for the system call wrapper).
shutil.move() should not mimic this though -- it should more closely
approximate the mv utility's behavior, which doesn't differentiate
between empty and non-empty destination directories, and always moves
*into* the target when it is a directory (and complains if the
resulting destination path already exists).
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1577
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1917] init_types() in Parser/asdl_c.py conflicts with init_types() in Modules/_typesmodule.c
Guido van Rossum added the comment: The comment in config.c is wrong. If you still have a Python/_typesmodule.c file, something's wrong on your end! -- nosy: +gvanrossum __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1917 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1917] init_types() in Parser/asdl_c.py conflicts with init_types() in Modules/_typesmodule.c
Graeme Smecher added the comment:
Hi Guido,
Yup! From the tarball (Python-2.5.1.tgz), the actual comment (in
Modules/config.c.in) reads:
/* This lives in Python/_types.c */
{_types, init_types},
...which is different from the snippet I posted here (I hand-reverted my
modifications, but got the comment wrong), but still incorrect (should
be Modules/_types.c.)
cheers,
Graeme
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1917
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1303614] Bypassing __dict__ readonlyness
Guido van Rossum added the comment: Here's a better fix, which also fixes the similar code path in GenericSetAttr(). As a bonus, I reviewed all uses of _PyObject_GetDictPtr() and found one questionable place where the dict at *dictptr was DECREF'ed before that location was set to NULL. I think we're better off setting it to NULL and *then* DECREF'ing the dict. -- resolution: fixed - versions: +Python 2.5, Python 2.6 _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1303614 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1303614] Bypassing __dict__ readonlyness
Changes by Guido van Rossum: Added file: http://bugs.python.org/file9275/deldict.diff _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1303614 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1303614] Bypassing __dict__ readonlyness
Changes by Guido van Rossum: Removed file: http://bugs.python.org/file9274/deldict.diff _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1303614 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1789] assumption about unsigned long byte size in struct module usage
Gregory P. Smith added the comment: A significant portion of the python standard library is broken due to incorrect use of the struct module on LP64 platforms. I'm attaching a patch that should clean it up. I need Mac OS X people to confirm that the Mac changes are sane. Its possible that the Lib/posixfile.py change could be a candidate for a 2.4 security backport if it turns out the _posixfile_.lock() implementation is indeed broken when a 64bit python is used on some platforms. I'll leave that up to the 2.4 releaser to decide. -- components: +Library (Lib) keywords: +64bit, patch -easy priority: normal - high severity: normal - major title: incorrect assumption about unsigned long byte size - assumption about unsigned long byte size in struct module usage versions: +Python 2.4, Python 2.5, Python 2.6 Added file: http://bugs.python.org/file9276/struct-long-nuke-01.diff __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1789 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1303614] Bypassing __dict__ readonlyness
Changes by Neal Norwitz: -- nosy: +nnorwitz _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1303614 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1743] IDLE fails to launch
Kurt B. Kaiser added the comment: Thanks for the fix. r60225. -- resolution: - fixed status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1743 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1862] Error on Save As in IDLE (Vista 32-bit)
Kurt B. Kaiser added the comment: r60225. Dup of Issue 1743. -- resolution: - fixed status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1862 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1789] assumption about unsigned long byte size in struct module usage
Changes by Georg Brandl: -- priority: high - urgent __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1789 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1794] Hot keys must work in any keyboard layout
Changes by Kurt B. Kaiser: __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1794 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1794] Hot keys must work in any keyboard layout
Changes by Kurt B. Kaiser: -- components: -IDLE __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1794 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1599] IDLE hangs if os.spwanv command is given
Changes by Kurt B. Kaiser: Removed file: http://bugs.python.org/file9032/unnamed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1599 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1599] IDLE hangs if os.spwanv command is given
Kurt B. Kaiser added the comment: Does it fail for foo.py: def foo(): pass import os os.spawnv(os.P_NOWAIT, 'foo.py', '') 5026 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1599 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1647] IDLE messes around with sys.exitfunc
Kurt B. Kaiser added the comment: And yet some people were seeing this error. I was not, on Linux, and I don't know why. Fixed at r60227. -- resolution: works for me - fixed versions: -Python 3.0 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1647 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1303614] Bypassing __dict__ readonlyness
Guido van Rossum added the comment: The more i think about it, I don't think the issue in typeobject.c can ever occur, so I'm skipping that part of the fix. _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1303614 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1303614] Bypassing __dict__ readonlyness
Changes by Adam Olsen: -- nosy: +Rhamphoryncus _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1303614 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1910] Document that with is slower than try/finally
Benjamin Peterson added the comment: Most platforms use the faster thread.LockType. Correct? Perhaps, since this module is more a reference implementation and it is pointed to by the threading docs (http://docs.python.org/lib/module-threading.html), we should elect to take the more pythonic route on this. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1910 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1910] Document that with is slower than try/finally
Raymond Hettinger added the comment: Generally we don't document the speed differences between various alternatives. One reason is that relative performance varies across releases and platforms. Another reason is that the rule in this case is somewhat generic (inlined code is typically faster than making a call to the same code without in-lining. Us developers are supposed to know that sort of thing or time it if we don't. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1910 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1910] Document that with is slower than try/finally
Raymond Hettinger added the comment: Amaury, please do revert 60189. There is no reason to destabalize this code, slow it down, and introduce new dependencies. Use of the with-statement is not in and of itself a best practice. Where it really shines is in factoring-away repeated setup/teardown code. Modules that serve as elemental building blocks (like threading, Queue, heapq, etc) need to have fast, clean code with as few dependencies as possible. Also, we should change/modernize something like asyncore or threading with a great deal of care and restraint. It is too easy to introduce hard to find bugs in this code. It took a long time for this code to stabalize and we should enjoy the benefits of its maturity. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1910 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1303614] Bypassing __dict__ readonlyness
Neal Norwitz added the comment: I looked at Guido's latest deldict.diff patch--the one to Objects/object.c only. It seems good. I can't convince myself either way about the change to Objects/typeobject.c. I can't think of a way to cause a problem. It seems safer to use Py_CLEAR in this case though. There are several other uses of _PyObject_GetDictPtr in Objects/typeobject.c. It was pretty much the same--I can't convince myself either way. Can Py_VISIT cause any Python code to execute that might lead to a problem? The other uses of _PyObject_GetDictPtr in Objects/typeobject.c seemed safer. Not a very useful review. _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1303614 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1617] Rare exception in test_urllib2net
Neal Norwitz added the comment: This started happening consistently on my box and I was able to reproduce it. Revision 60233 should fix this problem. I forwarded the checkin to Greg. Hopefully he can comment if there is a problem. (Also cc'd him on this bug report that I'm now closing.) -- assignee: - nnorwitz nosy: +gregory.p.smith resolution: - fixed status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1617 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
