[ python-Bugs-1569790 ] mailbox.Maildir.get_folder() loses factory information
Bugs item #1569790, was opened at 2006-10-03 10:16
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569790&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: mailbox.Maildir.get_folder() loses factory information
Initial Comment:
[forwarded from http://bugs.debian.org/384512]
the factory defines what class the mails have that are
returned.
So for two nested folders a and a.b, the following code
will return
messages with two different classes:
# factory = None to get mailbox.MaildirMessage objects
md = mailbox.Maildir("a", factory=None)
print md["somemessage"].__class__
# will print mailbox.MaildirMessage
md2 = md.get_folder("b")
print md2["someothermessage"].__class__
# will print rfc822.Message
i.e. the factory= parameter passed to the outer Maildir
class upon
creation is not passed on to the subfolder creation in
get_folder()
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569790&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1484556 ] Output of KlocWork on Python2.4.3 sources
Bugs item #1484556, was opened at 2006-05-09 13:14 Message generated for change (Comment added) made by tebeka You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1484556&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Neal Norwitz (nnorwitz) Summary: Output of KlocWork on Python2.4.3 sources Initial Comment: We're evaluating KlocWork (http://www.klocwork.com), I've ran it on the source of Python 2.4.3 and the output is attached (1562 warnings). -- >Comment By: Miki Tebeka (tebeka) Date: 2006-10-03 10:24 Message: Logged In: YES user_id=358087 I don't know, currently KlocWork is way down in my "todo" list :( Looks like I won't be able to continue in this matter any longer, if anyone else want to give a hand ... Miki -- Comment By: Georg Brandl (gbrandl) Date: 2006-09-30 14:34 Message: Logged In: YES user_id=849994 Have all KlocWork issues been fixed now, Neal? -- Comment By: Miki Tebeka (tebeka) Date: 2006-06-04 12:53 Message: Logged In: YES user_id=358087 I'll try to see if I can sneak it in, can't promise anything though -- Comment By: A.M. Kuchling (akuchling) Date: 2006-05-31 17:26 Message: Logged In: YES user_id=11375 The Coverity scans also probably report some of the same bugs, so many of these problems may be fixed in the 2.5 trunk. If you're still evaluating, you could try running the tool on the 2.5 trunk (snapshot available from http://svn.python.org/snapshots/) and see if the results are shorter. -- Comment By: Martin v. Löwis (loewis) Date: 2006-05-10 07:45 Message: Logged In: YES user_id=21627 Thanks for these results. Unfortunately, they seem to contain many false positives, so it is unclear how one should proceed with them. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1484556&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1521947 ] possible bug in mystrtol.c with recent gcc
Bugs item #1521947, was opened at 2006-07-13 17:39
Message generated for change (Comment added) made by arigo
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521947&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Marien Zwart (marienz)
Assigned to: Nobody/Anonymous (nobody)
Summary: possible bug in mystrtol.c with recent gcc
Initial Comment:
python 2.5b2 compiled with gentoo's gcc 4.1.1 and -O2
fails test_unary_minus in test_compile.py. Some
investigating showed that the -ftree-vrp pass of that
gcc (implied by -O2) optimizes out the "result ==
-result" test on line 215 of PyOS_strtol, meaning
PyOS_strtol of the most negative long will incorrectly
overflow.
Python deals with this in this case by constructing a
python long object instead of a python int object, so
at least in this case the problem is not serious. I
have no idea if there is a case where this is a "real"
problem.
At first I reported this as a gentoo compiler bug, but
got the reply that:
"""
I'm pretty sure it's broken. -LONG_MIN overflows when
LONG_MIN < -LONG_MAX, and in standard C as well as "GNU
C", behaviour after overflow on signed integer
operations is undefined.
"""
(see https://bugs.gentoo.org/show_bug.cgi?id=140133)
So now I'm reporting this here. There seems to be a
LONG_MIN constant in limits.h here that could checked
against instead, but I have absolutely no idea how
standard that is. Or this could be a compiler bug after
all, in which case I would appreciate information I Can
use to back that up :)
--
>Comment By: Armin Rigo (arigo)
Date: 2006-10-03 10:10
Message:
Logged In: YES
user_id=4771
Based on the other bug I guess that casting an arbitrary
long to unsigned long is allowed. If so, then maybe we could
use the following test:
if (sign == '-' && uresult == 0-(unsigned long)LONG_MIN) {
result = LONG_MIN;
}
which states the intention a bit more clearly and without the
assert().
--
Comment By: Tim Peters (tim_one)
Date: 2006-09-05 05:21
Message:
Logged In: YES
user_id=31435
Well, I deliberately avoided using LONG_MIN in the patches
for the other bug, so that should answer your question ;-)
If someone wants to take the small risk of backporting it,
fine by me -- it's not going to break on Windows, and if it
doesn't break on your box either ...
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2006-09-05 05:12
Message:
Logged In: YES
user_id=33168
Tim, how do you feel about backporting now? (Not sure if
your opinion changed based on the other bug.) That and I'm
cleaning out my mailbox, so I don't have to look at this any
more. :-)
--
Comment By: Tim Peters (tim_one)
Date: 2006-07-27 21:00
Message:
Logged In: YES
user_id=31435
Neal, as I said in the checkin comment, I expect it's no
less likely that we'll get screwed by goofy platform values
for LONG_MIN and LONG_MAX than that we /got/ screwed by an
"over ambitious" compiler optimizing away "result ==
-result", so I'm not sure backporting is a good idea. I
stuck in an assert that might fail if a platform is insane;
if there are no reports of that assert triggering, then I'd
feel better about backporting the change.
--
Comment By: Matt Fleming (splitscreen)
Date: 2006-07-27 10:49
Message:
Logged In: YES
user_id=1126061
Fixed for me on NetBSD -current AMD64, gcc 4.1.2
--
Comment By: Nick Maclaren (nmm)
Date: 2006-07-27 08:31
Message:
Logged In: YES
user_id=42444
Fixed for me, too, and the code looks solid.
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-27 04:48
Message:
Logged In: YES
user_id=33168
I reopened this bug as it still affects 2.4. Tim's fix
should be backported.
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-27 04:35
Message:
Logged In: YES
user_id=33168
Tim's fix corrected the problem on amd64 gentoo linux with
gcc 4.1.1.
--
Comment By: Tim Peters (tim_one)
Date: 2006-07-27 01:16
Message:
Logged In: YES
user_id=31435
Made a non-heroic effort to repair this in rev 50855, but
have no platform on which it could make any difference (and
apparently no Python buildbot test platform cares either) .
Would be nice if someone
[ python-Bugs-1545668 ] gcc trunk (4.2) exposes a signed integer overflows
Bugs item #1545668, was opened at 2006-08-24 03:14 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545668&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 9 Submitted By: Jack Howarth (jwhowarth) >Assigned to: Armin Rigo (arigo) Summary: gcc trunk (4.2) exposes a signed integer overflows Initial Comment: While building python 2.4.3 with the current gcc trunk (soon to be 4.2), I uncovered a signed integer overflows bug in Python with the help of one of the gcc developers. The bug I observed is documented in this gcc mailing list message... http://gcc.gnu.org/ml/gcc/2006-08/msg00436.html The gcc developer comments about its origin are in the messages... http://gcc.gnu.org/ml/gcc/2006-08/msg00434.html http://gcc.gnu.org/ml/gcc/2006-08/msg00442.html which in short says... It *is* a bug in python, here is the proof: https://codespeak.net/viewvc/vendor/cpython/Python-r243/dist/src/ Objects/intobject.c?revision=25647&view=markup Function * i_divmod*(*register* *long* x, *register* *long* y, the following lines: //* (-sys.maxint-1)/-1 is the only overflow case. *// *if* (y == -1 && x < 0 && x == -x) *return* DIVMOD_OVERFLOW; If overflow is barred then x==-x may happen only when x==0. This conflicts with x<0, which means that the compiler may assume that x<0 && x==-x always yields false. This may allow the compiler to eliminate the whole if statement. Hence, clearly python is at fault. -- >Comment By: Armin Rigo (arigo) Date: 2006-10-03 10:17 Message: Logged In: YES user_id=4771 I'd like to review this in 2.4/2.5/trunk before the 2.4.4 release. Debian "testing" ships with everything compiled with the faulty gcc -- even though this gcc is not released yet! I hate Debian's policies. "Fixing" 2.4.4 would help me a bit to get a reasonable Python installation on Debian machines where I have to log to (assuming the sysadmin knew he had to fish 72 small packages to get just a complete stdlib, that is, but that's another matter). -- Comment By: Armin Rigo (arigo) Date: 2006-09-16 11:28 Message: Logged In: YES user_id=4771 More of the same kind of problem: abs(-sys.maxint-1) sometimes gives -sys.maxint-1. It would be a good idea to review all places that need to special-case -sys.maxint-1 for overflow detection. (It would be a still better idea to review all overflow detection code, but that may have to wait after the 2.5 release). -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-05 04:04 Message: Logged In: YES user_id=33168 Tim checked in fixes for 2.6 (r51716), 2.5 (r51711), and 2.4. -- Comment By: David Hopwood (dhopwood) Date: 2006-08-26 23:24 Message: Logged In: YES user_id=634468 The correct patch is the one that uses if (y == -1 && x < 0 && (unsigned long)x == -(unsigned long)x) The one that uses (unsigned int)x will break some 64-bit platforms where int != long. -- Comment By: Tim Peters (tim_one) Date: 2006-08-26 20:33 Message: Logged In: YES user_id=31435 Boosted priority to 8 since it was brought up on python-dev as a suggested 2.5 release-blocker. The patch in the first comment looks fine, if a release manager wants to apply it. Python 2.4 surely has the same "issue". -- Comment By: Tim Peters (tim_one) Date: 2006-08-26 20:25 Message: Logged In: YES user_id=31435 Looks like the same deal as bug 1521947 (which was about similar code in PyOS_strtol()). -- Comment By: Jack Howarth (jwhowarth) Date: 2006-08-24 15:22 Message: Logged In: YES user_id=403009 Everyone involved in reviewing this patch should definitely read the following sequence of gcc mailing list messages which show the process by which this patch was arrived at... http://gcc.gnu.org/ml/gcc/2006-08/msg00434.html http://gcc.gnu.org/ml/gcc/2006-08/msg00436.html http://gcc.gnu.org/ml/gcc/2006-08/msg00437.html http://gcc.gnu.org/ml/gcc/2006-08/msg00443.html http://gcc.gnu.org/ml/gcc/2006-08/msg00446.html http://gcc.gnu.org/ml/gcc/2006-08/msg00447.html http://gcc.gnu.org/ml/gcc/2006-08/msg00449.html So we have had lots of gcc developer eyes on this problem and they all agree on the flaw and the fix as posted. It's unfortunate that I had to abuse their mailing list to get thi
[ python-Bugs-1521947 ] possible bug in mystrtol.c with recent gcc
Bugs item #1521947, was opened at 2006-07-13 13:39
Message generated for change (Comment added) made by tim_one
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521947&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Marien Zwart (marienz)
Assigned to: Nobody/Anonymous (nobody)
Summary: possible bug in mystrtol.c with recent gcc
Initial Comment:
python 2.5b2 compiled with gentoo's gcc 4.1.1 and -O2
fails test_unary_minus in test_compile.py. Some
investigating showed that the -ftree-vrp pass of that
gcc (implied by -O2) optimizes out the "result ==
-result" test on line 215 of PyOS_strtol, meaning
PyOS_strtol of the most negative long will incorrectly
overflow.
Python deals with this in this case by constructing a
python long object instead of a python int object, so
at least in this case the problem is not serious. I
have no idea if there is a case where this is a "real"
problem.
At first I reported this as a gentoo compiler bug, but
got the reply that:
"""
I'm pretty sure it's broken. -LONG_MIN overflows when
LONG_MIN < -LONG_MAX, and in standard C as well as "GNU
C", behaviour after overflow on signed integer
operations is undefined.
"""
(see https://bugs.gentoo.org/show_bug.cgi?id=140133)
So now I'm reporting this here. There seems to be a
LONG_MIN constant in limits.h here that could checked
against instead, but I have absolutely no idea how
standard that is. Or this could be a compiler bug after
all, in which case I would appreciate information I Can
use to back that up :)
--
>Comment By: Tim Peters (tim_one)
Date: 2006-10-03 06:35
Message:
Logged In: YES
user_id=31435
> Based on the other bug I guess that casting an arbitrary
> long to unsigned long is allowed.
Right, C defines the result of casting any integral type to
any unsigned integral type.
> If so, then maybe we could use the following test:
>
> if (sign == '-' && uresult == 0-(unsigned
long)LONG_MIN) {
> result = LONG_MIN;
> }
>
> which states the intention a bit more clearly and
> without the assert().
We could. It's not really clearer to me, given that the
current code is explained in a comment block before
PyOS_strtol(), and I couldn't care less about removing an
assert, so I'm not going to bother. I wouldn't object to
changing it, although "0-" instead of plain unary "-" also
begs for an explanation lest someone delete the "0" because
it looks plain silly.
--
Comment By: Armin Rigo (arigo)
Date: 2006-10-03 06:10
Message:
Logged In: YES
user_id=4771
Based on the other bug I guess that casting an arbitrary
long to unsigned long is allowed. If so, then maybe we could
use the following test:
if (sign == '-' && uresult == 0-(unsigned long)LONG_MIN) {
result = LONG_MIN;
}
which states the intention a bit more clearly and without the
assert().
--
Comment By: Tim Peters (tim_one)
Date: 2006-09-05 01:21
Message:
Logged In: YES
user_id=31435
Well, I deliberately avoided using LONG_MIN in the patches
for the other bug, so that should answer your question ;-)
If someone wants to take the small risk of backporting it,
fine by me -- it's not going to break on Windows, and if it
doesn't break on your box either ...
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2006-09-05 01:12
Message:
Logged In: YES
user_id=33168
Tim, how do you feel about backporting now? (Not sure if
your opinion changed based on the other bug.) That and I'm
cleaning out my mailbox, so I don't have to look at this any
more. :-)
--
Comment By: Tim Peters (tim_one)
Date: 2006-07-27 17:00
Message:
Logged In: YES
user_id=31435
Neal, as I said in the checkin comment, I expect it's no
less likely that we'll get screwed by goofy platform values
for LONG_MIN and LONG_MAX than that we /got/ screwed by an
"over ambitious" compiler optimizing away "result ==
-result", so I'm not sure backporting is a good idea. I
stuck in an assert that might fail if a platform is insane;
if there are no reports of that assert triggering, then I'd
feel better about backporting the change.
--
Comment By: Matt Fleming (splitscreen)
Date: 2006-07-27 06:49
Message:
Logged In: YES
user_id=1126061
Fixed for me on NetBSD -current AMD64, gcc 4.1.2
--
Comment By: Nick Maclaren (nmm)
Date: 2006-07-27 04:31
Mess
[ python-Bugs-1569886 ] distutils don't respect standard env variables
Bugs item #1569886, was opened at 2006-10-03 12:59 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569886&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Lukas Lalinsky (luks) Assigned to: Nobody/Anonymous (nobody) Summary: distutils don't respect standard env variables Initial Comment: Using environment variables INCLUDE and LIB is a standard way to set system-wide paths for C compilers. However distutils.msvccompiler always overwrites these variables with it's own values, which means users have no way to customize their MSVC setups. It should *append* the Python-specific stuff to the variables, not overwrite them. --- msvccompiler.py.orig2006-10-03 12:56:15.81250 +0200 +++ msvccompiler.py 2006-10-03 12:56:22.71875 +0200 @@ -635,4 +635,7 @@ else: p = self.get_msvc_paths(name) if p: -os.environ[name] = string.join(p, ';') +p = string.join(p, ';') +if name in os.environ: +p = os.environ[name] + ';' + p +os.environ[name] = p -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569886&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1484556 ] Output of KlocWork on Python2.4.3 sources
Bugs item #1484556, was opened at 2006-05-09 12:14 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1484556&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Neal Norwitz (nnorwitz) Summary: Output of KlocWork on Python2.4.3 sources Initial Comment: We're evaluating KlocWork (http://www.klocwork.com), I've ran it on the source of Python 2.4.3 and the output is attached (1562 warnings). -- >Comment By: Martin v. Löwis (loewis) Date: 2006-10-03 14:02 Message: Logged In: YES user_id=21627 Ok, let's close this report, then. We continue to monitor Klocwork, regardless. -- Comment By: Miki Tebeka (tebeka) Date: 2006-10-03 10:24 Message: Logged In: YES user_id=358087 I don't know, currently KlocWork is way down in my "todo" list :( Looks like I won't be able to continue in this matter any longer, if anyone else want to give a hand ... Miki -- Comment By: Georg Brandl (gbrandl) Date: 2006-09-30 13:34 Message: Logged In: YES user_id=849994 Have all KlocWork issues been fixed now, Neal? -- Comment By: Miki Tebeka (tebeka) Date: 2006-06-04 11:53 Message: Logged In: YES user_id=358087 I'll try to see if I can sneak it in, can't promise anything though -- Comment By: A.M. Kuchling (akuchling) Date: 2006-05-31 16:26 Message: Logged In: YES user_id=11375 The Coverity scans also probably report some of the same bugs, so many of these problems may be fixed in the 2.5 trunk. If you're still evaluating, you could try running the tool on the 2.5 trunk (snapshot available from http://svn.python.org/snapshots/) and see if the results are shorter. -- Comment By: Martin v. Löwis (loewis) Date: 2006-05-10 06:45 Message: Logged In: YES user_id=21627 Thanks for these results. Unfortunately, they seem to contain many false positives, so it is unclear how one should proceed with them. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1484556&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1568243 ] init_types
Bugs item #1568243, was opened at 2006-09-30 11:34 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1568243&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 6 Submitted By: Bosko Vukov (bvukov) >Assigned to: Kristj�n Valur (krisvale) Summary: init_types Initial Comment: I tried to build the final version of Python 2.5, and found that function init_types in file Python-ast.c is created as int init_types(void) but in file config.c it's declared as extern void init_types(void); Visual Studio 2005 didn't want to build the project until I changed the config.c to be the same... extern int init_types(void); Nothing big ;) Regards, Bosko -- >Comment By: Martin v. Löwis (loewis) Date: 2006-10-03 14:11 Message: Logged In: YES user_id=21627 Kristijan, can you please backport your changes to the 2.5 trunk and then close this report? -- Comment By: Coatimundi (coatimundi) Date: 2006-10-02 21:22 Message: Logged In: YES user_id=1611513 Thanks, loewis. I take your advice. I see that things have changed in SVN anyway. I like the new approach of using Visual STudio's configuration management. When I (try to) build PGIRelease to instrument the python dll, I get a curious error: 1>Compiling... 1>zlibmodule.c 1>Compiling resources... 1>Linking... 1> Creating library Win32\PGIRelease\pythoncore/python26.lib and object Win32\PGIRelease\pythoncore/python26.exp 1>Generating code 1>c:\Documents and Settings\kferrio\My Documents\Dev\Python-2.5\Modules\zipimport.c : fatal error C1350: error loading dll 'pgodb80.dll': dll not found 1>LINK : fatal error LNK1257: code generation failed 1>Build log was saved at "file://c:\Documents and Settings\kferrio\My Documents\Dev\Python-2.5\PCbuild8\Win32\PGIRelease\pythoncore\BuildLog.htm" 1>pythoncore - 2 error(s), 2 warning(s) == Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped == I definitely do not understand this -- yet. Meanwhile, any clues would be welcome. Thanks. -- Comment By: Martin v. Löwis (loewis) Date: 2006-10-02 21:08 Message: Logged In: YES user_id=21627 I think you should avoid building pythoncore_pgo; it's of no use. Or else, study all documentation you can find on Microsoft's profile-guided-optimization for a few days, read all web logs about the bugs in this software, and perhaps you can succeed in building it, by deleting the right files in the right order. -- Comment By: Coatimundi (coatimundi) Date: 2006-10-02 20:28 Message: Logged In: YES user_id=1611513 I am expereincing the problem described by the original poster. I undertand that MSVC8 is not officially supported, and I'm trying anyway. I downloaded the 2.5.0 final tarball and began working in the PCbuild8 directory. Firts off, I found that I had to build two projects before pythoncore would build: make_versioninfo make_buildinfo When I tried to build pythoncore, I got the linker error saying that _init_types could not be found. So I added _typesmodule.c to the pythoncore project. Finally, pythoncore built cleanly. Next up, I wanted to build pythoncore_pgo. So I added _typesmodule to this project also. But try as I might, every attempt to build pythoncore_pgo produces the link error on _init_types. (I also did a 'clean' on pythoncore just to be safe.) I do not understand this. Unlike the original poster, I have not modified any source. It seems like the definition of pyMODINIT_FUNC as extern "C" void might be involved, but I agree with gbrandl that the static int in Python-ast.c is not the issue, because that is a different scope. So the linkage problem with pythoncore_pgo remains a mystery to me. I hope someone has more clues than me. -- Comment By: Martin v. Löwis (loewis) Date: 2006-10-02 16:00 Message: Logged In: YES user_id=21627 Notice that the PCbuild8 directory isn't really supported... In any case, the bug is that PCbuild8 does not have the reference to _typesmodule, not that init_types in Python-ast.c is static. If you revert your change to Python-ast.c, and change pythoncore.vcproj, it should build fine. This is already fixed in r51751 in the trunk; not sure whether backporting it is necessary. -- Comment By: Bosko Vukov (bvukov) Date: 2006-09-30 19:50 Message: Logged In: YES user_id=1292849 I opened solu
[ python-Bugs-1569517 ] PGIRelease linkage fails on pgodb80.dll
Bugs item #1569517, was opened at 2006-10-02 21:54 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569517&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.6 Status: Open Resolution: None Priority: 5 Submitted By: Coatimundi (coatimundi) >Assigned to: Kristj�n Valur (krisvale) Summary: PGIRelease linkage fails on pgodb80.dll Initial Comment: Hi. I'm interested in learning how to optimize Python for Windows. I have made a similar report as a follow-on to Bug 1568243, but it's really a separate issue. Let me emphasize that what I am about to describe this is *not* a bug in the Python build system. But it may be worth calling out in the README file for PCbuild8. When building PGIRelease to instrument the pythoncore DLL, the linker fails because it cannot find pgodb80.dll. This file is required for PGO with Visual C++ under Visual Studio 2005 and is shipped with the Professional version, but not with the Express version or (apparently) the Standard version I have. Looks like upgrade time... I hope this helps someone else. -- >Comment By: Martin v. Löwis (loewis) Date: 2006-10-03 14:12 Message: Logged In: YES user_id=21627 Kristjan, can you please take a look? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569517&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1567910 ] missing _typesmodule.c, Visual Studio 2005 pythoncore.vcproj
Bugs item #1567910, was opened at 2006-09-29 19:47 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1567910&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: everbruin (everbruin) >Assigned to: Kristj�n Valur (krisvale) Summary: missing _typesmodule.c,Visual Studio 2005 pythoncore.vcproj Initial Comment: Python 2.5's Visual Studio 2005 pythoncore.vcproj (in PCBuild8 folder) is missing Modules/_typesmodule.c (note the VS 2003 pythoncore.vcproj in PCBuild correctly has it). The bug is that binaries built w/o the file will give a SystemError when "import _types" is done (eg by types.py). -- >Comment By: Martin v. Löwis (loewis) Date: 2006-10-03 14:12 Message: Logged In: YES user_id=21627 Kristjan, can you please take a look? -- Comment By: Martin v. Löwis (loewis) Date: 2006-10-02 21:10 Message: Logged In: YES user_id=21627 I find it hard to believe that you get this precise error; I would have expected that the pythoncore project would fail to build instead. Notice that PCbuild8 is not really supported. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1567910&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1569886 ] distutils don't respect standard env variables
Bugs item #1569886, was opened at 2006-10-03 12:59 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569886&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils Group: Python 2.5 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Lukas Lalinsky (luks) Assigned to: Nobody/Anonymous (nobody) Summary: distutils don't respect standard env variables Initial Comment: Using environment variables INCLUDE and LIB is a standard way to set system-wide paths for C compilers. However distutils.msvccompiler always overwrites these variables with it's own values, which means users have no way to customize their MSVC setups. It should *append* the Python-specific stuff to the variables, not overwrite them. --- msvccompiler.py.orig2006-10-03 12:56:15.81250 +0200 +++ msvccompiler.py 2006-10-03 12:56:22.71875 +0200 @@ -635,4 +635,7 @@ else: p = self.get_msvc_paths(name) if p: -os.environ[name] = string.join(p, ';') +p = string.join(p, ';') +if name in os.environ: +p = os.environ[name] + ';' + p +os.environ[name] = p -- >Comment By: Martin v. Löwis (loewis) Date: 2006-10-03 14:50 Message: Logged In: YES user_id=21627 This bug was fixed in Python 2.5. If the environment variables MSSdk and DISTUTILS_USE_SDK are set, then distutils doesn't attempt to overwrite LIB or INCLUDE. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569886&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1569886 ] distutils don't respect standard env variables
Bugs item #1569886, was opened at 2006-10-03 12:59 Message generated for change (Comment added) made by luks You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569886&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils Group: Python 2.5 Status: Closed Resolution: Invalid Priority: 5 Submitted By: Lukas Lalinsky (luks) Assigned to: Nobody/Anonymous (nobody) Summary: distutils don't respect standard env variables Initial Comment: Using environment variables INCLUDE and LIB is a standard way to set system-wide paths for C compilers. However distutils.msvccompiler always overwrites these variables with it's own values, which means users have no way to customize their MSVC setups. It should *append* the Python-specific stuff to the variables, not overwrite them. --- msvccompiler.py.orig2006-10-03 12:56:15.81250 +0200 +++ msvccompiler.py 2006-10-03 12:56:22.71875 +0200 @@ -635,4 +635,7 @@ else: p = self.get_msvc_paths(name) if p: -os.environ[name] = string.join(p, ';') +p = string.join(p, ';') +if name in os.environ: +p = os.environ[name] + ';' + p +os.environ[name] = p -- >Comment By: Lukas Lalinsky (luks) Date: 2006-10-03 15:02 Message: Logged In: YES user_id=587716 Oh, I didn't know about this. Thank you. -- Comment By: Martin v. Löwis (loewis) Date: 2006-10-03 14:50 Message: Logged In: YES user_id=21627 This bug was fixed in Python 2.5. If the environment variables MSSdk and DISTUTILS_USE_SDK are set, then distutils doesn't attempt to overwrite LIB or INCLUDE. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569886&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1563630 ] IDLE doesn't load - apparently without firewall problems
Bugs item #1563630, was opened at 2006-09-22 17:19 Message generated for change (Comment added) made by daniboy22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563630&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: dani (daniboy22) Assigned to: Kurt B. Kaiser (kbk) Summary: IDLE doesn't load - apparently without firewall problems Initial Comment: I've installed Python in Windows XP, SP2. When I ran IDLE for the first times, it worked ok. But then I redefined some shorcuts (history-previous, history-next, and expand-word). This also worked ok, but there was a problem I wasn't expecting: I changed the history-previous to the short-cut + P, and when I use it for the first time it printed the content of the window... I forgot that this shorcut was already in use... Then came the real problem. I went to redefine the history-previous to another key set, but each time I clicked for "oK" for the new keys, the shell wrote some errors in red (-/+ 7/8 lines). I did that a few times until I closed IDLE and tried to restarted it again. Then it stop working. The only thing it does now is to show the hourglass logo in the mouse pointer for a few seconds and then it does not do anything else. I've installed Python in its default path (C:\Python25), and tried to switch off all the firewalls I remembered (Windows Firewall and disabled McAfee Virus Scan). None of that worked. I tried several times to reinstall the software, but that didn't work either. I even tried to install a previous version of Python (v2.4.3), but it had exactly the same problem. I haven't found any similar problem on the web. Thanks, Dani -- >Comment By: dani (daniboy22) Date: 2006-10-03 13:33 Message: Logged In: YES user_id=1604341 Well, I'm also not a specialist on the subject, but in my case I don't have any problems in opening the folder. I just had some problems to rename it (it didn't accepted a name starting with a "."), but I resolve it (I rename it to "pinga"). Concerning your problem, my hint is that your account is not an administrator one. Try to enter as an administrator and make the necessary changes. Or else change the permissions of your account to the "administrator" type (ask someone that is already an administrator on that computer to do that). -- Comment By: jordanramz (jordanramz) Date: 2006-10-02 22:15 Message: Logged In: YES user_id=1604497 Thanks for that, I found it. However, I guess I'm not as skilled with the computer as I thought... It won't let me change the name, open the folder etc. It says access is denied. Know why it's doing that when I try to modify it? -- Comment By: dani (daniboy22) Date: 2006-10-02 14:13 Message: Logged In: YES user_id=1604341 Dear kbk, I tried your solution and everything seems to work fine. I even recreated the problem (with the details that I still remember), and everything is OK. Many thanks! Dani P.S. For jordanramz: the .idlerc folder can be found in the directory c:\Documents and Settings (assuming you installed Windows on C:), and then selecting the folder corresponding to your ID (say, "jordanramz"). -- Comment By: dani (daniboy22) Date: 2006-10-02 14:12 Message: Logged In: YES user_id=1604341 Dear kbk, I tried your solution and everything seems to work fine. I even recreated the problem (with the details that I still remember), and everything is OK. Many thanks! Dani P.S. For jordanramz: the .idlerc folder can be found in the directory c:\Documents and Settings (assuming you installed Windows on C:), and then selecting the folder corresponding to your ID (say, "jordanramz"). -- Comment By: jordanramz (jordanramz) Date: 2006-10-01 16:42 Message: Logged In: YES user_id=1604497 What is the .idlerc customization folder? -- Comment By: Kurt B. Kaiser (kbk) Date: 2006-10-01 02:38 Message: Logged In: YES user_id=149084 Use the task manager to kill all Python processes. Then set aside your .idlerc customization folder (i.e. rename it). Now IDLE should start. Try to recreate the problem and post any error messages you see here. -- Comment By: jordanramz (jordanramz) Date: 2006-09-22 21:15 Message: Logged In: YES user_id=1604497 I am having the same problem. When I first installed it, it ran okay. Now everyti
[ python-Bugs-1569998 ] 2.5 incorrectly permits break inside try statement
Bugs item #1569998, was opened at 2006-10-04 00:04 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569998&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Nobody/Anonymous (nobody) Summary: 2.5 incorrectly permits break inside try statement Initial Comment: The new AST compiler permits the break statement inside *any* frame block, rather than requiring that there be a loop somewhere on the block stack. Will add examples in a comment where SF shouldn't destroy the formatting. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569998&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1569998 ] 2.5 incorrectly permits break inside try statement
Bugs item #1569998, was opened at 2006-10-04 00:04 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569998&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Nobody/Anonymous (nobody) Summary: 2.5 incorrectly permits break inside try statement Initial Comment: The new AST compiler permits the break statement inside *any* frame block, rather than requiring that there be a loop somewhere on the block stack. Will add examples in a comment where SF shouldn't destroy the formatting. -- >Comment By: Nick Coghlan (ncoghlan) Date: 2006-10-04 00:05 Message: Logged In: YES user_id=1038590 Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> try: ... print 1 ... break ... print 2 ... finally: ... print 3 ... SyntaxError: 'break' outside loop Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information.>>> try: ... print 1 ... break ... print 2 ... finally: ... print 3 ... 1 3 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569998&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1569998 ] 2.5 incorrectly permits break inside try statement
Bugs item #1569998, was opened at 2006-10-03 14:04 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569998&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.5 Status: Open Resolution: None >Priority: 8 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Nobody/Anonymous (nobody) Summary: 2.5 incorrectly permits break inside try statement Initial Comment: The new AST compiler permits the break statement inside *any* frame block, rather than requiring that there be a loop somewhere on the block stack. Will add examples in a comment where SF shouldn't destroy the formatting. -- Comment By: Nick Coghlan (ncoghlan) Date: 2006-10-03 14:05 Message: Logged In: YES user_id=1038590 Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> try: ... print 1 ... break ... print 2 ... finally: ... print 3 ... SyntaxError: 'break' outside loop Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information.>>> try: ... print 1 ... break ... print 2 ... finally: ... print 3 ... 1 3 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569998&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1569622 ] Backward incompatibility in logging.py
Bugs item #1569622, was opened at 2006-10-02 16:10 Message generated for change (Comment added) made by mklaas You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569622&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Mike Klaas (mklaas) Assigned to: Vinay Sajip (vsajip) Summary: Backward incompatibility in logging.py Initial Comment: LogRecord.__init__ changed in a backward incompatible way in python 2.5 (added one parameter). There is no mention of this breakage in the release notes, nor has the documentation of the module been updated (http://docs.python.org/lib/node424.html) -- >Comment By: Mike Klaas (mklaas) Date: 2006-10-03 10:14 Message: Logged In: YES user_id=1611720 It is incompatible as code written for 2.4 will break in 2.5, and vice-versa (this is a required parameter, not an optional parameter, and the change could have been made in a backward-compatible way). You're right that the documentation fix is the important thing. -- Comment By: Georg Brandl (gbrandl) Date: 2006-10-02 23:11 Message: Logged In: YES user_id=849994 I don't see why adding one parameter is backwards incompatible, but it's true that the docs must be updated. Assigning to Vinay. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569622&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1569622 ] Backward incompatibility in logging.py
Bugs item #1569622, was opened at 2006-10-02 23:10 Message generated for change (Comment added) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569622&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Mike Klaas (mklaas) Assigned to: Vinay Sajip (vsajip) Summary: Backward incompatibility in logging.py Initial Comment: LogRecord.__init__ changed in a backward incompatible way in python 2.5 (added one parameter). There is no mention of this breakage in the release notes, nor has the documentation of the module been updated (http://docs.python.org/lib/node424.html) -- >Comment By: Vinay Sajip (vsajip) Date: 2006-10-03 18:22 Message: Logged In: YES user_id=308438 Documentation now updated in CVS. Also changed the added "func" parameter to have a default value of None. Sorry for the inconvenience caused. -- Comment By: Mike Klaas (mklaas) Date: 2006-10-03 17:14 Message: Logged In: YES user_id=1611720 It is incompatible as code written for 2.4 will break in 2.5, and vice-versa (this is a required parameter, not an optional parameter, and the change could have been made in a backward-compatible way). You're right that the documentation fix is the important thing. -- Comment By: Georg Brandl (gbrandl) Date: 2006-10-03 06:11 Message: Logged In: YES user_id=849994 I don't see why adding one parameter is backwards incompatible, but it's true that the docs must be updated. Assigning to Vinay. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569622&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1567331 ] logging.RotatingFileHandler has no "infinite" backupCount
Feature Requests item #1567331, was opened at 2006-09-28 21:36 Message generated for change (Settings changed) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1567331&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Vinay Sajip (vsajip) Summary: logging.RotatingFileHandler has no "infinite" backupCount Initial Comment: It seems to me that logging.RotatingFileHandler should have a way to spell "never delete old log files". This is useful in situations where you want an external process (manual or automatic) make decisions about deleting log files. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1567331&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1570255 ] redirected cookies
Bugs item #1570255, was opened at 2006-10-04 09:37 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1570255&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: hans_moleman (hans_moleman) Assigned to: Nobody/Anonymous (nobody) Summary: redirected cookies Initial Comment: Cookies are not resend when a redirect is requested. Blurb: I've been trying to get a response off a server using Python. The response so far differs from the response using Firefox. In Python, I have set headers and cookies the way Firefox does it. I noticed that the server accepts the POST request, and redirects the client to another address with the result on it. This happens both with Python and Firefox correctly. Cookie handling differs though: The Python client, when redirected, using the standard redirect handler, does not resend its cookies to the redirected address. Firefox does resend the cookies from the original request. When I redefine the redirect handler and code it so that it adds the cookies from the original request, the response is the same as Firefox's response. This confirms then that resending cookies is required to get the server to respond correctly. Is the default Python redirection cookie policy different from Firefox's policy? Could we improve the default redirection handler to work like Firefox? Is it a bug? I noticed an old open bug report 511786, that looks very much like this problem. It suggests it is fixed. Cheers Hans Moleman. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1570255&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1570284 ] Launcher reset to factory button provides bad command-line
Bugs item #1570284, was opened at 2006-10-03 14:17 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1570284&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Macintosh Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: jjackson (jejackson) Assigned to: Jack Jansen (jackjansen) Summary: Launcher reset to factory button provides bad command-line Initial Comment: If I push the "Reset to factory settings" in Python Launcher's Preferences window, the command line gets a bogues "(null)" inserted, which makes a mess of things. I don't think that was what was intended. In trying to debug this, I notice in the source for FileSettings.m, at line 209 there are two duplicated lines: [NSNumber numberWithBool: nosite], @"nosite", [NSNumber numberWithBool: nosite], @"nosite", Also, I notice at FileSettings.m:236 value = [dict objectForKey: @"nosite"]; if (value) nosite = [value boolValue]; value = [dict objectForKey: @"nosite"]; if (value) tabs = [value boolValue]; I'm wondering if these second "nosite"s should be "tabs", and if that would fix the problem. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1570284&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1558223 ] apache2 - mod_python - python2.4 core dump
Bugs item #1558223, was opened at 2006-09-14 00:05 Message generated for change (Comment added) made by thurnerrupert You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1558223&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: 3rd Party Status: Closed Resolution: Invalid Priority: 5 Submitted By: ThurnerRupert (thurnerrupert) Assigned to: Nobody/Anonymous (nobody) Summary: apache2 - mod_python - python2.4 core dump Initial Comment: $ gdb bin/httpd GNU gdb 6.0 Copyright 2003 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "sparc-sun-solaris2.8"... (gdb) core core Core was generated by `/usr/local/bin/httpd -k restart'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/local/lib/libssl.so.0.9.8...done. Loaded symbols for /usr/local/lib/libssl.so.0.9.8 <... deleted the whole loaded libraries> #0 0xfebb3218 in strlen () from /usr/lib/libc.so.1 (gdb) bt #0 0xfebb3218 in strlen () from /usr/lib/libc.so.1 #1 0xfda6ac4c in PyString_FromString ( str=0xfef65ec0 "unexpected parser state - please send a bug report") at Objects/stringobject.c:106 #2 0xfdac9b50 in PyModule_AddStringConstant (m=0x594cd0, name=0xfe5a5478 "XML_ERROR_ENTITY_DECLARED_IN_PE", value=0x0) at Python/modsupport.c:589 #3 0xfe57cec4 in initpyexpat () at /usr/local/Python-2.4.3/Modules/pyexpat.c:1973 this happens when running moinmoin 1.5.4, and doing a gui-edit. mod_python-3.2.10, httpd-2.2.3, solaris 8, compile with gcc-3.4.6. -- >Comment By: ThurnerRupert (thurnerrupert) Date: 2006-10-03 23:54 Message: Logged In: YES user_id=1597584 ok ... i will. we noticed similar errors when running: * edgewall trac 0.11-dev (which uses edgewall ghenshi) * xml-rpc plugin for edgewall trac also, i filed the bug report after changing to newest mod_python. the old mod_python with apache 2.0.54 did not give a core, just segfaulted. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-14 05:34 Message: Logged In: YES user_id=33168 Please file this bug report with mod_python. That's typically the cause and it will likely be very hard for any Python developer to create this setup and much less try to reproduce the error. If you can provoke the same error without mod_python or other third party C extensions, please file a bug report with the minimal test case to reproduce. If you need a work-around, I would suggest changing to a different version of mod_python. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1558223&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1558223 ] apache2 - mod_python - python2.4 core dump
Bugs item #1558223, was opened at 2006-09-14 00:05 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1558223&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: 3rd Party Status: Closed Resolution: Invalid Priority: 5 Submitted By: ThurnerRupert (thurnerrupert) Assigned to: Nobody/Anonymous (nobody) Summary: apache2 - mod_python - python2.4 core dump Initial Comment: $ gdb bin/httpd GNU gdb 6.0 Copyright 2003 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "sparc-sun-solaris2.8"... (gdb) core core Core was generated by `/usr/local/bin/httpd -k restart'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/local/lib/libssl.so.0.9.8...done. Loaded symbols for /usr/local/lib/libssl.so.0.9.8 <... deleted the whole loaded libraries> #0 0xfebb3218 in strlen () from /usr/lib/libc.so.1 (gdb) bt #0 0xfebb3218 in strlen () from /usr/lib/libc.so.1 #1 0xfda6ac4c in PyString_FromString ( str=0xfef65ec0 "unexpected parser state - please send a bug report") at Objects/stringobject.c:106 #2 0xfdac9b50 in PyModule_AddStringConstant (m=0x594cd0, name=0xfe5a5478 "XML_ERROR_ENTITY_DECLARED_IN_PE", value=0x0) at Python/modsupport.c:589 #3 0xfe57cec4 in initpyexpat () at /usr/local/Python-2.4.3/Modules/pyexpat.c:1973 this happens when running moinmoin 1.5.4, and doing a gui-edit. mod_python-3.2.10, httpd-2.2.3, solaris 8, compile with gcc-3.4.6. -- Comment By: �iga Seilnacht (zseil) Date: 2006-10-04 00:47 Message: Logged In: YES user_id=1326842 This looks like another problem with pyexpat getting the export symbols from an older expat version. See: http://www.python.org/sf/1295808 and http://www.python.org/sf/1075984 for details. -- Comment By: ThurnerRupert (thurnerrupert) Date: 2006-10-03 23:54 Message: Logged In: YES user_id=1597584 ok ... i will. we noticed similar errors when running: * edgewall trac 0.11-dev (which uses edgewall ghenshi) * xml-rpc plugin for edgewall trac also, i filed the bug report after changing to newest mod_python. the old mod_python with apache 2.0.54 did not give a core, just segfaulted. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-14 05:34 Message: Logged In: YES user_id=33168 Please file this bug report with mod_python. That's typically the cause and it will likely be very hard for any Python developer to create this setup and much less try to reproduce the error. If you can provoke the same error without mod_python or other third party C extensions, please file a bug report with the minimal test case to reproduce. If you need a work-around, I would suggest changing to a different version of mod_python. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1558223&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1569057 ] Using .next() on file open in write mode writes junk to file
Bugs item #1569057, was opened at 2006-10-01 23:49
Message generated for change (Comment added) made by rainy
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569057&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: Documentation
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: andrei kulakov (rainy)
Assigned to: Nobody/Anonymous (nobody)
Summary: Using .next() on file open in write mode writes junk to file
Initial Comment:
When you open a file in write mode and use .next(), it
prints an error and writes many lines of junk to file.
I tested on windows and python 2.5:
>>> f = open('test', 'w')
>>> f.fileno()
4
>>> f.write('1\n')
>>> f.write('2\n3\n4\n')
>>> f.next()
Traceback (most recent call last):
File "", line 1, in
f.next()
IOError: [Errno 9] Bad file descriptor
>>> f.close()
>>> f = open('test')
>>> f.next()
'1\n'
>>> f.next()
'2\n'
>>> f.next()
'3\n'
>>> f.next()
'4\n'
>>> f.next()
'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x
00\x00\x00\x00\x00\x
00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00
\x00\x00\x00\x00\x00\
x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00
\x00\x00\x00
...many more lines of junk...'
--
>Comment By: andrei kulakov (rainy)
Date: 2006-10-03 20:23
Message:
Logged In: YES
user_id=511010
Python newsgroup folks said that this is normal because when
switching between write/read modes without doing flush()
first, result is undefined. There was a suggestion from
Terry Ready to add this to documentation on file methods:
"When switching from reading or writing (or vice versa),
call flush(), or
the result will be undefined."
thx, -andrei
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569057&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Bug in unicode object free list?
I suspect there is a bug in the way the unicode object "free list" is managed. In the file unicodeobject.c, I noticed the following statements whose behaviour is a bit ambiguous for me: unicode_freelist = *(PyUnicodeObject **)unicode; . *(PyUnicodeObject **)unicode = unicode_freelist; .. u = *(PyUnicodeObject **)u; It seems to me that those statements assume the first member of PyUnicodeObject is "_ob_next" but this is true only if Py_TRACE_REFS is defined. If PyTRACE_REFS is not defined, the first member of PyUnicodeObject is "ob_refcnt" and I think the above statements have an unexpected behaviour. Regards. Pasquale d'Aloise GATE T.I. s.r.l. Viale dei Pentri, P.zzo D'Abbraccio 86170 ISERNIA Tel. 0865.451890 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Exception during GarbageCollection in Py_Finalize()
Hi,
I have two problems using the C/API to write a C dll, the first and
serious:
1) The Scenario (pLocal, pGlobal are not changed by the dll during one
"init-> fini" cycle)
- Py_Initialize()
- PyRun_String("x=1", Py_single_input, pGlobal, pLocal)
- PyRun_String("x:=1", Py_eval_input, pGlobal, pLocal)
-> returns -1; Hint: if the string contains a valid statement
("x==1") there is no exception at finalize
- Py_Finalize()
---> access violation
At the Py_Finalize an access violation appears. As I'm having trouble
building python by myself I have no debug version available to see
whats goin' on in the finalize().
Of course it is an invalid statement, but an access violation is still
not nice.
the 2nd)
In Py_DECREF in the case the variable will be deleted, it would be
helpful to set the variable to NULL. Otherwise I have to check it
(ob_refcnt) in my code as well.
If the API is used in an invalid way, please tell how the right way is.
Kind Regards,
Matthias
--
schau
Matthias Uhlig
Gewerbering 9, D-91341 Röttenbach, Germany
Tel: +49 (0) 9195 / 931 235
Fax: +49 (0) 9195 / 995 858
Email: [EMAIL PROTECTED]
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
sys.settrace closure interaction bug
The code below exhibits different behavior depending on whether it invokes sys.settrace ('-t' option) or not. This means that (in a more complicated case) debugging the code (which uses sys.settrace) makes it fail. Any ideas?
""" Demonstrace that tracing messes up curried class definitions """
# Some simple command line parsing: -t or --trace means trace, nothing means don't trace
import sysdef usage( ):
print 'Usage:', sys.argv[ 0 ], '[-t | --trace]' sys.exit( 1 )
if 1 == len( sys.argv ):
passelif 2 == len( sys.argv ):
if sys.argv[ 1 ]=='-t' or sys.argv[ 1 ]=='--trace': def trace ( frame, event, arg ):
# print frame, event, arg
return trace sys.settrace( trace )
else: usage( )
else: usage( )
# The test: define a class factory with a curried member function
def the_factory( parm1 ):
class the_class( object ): def curried( self ): return parm1
return the_class
x = the_factory( 42 )y = x( )
try: x.parm1
print "Failure: x (the manufactured class) has attribute parm1?!"
except AttributeError: print "Success with the manufactured class!"
try:
y.parm1 print "Failure: y (the instance) has attribute parm1?!"
except AttributeError: print "Success with the instance!"
assert y.curried( ) == 42, "Currying didn't work?!"
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: [ python-Bugs-1569998 ] 2.5 incorrectly permits break inside try statement
I'm working on this bug now, but can't get an SF login to update the bug report. Jeremy On 10/3/06, SourceForge.net <[EMAIL PROTECTED]> wrote: > Bugs item #1569998, was opened at 2006-10-03 14:04 > Message generated for change (Settings changed) made by gbrandl > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569998&group_id=5470 > > Please note that this message will contain a full copy of the comment thread, > including the initial issue submission, for this request, > not just the latest update. > Category: Parser/Compiler > Group: Python 2.5 > Status: Open > Resolution: None > >Priority: 8 > Submitted By: Nick Coghlan (ncoghlan) > Assigned to: Nobody/Anonymous (nobody) > Summary: 2.5 incorrectly permits break inside try statement > > Initial Comment: > The new AST compiler permits the break statement inside > *any* frame block, rather than requiring that there be > a loop somewhere on the block stack. > > Will add examples in a comment where SF shouldn't > destroy the formatting. > > -- > > Comment By: Nick Coghlan (ncoghlan) > Date: 2006-10-03 14:05 > > Message: > Logged In: YES > user_id=1038590 > > Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit > (Intel)] on win32 > Type "help", "copyright", "credits" or "license" for more > information. > >>> try: > ... print 1 > ... break > ... print 2 > ... finally: > ... print 3 > ... > SyntaxError: 'break' outside loop > > Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 > bit (Intel)] on win32 > Type "help", "copyright", "credits" or "license" for more > information.>>> try: > ... print 1 > ... break > ... print 2 > ... finally: > ... print 3 > ... > 1 > 3 > > -- > > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569998&group_id=5470 > ___ > Python-bugs-list mailing list > Unsubscribe: > http://mail.python.org/mailman/options/python-bugs-list/jeremy%40alum.mit.edu > > ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1569356 ] sys.settrace cause curried parms to show up as attributes
Bugs item #1569356, was opened at 2006-10-02 11:26
Message generated for change (Comment added) made by scott_marks
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569356&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: applebucks (scott_marks)
Assigned to: Martin v. Löwis (loewis)
Summary: sys.settrace cause curried parms to show up as attributes
Initial Comment:
The code below exhibits different behavior depending on
whether it invokes sys.settrace ('-t' option) or not.
This means that (in a more complicated case) debugging
the code (which uses sys.settrace) makes it fail.
Reported v 2.4, but the same behavior on 2.5. Any ideas?
""" Demonstrace that tracing messes up curried class
definitions """
# Some simple command line parsing: -t or --trace means
trace, nothing means don't trace
import sys
def usage( ):
print 'Usage:', sys.argv[ 0 ], '[-t | --trace]'
sys.exit( 1 )
if 1 == len( sys.argv ):
pass
elif 2 == len( sys.argv ):
if sys.argv[ 1 ]=='-t' or sys.argv[ 1 ]=='--trace':
def trace ( frame, event, arg ):
# print frame, event, arg
return trace
sys.settrace( trace )
else:
usage( )
else:
usage( )
# The test: define a class factory with a curried
member function
def the_factory( parm1 ):
class the_class( object ):
def curried( self ): return parm1
return the_class
x = the_factory( 42 )
y = x( )
try:
x.parm1
print "Failure: x (the manufactured class) has
attribute parm1?!"
except AttributeError:
print "Success with the manufactured class!"
try:
y.parm1
print "Failure: y (the instance) has attribute parm1?!"
except AttributeError:
print "Success with the instance!"
assert y.curried( ) == 42, "Currying didn't work?!"
--
>Comment By: applebucks (scott_marks)
Date: 2006-10-03 22:32
Message:
Logged In: YES
user_id=120857
"Cannot be fixed" sounds pretty final, and also a little
pessimistic. From your description, it seems that the
correct functionality could be maintained at the cost of
retention of the keys in "normal locals" and dissection back
into "fast locals" and "normal locals" after the trace
function does ... whatever it does. In particular, it seems
unacceptable that the invariants of the semantics of class
creation (on which introspection and other important
functionality depends) is borked by debugging in such a way
as to render quite misleading the process of debugging code
that depends on those invariants.
Not to mention that the workaround ("be sure to rename your
class factory function parameters so that they don't collide
with intended attributes of the created class") just makes
Python seem ... lame.
I hope for a more optimistic reply.
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-10-03 02:49
Message:
Logged In: YES
user_id=849994
I'm afraid that this cannot be fixed.
In normal execution, the variable "parm1" is stored by the
compiler in the "fast locals" (that are referenced by index
into a list) for the function that is used to build the
class, which means that it is not in the dict of "normal
locals" (that are referenced by their name in the dict) that
is returned at the end.
If you set a trace function, on each call to the trace
function the "fast locals" are merged into the "normal
locals" in order to give the trace function full control
over the execution frame. This means that after the trace
function has been executed for the class' frame, the locals
will contain "parm1" which will then show up as an attribute
of that class.
Martin, do you you have an additional opinion?
--
Comment By: applebucks (scott_marks)
Date: 2006-10-02 12:02
Message:
Logged In: YES
user_id=120857
This bug actually causes a failure in a system that heavily
uses function-level programming and member delegation. The
bug occurred when a class factory function formal parameter
name was the same as a field delegated by instances of the
generated class to a member -- when run in a debugger (i.e.
after a non-None call to sys.settrace) the delegating
descriptor was over-written by the value of the factory
function parameter.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569356&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1563630 ] IDLE doesn't load - apparently without firewall problems
Bugs item #1563630, was opened at 2006-09-22 12:19 Message generated for change (Comment added) made by jordanramz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563630&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: dani (daniboy22) Assigned to: Kurt B. Kaiser (kbk) Summary: IDLE doesn't load - apparently without firewall problems Initial Comment: I've installed Python in Windows XP, SP2. When I ran IDLE for the first times, it worked ok. But then I redefined some shorcuts (history-previous, history-next, and expand-word). This also worked ok, but there was a problem I wasn't expecting: I changed the history-previous to the short-cut + P, and when I use it for the first time it printed the content of the window... I forgot that this shorcut was already in use... Then came the real problem. I went to redefine the history-previous to another key set, but each time I clicked for "oK" for the new keys, the shell wrote some errors in red (-/+ 7/8 lines). I did that a few times until I closed IDLE and tried to restarted it again. Then it stop working. The only thing it does now is to show the hourglass logo in the mouse pointer for a few seconds and then it does not do anything else. I've installed Python in its default path (C:\Python25), and tried to switch off all the firewalls I remembered (Windows Firewall and disabled McAfee Virus Scan). None of that worked. I tried several times to reinstall the software, but that didn't work either. I even tried to install a previous version of Python (v2.4.3), but it had exactly the same problem. I haven't found any similar problem on the web. Thanks, Dani -- Comment By: jordanramz (jordanramz) Date: 2006-10-03 21:45 Message: Logged In: YES user_id=1604497 The problem is that it is my laptop, so I am the administrator. I booted up in safe mode so that I could log on as the administrator, and even then it wouldn't let me access any of my (username) documents, so I couldn't even get in to view that folder let alone change the name. -- Comment By: dani (daniboy22) Date: 2006-10-03 08:33 Message: Logged In: YES user_id=1604341 Well, I'm also not a specialist on the subject, but in my case I don't have any problems in opening the folder. I just had some problems to rename it (it didn't accepted a name starting with a "."), but I resolve it (I rename it to "pinga"). Concerning your problem, my hint is that your account is not an administrator one. Try to enter as an administrator and make the necessary changes. Or else change the permissions of your account to the "administrator" type (ask someone that is already an administrator on that computer to do that). -- Comment By: jordanramz (jordanramz) Date: 2006-10-02 17:15 Message: Logged In: YES user_id=1604497 Thanks for that, I found it. However, I guess I'm not as skilled with the computer as I thought... It won't let me change the name, open the folder etc. It says access is denied. Know why it's doing that when I try to modify it? -- Comment By: dani (daniboy22) Date: 2006-10-02 09:13 Message: Logged In: YES user_id=1604341 Dear kbk, I tried your solution and everything seems to work fine. I even recreated the problem (with the details that I still remember), and everything is OK. Many thanks! Dani P.S. For jordanramz: the .idlerc folder can be found in the directory c:\Documents and Settings (assuming you installed Windows on C:), and then selecting the folder corresponding to your ID (say, "jordanramz"). -- Comment By: dani (daniboy22) Date: 2006-10-02 09:12 Message: Logged In: YES user_id=1604341 Dear kbk, I tried your solution and everything seems to work fine. I even recreated the problem (with the details that I still remember), and everything is OK. Many thanks! Dani P.S. For jordanramz: the .idlerc folder can be found in the directory c:\Documents and Settings (assuming you installed Windows on C:), and then selecting the folder corresponding to your ID (say, "jordanramz"). -- Comment By: jordanramz (jordanramz) Date: 2006-10-01 11:42 Message: Logged In: YES user_id=1604497 What is the .idlerc customization folder? -- Comment By: Kurt B. Kaiser (kbk) Date: 2006-09-30 21:38 Message: Logged In: YES user_id=149084 Use the tas
[ python-Bugs-1570417 ] 2.4 & 2.5 can't create win installer on linux
Bugs item #1570417, was opened at 2006-10-04 13:45 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1570417&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Richard Jones (richard) Assigned to: Nobody/Anonymous (nobody) Summary: 2.4 & 2.5 can't create win installer on linux Initial Comment: With python 2.4.3 and 2.5 I can't build a Windows installer on Linux. I get the following error: Warning: Can't read registry to find the necessary compiler setting Make sure that Python modules _winreg, win32api or win32con are installed. removing 'build/bdist.linux-i686/wininst' (and everything under it) I can still create an installer with 2.3.5 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1570417&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1484556 ] Output of KlocWork on Python2.4.3 sources
Bugs item #1484556, was opened at 2006-05-09 03:14 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1484556&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Neal Norwitz (nnorwitz) Summary: Output of KlocWork on Python2.4.3 sources Initial Comment: We're evaluating KlocWork (http://www.klocwork.com), I've ran it on the source of Python 2.4.3 and the output is attached (1562 warnings). -- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-10-03 22:02 Message: Logged In: YES user_id=33168 Right, all the important changes have been fixed AFAIK. There might be a few that slipped through, but we are in good enough shape. -- Comment By: Martin v. Löwis (loewis) Date: 2006-10-03 05:02 Message: Logged In: YES user_id=21627 Ok, let's close this report, then. We continue to monitor Klocwork, regardless. -- Comment By: Miki Tebeka (tebeka) Date: 2006-10-03 01:24 Message: Logged In: YES user_id=358087 I don't know, currently KlocWork is way down in my "todo" list :( Looks like I won't be able to continue in this matter any longer, if anyone else want to give a hand ... Miki -- Comment By: Georg Brandl (gbrandl) Date: 2006-09-30 04:34 Message: Logged In: YES user_id=849994 Have all KlocWork issues been fixed now, Neal? -- Comment By: Miki Tebeka (tebeka) Date: 2006-06-04 02:53 Message: Logged In: YES user_id=358087 I'll try to see if I can sneak it in, can't promise anything though -- Comment By: A.M. Kuchling (akuchling) Date: 2006-05-31 07:26 Message: Logged In: YES user_id=11375 The Coverity scans also probably report some of the same bugs, so many of these problems may be fixed in the 2.5 trunk. If you're still evaluating, you could try running the tool on the 2.5 trunk (snapshot available from http://svn.python.org/snapshots/) and see if the results are shorter. -- Comment By: Martin v. Löwis (loewis) Date: 2006-05-09 21:45 Message: Logged In: YES user_id=21627 Thanks for these results. Unfortunately, they seem to contain many false positives, so it is unclear how one should proceed with them. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1484556&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1569998 ] 2.5 incorrectly permits break inside try statement
Bugs item #1569998, was opened at 2006-10-03 07:04 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569998&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.5 Status: Open Resolution: None Priority: 8 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Nobody/Anonymous (nobody) Summary: 2.5 incorrectly permits break inside try statement Initial Comment: The new AST compiler permits the break statement inside *any* frame block, rather than requiring that there be a loop somewhere on the block stack. Will add examples in a comment where SF shouldn't destroy the formatting. -- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-10-03 22:47 Message: Logged In: YES user_id=33168 Jeremy checked in r52129 on head. Needs backport to 2.5. -- Comment By: Nick Coghlan (ncoghlan) Date: 2006-10-03 07:05 Message: Logged In: YES user_id=1038590 Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> try: ... print 1 ... break ... print 2 ... finally: ... print 3 ... SyntaxError: 'break' outside loop Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information.>>> try: ... print 1 ... break ... print 2 ... finally: ... print 3 ... 1 3 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569998&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1570284 ] Launcher reset to factory button provides bad command-line
Bugs item #1570284, was opened at 2006-10-03 14:17 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1570284&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Macintosh Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: jjackson (jejackson) >Assigned to: Ronald Oussoren (ronaldoussoren) Summary: Launcher reset to factory button provides bad command-line Initial Comment: If I push the "Reset to factory settings" in Python Launcher's Preferences window, the command line gets a bogues "(null)" inserted, which makes a mess of things. I don't think that was what was intended. In trying to debug this, I notice in the source for FileSettings.m, at line 209 there are two duplicated lines: [NSNumber numberWithBool: nosite], @"nosite", [NSNumber numberWithBool: nosite], @"nosite", Also, I notice at FileSettings.m:236 value = [dict objectForKey: @"nosite"]; if (value) nosite = [value boolValue]; value = [dict objectForKey: @"nosite"]; if (value) tabs = [value boolValue]; I'm wondering if these second "nosite"s should be "tabs", and if that would fix the problem. -- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-10-03 22:48 Message: Logged In: YES user_id=33168 Ronald, I'm guessing that Jack still doesn't have time. Do you know anything about this? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1570284&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1446043 ] unicode('foo', '.utf99') does not raise LookupError
Bugs item #1446043, was opened at 2006-03-08 16:55
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1446043&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Unicode
Group: Python 2.4
Status: Closed
Resolution: Fixed
Priority: 8
Submitted By: osvenskan (osvenskan)
>Assigned to: A.M. Kuchling (akuchling)
Summary: unicode('foo', '.utf99') does not raise LookupError
Initial Comment:
A very minor inconsistency -- when I call unicode()
with an encoding that Python doesn't know about, it
usually returns a lookup error (e.g LookupError:
unknown encoding: utf99). But when the encoding begins
with a dot (ASCII 0x2e), Python instead gives a
ValueError: Empty module name. It is certainly correct
in raising an error, but it should raise a lookup
error, not a value error.
I've recreated this under Python 2.4.1/FreeBSD 6.0 and
2.3/OS X. See attachment for recreation steps.
--
>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-10-03 22:58
Message:
Logged In: YES
user_id=33168
I thought part of this was reverted, but I'm not sure if it
was reverted in 2.4. I know I had starred this for some
reason, but I don't recall exactly. This should be
investigated. I'm not sure there was a test for this either.
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-09-30 04:22
Message:
Logged In: YES
user_id=849994
Fixed in rev. 52075, 52076 (2.4), 52077 (2.5).
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-08-17 12:17
Message:
Logged In: YES
user_id=849994
I'd say that this should be fixed before 2.5 final.
Attached patch (the modname that's used for import may not
contain a dot anymore...)
--
Comment By: osvenskan (osvenskan)
Date: 2006-04-06 07:45
Message:
Logged In: YES
user_id=1119995
I noticed that the documentation for unicode() says, "if the
encoding is not known, LookupError is raised". Regarding the
3rd parameter ("errors") to unicode(), the docs say, "Error
handling is done according to errors; this specifies the
treatment of characters which are invalid in the input
encoding. If errors is 'strict' (the default), a ValueError
is raised on errors..."
ref: http://docs.python.org/lib/built-in-funcs.html
That makes the code's current behavior doubly confusing
because a the documentation says that a ValueError is
reserved for indicating an undecodable byte sequence, not an
unknown encoding name.
--
Comment By: osvenskan (osvenskan)
Date: 2006-03-09 07:04
Message:
Logged In: YES
user_id=1119995
There are encoding names that contain dots, such as
ANSI_X3.4-1968, ANSI_X3.4-1986 and ISO_646.IRV:1991 (as
reported by iconv). There are none in iconv's list that
begin with a dot.
Please note that the behavior of this function has been
discussed before in Python bugs 513666 and 960874. Apologies
for not referencing them in my original report.
Having stepped through the code, I understand how the
ValueError is getting generated. My frustration with this as
a programmer is that I want to write specific except clauses
for each possible exception that a method can raise, but
that's impractical if any exception is fair game on any
method. So I'm forced to use a catch-all except clause about
which the Python documentation says (wisely, IMHO), "Use
this with extreme caution, since it is easy to mask a real
programming error in this way!" While it is helpful to
document errors that a method is *likely* to raise, my code
needs to handle all possibilities, not just likely ones.
Perhaps the answer is just, "This is how Python works" and
if I feel it is a weakness in the language I need to take it
up on a different level.
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-03-09 00:16
Message:
Logged In: YES
user_id=849994
Is it possible for an encoding name to contain dots at all?
If not, this would do too:
if '.' in modname: continue
--
Comment By: Walter Dörwald (doerwalter)
Date: 2006-03-09 00:12
Message:
Logged In: YES
user_id=89016
The problem is that after normalizing the encoding name a
module with this name is imported. Maybe
encodings/__init__.py:search_function should do:
if ".".join(filter(None, modname.split("."))) != modname:
return None
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detai
[ python-Bugs-1570417 ] 2.4 & 2.5 can't create win installer on linux
Bugs item #1570417, was opened at 2006-10-04 05:45 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1570417&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Richard Jones (richard) >Assigned to: Thomas Heller (theller) Summary: 2.4 & 2.5 can't create win installer on linux Initial Comment: With python 2.4.3 and 2.5 I can't build a Windows installer on Linux. I get the following error: Warning: Can't read registry to find the necessary compiler setting Make sure that Python modules _winreg, win32api or win32con are installed. removing 'build/bdist.linux-i686/wininst' (and everything under it) I can still create an installer with 2.3.5 -- >Comment By: Martin v. Löwis (loewis) Date: 2006-10-04 08:30 Message: Logged In: YES user_id=21627 The message you get is a warning only; you can ignore it. However, it still fails because it can't determine what msvcrt version the target python was built with. It needs to find that out because it needs to decide whether to use wininst-6.exe or wininst-7.1.exe. Thomas, can you think of a way to fix this? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1570417&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
