[ python-Bugs-1521947 ] possible bug in mystrtol.c with recent gcc

[SourceForge.net]

Bugs item #1521947, was opened at 2006-07-13 17:39
Message generated for change (Comment added) made by splitscreen
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: 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 who has such a platform could
check against current Python trunk.

--

Comment By: Nick Maclaren (nmm)
Date: 2006-07-17 09:20

Message:
Logged In: YES 
user_id=42444

Yes, this is a duplicate of 1521726.

The compiler people's answer is correct, and mystrtoul.c is
incorrect. LONG_MIN has been in C since C90, so should be
safe, but its value may not always be what you expect.

However, the code breakage is worse that just that test, and
there are the following 3 cases of undefined behaviour:

1) Casting and unsigned long to long above LONG_MAX.
2) That test.
3) result = -result.

The fix should be to make result unsigned long, and check
the range BEFORE any conversion.  Nothing else is safe.

It is a matter of taste whether to include a fiddle for the
number that can be held only when negated - I wouldn't, and
would let that number be converted to a Python long, but
others might disagree.


--

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-17 01:13

Message:
Logged In: YES 
user_id=33168

Is this a duplicate of 1521726?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521947&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1519452 ] zipfile -- too many files?

[SourceForge.net]

Bugs item #1519452, was opened at 2006-07-09 07:57
Message generated for change (Settings changed) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1519452&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: Fixed
Priority: 5
Submitted By: Joe Brown (shmengie)
Assigned to: Nobody/Anonymous (nobody)
Summary: zipfile -- too many files?

Initial Comment:
While creating a huge zipfile (probably too big) the
following error appeared.

Exception exceptions.OverflowError: 'long int too large
to convert to int' in > ignored

I assume this is during the closing of the zipfile,
further assuming too many files were added to the archive.

--

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-13 10:17

Message:
Logged In: YES 
user_id=580910

hmm, I should read all new comments before responding :-(

To use the ZIP64 extensions with python2.5 you must add 'allowZip64=True' to 
arguments of the zipfile constructor. ZIP64 is disabled by default because the 
unix zip tools don't support zip64.

--

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-13 09:47

Message:
Logged In: YES 
user_id=580910

The problem with zipfile is not the number of files, but the size of the 
archive. 
The basic zip file format stores file sizes as 32 bit (signed) integers, there 
is an 
extension for using 64 bit integers, but that isn't supported in python 2.4.

--

Comment By: Joe Brown (shmengie)
Date: 2006-07-12 04:17

Message:
Logged In: YES 
user_id=729883

Windows 2.5 beta 2 responded like this:

Traceback (most recent call last):
  File "C:\python_scripts\archive.py", line 27, in 
main()
  File "C:\python_scripts\archive.py", line 23, in main
zipper(zip, folder)
  File "C:\python_scripts\archive.py", line 15, in zipper
zip.write(os.path.join(root, item))
  File "C:\Python25\lib\zipfile.py", line 561, in write
self._writecheck(zinfo)
  File "C:\Python25\lib\zipfile.py", line 536, in _writecheck
raise LargeZipFile("Zipfile size would require ZIP64
extensions")
zipfile.LargeZipFile: Zipfile size would require ZIP64
extensions
C:\Python25\lib\struct.py:63: DeprecationWarning: struct
integer overflow maskin
g is deprecated
  return o.pack(*args)

--

Comment By: Joe Brown (shmengie)
Date: 2006-07-11 22:08

Message:
Logged In: YES 
user_id=729883

The zip file was on order of 6-9 GBs, surely over 32000
files.  I will give Python2.5 a shot and see how that works.

I've stumbled on another bug with tarfile.  It's not
reporting an error, but I only find 350 files when I
unarchive.  That's entirely different bug tho :-o

--

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-11 19:47

Message:
Logged In: YES 
user_id=580910

How large is the resulting file? Zipfile in python2.4 cannot handle zipfiles 
that 
require the zip64 extensions and fails misserably when you do cross that limit.

This was fixed in python 2.5.

--

Comment By: Joe Brown (shmengie)
Date: 2006-07-09 08:01

Message:
Logged In: YES 
user_id=729883

Platform: Windows SBS 2003
Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit
(Intel)] on win32

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1519452&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1469557 ] FTP modue functions are not re-entrant, give odd exceptions

[SourceForge.net]

Bugs item #1469557, was opened at 2006-04-13 00:13
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1469557&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.4
>Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Bruce (brucepeterson)
Assigned to: Nobody/Anonymous (nobody)
Summary: FTP modue functions are not re-entrant,give odd exceptions

Initial Comment:
 If I define a class using the Thread and FTP moudles, 
start a process which gathers FTP responses, 
additional calls to the class may have the responses 
of the thread instead of the main loop (or vice versa)
  This causes weird and unexpected exceptions from the 
ftplib.

  For instance I get the following error when the 
thread process does a pwd() function
error_reply: 213 34603008  

  The "213" reply is a response from the main process 
size() function

-
Code
-
from time import sleep
from threading import Thread

class ftpMachine(Thread, ftplib.FTP):
def __init__(self, svr, user, passwd):
Thread.__init__(self)
ftplib.FTP.__init__(self, svr, user, passwd)

def run(self):
for x in xrange(20):
output="Thread -"+str(self.nlst())[:30]
print output
sleep (0.0100)

def main():
aCon = ftpMachine("LocalFTP", "user", "")
aCon.start()
for x in xrange(20):
output = "Main -- " + str(aCon.size("File"))
print output  
sleep (0.010)

Workround:
  Rewrite code to create a third worker thread for 
response isolation?  Don't know that this would solve 
the problem.


---
Exception example
---

Exception in thread Thread-1:
Traceback (most recent call last):
  File "C:\Python24\lib\threading.py", line 442, in 
__bootstrap
self.run()
  File "dualFTPIssue.py", line 17, in run
output  = "Thread output " + str(self.nlst())[:30]
+" ..."
  File "C:\Python24\lib\ftplib.py", line 448, in nlst
self.retrlines(cmd, files.append)
  File "C:\Python24\lib\ftplib.py", line 396, in 
retrlines
conn = self.transfercmd(cmd)
  File "C:\Python24\lib\ftplib.py", line 345, in 
transfercmd
return self.ntransfercmd(cmd, rest)[0]
  File "C:\Python24\lib\ftplib.py", line 321, in 
ntransfercmd
host, port = self.makepasv()
  File "C:\Python24\lib\ftplib.py", line 299, in 
makepasv
host, port = parse227(self.sendcmd('PASV'))
  File "C:\Python24\lib\ftplib.py", line 566, in 
parse227
raise error_reply, resp
error_reply: 213 34603008

--

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-13 11:54

Message:
Logged In: YES 
user_id=580910

IMHO this isn't a bug, your accessing a shared resource (the FTP connection) 
from two threads without locking. Most of python's libraries aren't safe for 
this 
kind of use.

BTW. The fact that you subclass form thread and ftplib.FTP is immaterial, you 
will get the same effect if you create an ftplib.FTP and then use it in two 
threads.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1469557&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1529297 ] unrelated variable messing up doctests

[SourceForge.net]

Bugs item #1529297, was opened at 2006-07-26 18:02
Message generated for change (Comment added) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529297&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.5
Status: Open
Resolution: None
Priority: 5
Submitted By: David MacQuigg (macquigg)
Assigned to: Nobody/Anonymous (nobody)
Summary: unrelated variable messing up doctests

Initial Comment:
Version 2.5b2 with IDLE 1.2b2 running on Windows XP 
Home, fully updated.

Unpack the attached zip file.
Open program.py, test_suite.py, in separate IDLE 
windows.  
Run test_suite.py.  
  8 passed and 0 failed.
Now add a variable at the top of program.py, any name 
will do.
  xyz = 2
Re-run test_suite.py.  
  7 passed and 1 failed !!

I haven't been able to isolate the problem, but it is 
repeatable.  Taking out blocks of unrelated statements 
changes the behavior.  Feels like a memory allocation 
error, or something strange.


--

>Comment By: A.M. Kuchling (akuchling)
Date: 2006-07-27 08:15

Message:
Logged In: YES 
user_id=11375

On a Linux machine, both 2.4.3 and SVN HEAD report 7 tests
passed, one failed.

For both versions, the failure is: 
Failed example:
_envrcpt('[EMAIL PROTECTED]')
Expected:
CONTINUE [['[EMAIL PROTECTED]', 50, 2, 75, 101, '']]
Got:
CONTINUE [['[EMAIL PROTECTED]', 50, 2, 75, 50, '']]


--

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-26 23:59

Message:
Logged In: YES 
user_id=33168

Can you try with SVN head?  There was an unitialized read
that the doctests could trigger.  It has been fixed. 
Perhaps you are running into that?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529297&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1526834 ] unbalanced parentheses from command line crash pdb

[SourceForge.net]

Bugs item #1526834, was opened at 2006-07-22 00:03
Message generated for change (Comment added) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1526834&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: Ilya Sandler (isandler)
>Assigned to: A.M. Kuchling (akuchling)
Summary: unbalanced parentheses  from command line crash pdb

Initial Comment:
 bagira:~/python-svn/patches> cat simple
 print 123

 bagira:~/python-svn/patches> ../python/trunk/python -m
pdb simple

 (Pdb) b f(   #crashes your program
 Traceback (most recent call last):
 ...
  File "/home/ilya/python-svn/python/trunk/Lib/sre.py",  
  line 233, in _compile
raise error, v # invalid expression
 error: unbalanced parenthesis
 Uncaught exception. Entering post mortem debugging

 (Pdb) b f(   # doing it post-mortem fully crashes pdb
 Traceback (most recent call last):
 ..
raise error, v # invalid expression
 sre_constants.error: unbalanced parenthesis

 bagira:~/python-svn/patches>


--

>Comment By: A.M. Kuchling (akuchling)
Date: 2006-07-27 08:38

Message:
Logged In: YES 
user_id=11375

Easily fixed by adding a re.escape() call, but this means
that 'b f()', if you've been doing that, will no longer work
to set a breakpoint.  The documentation doesn't claim that
'b f()' should work, but people may be used to typing this.

I've asked the 2.5 release manager about this issue.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1526834&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1529655 ] BROWSER path with capital letters

[SourceForge.net]

Bugs item #1529655, was opened at 2006-07-28 00:55
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=1529655&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.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Ken McGaugh (kenmcgaugh)
Assigned to: Nobody/Anonymous (nobody)
Summary: BROWSER path with capital letters

Initial Comment:
If you set the BROWSER environment variable to a path
that has capital letters in it, the webbrowser module
will not work.  This is python 2.4.1 under Fedora Core 4
linux.


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529655&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1527974 ] tarfile chokes on ipython archive on Windows

[SourceForge.net]

Bugs item #1527974, was opened at 2006-07-24 23:00
Message generated for change (Comment added) made by arve_knudsen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1527974&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.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Arve Knudsen (arve_knudsen)
Assigned to: Nobody/Anonymous (nobody)
Summary: tarfile chokes on ipython archive on Windows

Initial Comment:
I'm trying to extract files from the latest ipython tar
archive, available from
http://ipython.scipy.org/dist/ipython-0.7.2.tar.gz,
using tarfile. This is on Windows XP, using Python
2.4.3. There is only a problem if I open the archive in
stream mode (the "mode" argument to tarfile.open is
"r|gz"), in which case tarfile raises StreamError. I'd
be happy if this error could be sorted out.

The following script should trigger the error:

import tarfile

f = file(r"ipython-0.7.2.tar.gz", "rb")
tar = tarfile.open(fileobj=f, mode="r|gz")
try:
for m in tar:
tar.extract(m)
finally:
tar.close()
f.close(

The resulting exception:
Traceback (most recent call last):
  File "tst.py", line 7, in ?
tar.extract(m)
  File "C:\Program Files\Python24\lib\tarfile.py", line
1335, in extract
self._extract_member(tarinfo, os.path.join(path,
tarinfo.name))
  File "C:\Program Files\Python24\lib\tarfile.py", line
1431, in _extract_member

self.makelink(tarinfo, targetpath)
  File "C:\Program Files\Python24\lib\tarfile.py", line
1515, in makelink
self._extract_member(self.getmember(linkpath),
targetpath)
  File "C:\Program Files\Python24\lib\tarfile.py", line
1423, in _extract_member

self.makefile(tarinfo, targetpath)
  File "C:\Program Files\Python24\lib\tarfile.py", line
1461, in makefile
copyfileobj(source, target)
  File "C:\Program Files\Python24\lib\tarfile.py", line
158, in copyfileobj
shutil.copyfileobj(src, dst)
  File "C:\Program Files\Python24\lib\shutil.py", line
22, in copyfileobj
buf = fsrc.read(length)
  File "C:\Program Files\Python24\lib\tarfile.py", line
551, in _readnormal
self.fileobj.seek(self.offset + self.pos)
  File "C:\Program Files\Python24\lib\tarfile.py", line
420, in seek
raise StreamError, "seeking backwards is not allowed"
tarfile.StreamError: seeking backwards is not allowed

--

>Comment By: Arve Knudsen (arve_knudsen)
Date: 2006-07-27 00:20

Message:
Logged In: YES 
user_id=1522083

Regarding my last comment, sorry about the noise. After 
giving it some more thought I realized it was not very 
realistic implementation wise, seeing as you can't know 
whether a file is being linked to when you encounter it in 
the stream (right?).

So I followed your suggestion instead and handled the links 
on the client level. What I think I'd like to see in 
TarFile though is an 'extractall' method with the ability 
to report progress to an optional callback, since I'm only 
opening in stream mode as a hack to implement this myself 
(by monitoring file position). From browsing tarfile's 
source it seems it might require some effort though (with 
e.g. BZ2File you can't know the amount of data without 
decompressing everything?).

--

Comment By: Arve Knudsen (arve_knudsen)
Date: 2006-07-25 11:58

Message:
Logged In: YES 
user_id=1522083

Yes I admit that is a weakness to my proposed approach.
Perhaps it would be a better idea to extract hardlinked
files to a temporary location and copy those files when
needed, as a cache? The only problem that I can think of
with this approach is the overhead, but perhaps this could
be configurable through a keyword if you think it would pose
a significant problem (i.e. keeping extra copies of
potentially huge files)?

The temporary cache would be private to tarfile, so there
should be no need to worry about modifications to the
contained files.

--

Comment By: Lars Gustäbel (gustaebel)
Date: 2006-07-25 11:31

Message:
Logged In: YES 
user_id=642936

Copying the previously extracted file is no option. When the
archive is extracted inside a loop, you never know what
happens between two extract() calls. The original file could
have been renamed, changed or removed. Suppose you want to
extract just those members which are hard links:

for tarinfo in tar:
if tarinfo.islnk():
tar.extract(tarinfo)

I agree with you that the error message is bad because it
does not give the slightest idea of what's going wrong. I'll
see what I can do about that.

To work around your particular problem, my idea is to
subclass the TarFile class and replace the makelink() method
with one that simply copies the file 

[ python-Bugs-1521947 ] possible bug in mystrtol.c with recent gcc

[SourceForge.net]

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: None
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-07-26 21: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 who has such a platform could
check against current Python trunk.

--

Comment By: Nick Maclaren (nmm)
Date: 2006-07-17 05:20

Message:
Logged In: YES 
user_id=42444

Yes, this is a duplicate of 1521726.

The compiler people's answer is correct, and mystrtoul.c is
incorrect. LONG_MIN has been in C since C90, so should be
safe, but its value may not always be what you expect.

However, the code breakage is worse that just that test, and
there are the following 3 cases of undefined behaviour:

1) Casting and unsigned long to long above LONG_MAX.
2) That test.
3) result = -result.

The fix should be to make result unsigned long, and check
the range BEFORE any conversion.  Nothing else is safe.

It is a matter of taste whether to include a fiddle for the
number that can be held only when negated - I wouldn't, and
would let that number be converted to a Python long, but
others might disagree.


--

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-16 21:13

Message:
Logged In: YES 
user_id=33168

Is this a duplicate of 1521726?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521947&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1529269 ] Python 2.5b2 fails to build on Solaris 10 (GCC Compiler)

[SourceForge.net]

Bugs item #1529269, was opened at 2006-07-26 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=1529269&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: Guido Ostkamp (ostkamp)
>Assigned to: Thomas Heller (theller)
Summary: Python 2.5b2 fails to build on Solaris 10 (GCC Compiler)

Initial Comment:
Hello,

as promised here is the second report because of
problems with building Python 2.5b2 on Solaris 10
(Sparc). I have been using the GCC this time.

These are the problems (for full logs please see
attachments):

building '_ctypes' extension
gcc -shared
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modules
/_ctypes/_ctypes.o
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/
Modules/_ctypes/callbacks.o
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Pyth
on-2.5b2/Modules/_ctypes/callproc.o
build/temp.solaris-2.10-sun4us-2.5/home/ostk
amp/Python-2.5b2/Modules/_ctypes/stgdict.o
build/temp.solaris-2.10-sun4us-2.5/ho
me/ostkamp/Python-2.5b2/Modules/_ctypes/cfield.o
build/temp.solaris-2.10-sun4us-
2.5/home/ostkamp/Python-2.5b2/Modules/_ctypes/malloc_closure.o
build/temp.solari
s-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/prep_cif.
o
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modules/_ctypes/l
ibffi/src/sparc/ffi.o
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5
b2/Modules/_ctypes/libffi/src/sparc/v8.o
build/temp.solaris-2.10-sun4us-2.5/home
/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v9.o
-o build/lib.solaris
-2.10-sun4us-2.5/_ctypes.so
ld: fatal: relocation error: R_SPARC_32: file
build/temp.solaris-2.10-sun4us-2.5
/home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o:
symbol : offset 0xfeedcca5 is non-aligned
ld: fatal: relocation error: R_SPARC_32: file
build/temp.solaris-2.10-sun4us-2.5
/home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o:
symbol : offset 0xfeedccab is non-aligned
ld: fatal: relocation error: R_SPARC_32: file
build/temp.solaris-2.10-sun4us-2.5
/home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o:
symbol : offset 0xfeedccaf is non-aligned
ld: fatal: relocation error: R_SPARC_32: file
build/temp.solaris-2.10-sun4us-2.5
/home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o:
symbol : offset 0xfeedccb3 is non-aligned
ld: fatal: relocation error: R_SPARC_32: file
build/temp.solaris-2.10-sun4us-2.5
/home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o:
symbol : offset 0xfeeeae06 is non-aligned
ld: fatal: relocation error: R_SPARC_32: file
build/temp.solaris-2.10-sun4us-2.5
/home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o:
symbol : offset 0xfeeecaf6 is non-aligned
collect2: ld returned 1 exit status

building '_curses' extension
gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall
-Wstrict-prototypes -I. -I/
home/ostkamp/Python-2.5b2/./Include -I./Include -I.
-I/home/ostkamp/Python-2.5b2
/Include -I/home/ostkamp/Python-2.5b2 -c
/home/ostkamp/Python-2.5b2/Modules/_cur
sesmodule.c -o
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modu
les/_cursesmodule.o
/home/ostkamp/Python-2.5b2/Modules/_cursesmodule.c: In
function `PyCursesWindow_
GetStr':
/home/ostkamp/Python-2.5b2/Modules/_cursesmodule.c:822:
warning: implicit declar
ation of function `mvwgetnstr'
gcc -shared
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modules
/_cursesmodule.o -lcurses -ltermcap -o
build/lib.solaris-2.10-sun4us-2.5/_curses
.so
*** WARNING: renaming "_curses" since importing it
failed: ld.so.1: python: fata
l: relocation error: file
build/lib.solaris-2.10-sun4us-2.5/_curses.so: symbol m
vwgetnstr: referenced symbol not found
building '_curses_panel' extension
gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall
-Wstrict-prototypes -I. -I/
home/ostkamp/Python-2.5b2/./Include -I./Include -I.
-I/home/ostkamp/Python-2.5b2
/Include -I/home/ostkamp/Python-2.5b2 -c
/home/ostkamp/Python-2.5b2/Modules/_cur
ses_panel.c -o
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modu
les/_curses_panel.o
gcc -shared
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modules
/_curses_panel.o -lpanel -lcurses -ltermcap -o
build/lib.solaris-2.10-sun4us-2.5
/_curses_panel.so
*** WARNING: renaming "_curses_panel" since importing
it failed: No module named
 _curses
running build_scripts

Regards,

Guido

--

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-26 20:21

Message:
Logged In: YES 
user_id=33168

Thomas can you check out the ctypes problems?

--

You can respond by visiting: 
h

[ python-Bugs-1513611 ] xml.sax.ParseException weirdness in python 2.5b1

[SourceForge.net]

Bugs item #1513611, was opened at 2006-06-27 17:06
Message generated for change (Comment added) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1513611&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: XML
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Marien Zwart (marienz)
Assigned to: Nobody/Anonymous (nobody)
Summary: xml.sax.ParseException weirdness in python 2.5b1

Initial Comment:
There is something weird going on with xml.sax
exceptions, probably related to the xml/xmlcore shuffle:

from xml.sax import make_parser, SAXParseException
from StringIO import StringIO

parser = make_parser()

try:
parser.parse(StringIO('invalid'))
except SAXParseException:
print 'caught it!'

On python 2.4.3 this prints "caught it!". On python
2.5b1 the exception is not caught, because it is a
different  exception: an
xmlcore.sax._exceptions.SAXParseException. Printing the
SAXParseException imported from xml.sax gives "".

Stumbled on this running the logilab-common (see
logilab.org) tests with python 2.5b1, but it seems
likely other code will be affected.

--

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-07-26 22:01

Message:
Logged In: YES 
user_id=3066

Patch #1519796 does not do anything for this, based on the
current trunk.  I've attached a diff containing a test case.

--

Comment By: Žiga Seilnacht (zseil)
Date: 2006-07-10 03:37

Message:
Logged In: YES 
user_id=1326842

This bug is simmilar to http://python.org/sf/1511497.
It is caused by absolute imports in xmlcore.sax.expatreader.
Patch #1519796 ( http://python.org/sf/1519796 )
should fix it.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1513611&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1069433 ] Python 2.4c1 test_univnewlines.py fails within IDLE IDE

[SourceForge.net]

Bugs item #1069433, was opened at 2004-11-19 09:33
Message generated for change (Comment added) made by kbk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1069433&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.4
>Status: Closed
>Resolution: Invalid
>Priority: 4
Submitted By: PieterB (pieterb)
Assigned to: Kurt B. Kaiser (kbk)
Summary: Python 2.4c1 test_univnewlines.py fails within IDLE IDE

Initial Comment:
On my WinXP SP 1 system with Python2.4c1.msi installed
the testcase test_univnewlines.py fails:

Traceback (most recent call last):
  File "C:\Python24\Lib\test\test_univnewlines.py",
line 8, in -toplevel-
raise test_support.TestSkipped, \
TestSkipped: This Python does not have universal
newline support

I assume Python on WinXP should have universal newline
support. This also causes 
test_subprocess.py to fail at line 334.

Furthermore my test_descr also fails, but I don't know
if it's related:

...
Testing methods...
Testing special operators...

Traceback (most recent call last):
  File "C:\Python24\Lib\test\test_descr.py", line 4065,
in -toplevel-
test_main()
  File "C:\Python24\Lib\test\test_descr.py", line 4008,
in test_main
specials()
  File "C:\Python24\Lib\test\test_descr.py", line 1875,
in specials
print Letter('w')
PicklingError: Can't pickle :
attribute lookup __main__.Letter failed

--

>Comment By: Kurt B. Kaiser (kbk)
Date: 2006-07-26 22:33

Message:
Logged In: YES 
user_id=149084

I don't expect IDLE to be able to pass all the
Python tests.  It does pretty well, considering it's
really two instances of Python communicating with
each other.

test_descr:  there is a special test which fails
which causes IDLE to try to pickle an embedded class,
which is illegal, to communicate with its GUI.

The test_subprocess passes on 2.5.

The universal newline support isn't included in IDLE
because as an editor, IDLE preserves the line endings
in the original file.  Any edits are done using the
'native' line endings for that file.  This allows IDLE
files on disc to be moved between different platforms.

If any failing tests are identified in the future which
affect IDLE's functionality or the correct execution of
'real' Python code, please post a bug on the tracker.

--

Comment By: Nick Coghlan (ncoghlan)
Date: 2004-11-23 04:07

Message:
Logged In: YES 
user_id=1038590

Ah, that makes a big difference - running through IDLE I get
the same three errors (failures in test_descr and
test_subprocess, skip on test_univnewlines).

I'd be inclined to keep the bug, but change the category to
IDLE and assign it to Kurt (SF user 'kbk'). IDLE's his baby
so he can make the call as to whether this is a bug, or
unfortunate but expected behaviour.


--

Comment By: PieterB (pieterb)
Date: 2004-11-22 17:13

Message:
Logged In: YES 
user_id=458461

I ran the tests through the IDLE IDE. All tests succeed when
I run regrtest.py from a command prompt or from with Cygwin
1.5.11. (240 tests OK, 50 tests skipped as expected) 

I don't know if running the tests and/or using universal
newlines support within IDLE is/will be supported. Please
close this bug if it's inappropriate.

For more information 
Python is not in the PATH and
TIX_LIBRARY=C:\Python24\tcl\tix8.1 and
TK_LIBRARY=C:\Python24\tcl\tk8.4

>From Python shell within IDLE:

>>> import sys
>>> dir(sys.stdin)
['_RPCProxy__attributes', '_RPCProxy__getattributes',
'_RPCProxy__getmethods', '_RPCProxy__methods', '__doc__',
'__getattr__', '__init__', '__module__', 'encoding', 'oid',
'sockio']
>>> print sys.stdin


>From a Python shell run from a command prompt:

>>> import sys
>>> dir(sys.stdin)
['__class__', '__delattr__', '__doc__', '__getattribute__',
'__hash__', '__init__', '__iter__', '__new__', '__reduce__',
'__reduce_ex__', '__repr__', '__setattr__', '__str__',
'close', 'closed', 'encoding', 'fileno', 'flush', 'isatty',
'mode', 'name', 'newlines', 'next', 'read', 'readinto',
'readline', 'readlines', 'seek', 'softspace', 'tell',
'truncate', 'write', 'writelines', 'xreadlines']
>>> print sys.stdin
', mode 'r' at 0x0095E020>

PS: I changed the summary because this problem is IDLE specific.

--

Comment By: Nick Coghlan (ncoghlan)
Date: 2004-11-22 08:51

Message:
Logged In: YES 
user_id=1038590

The three tests mentioned (test_univnewlines,
test_subprocess & test_descr) also all work correctly for me
when invoked directly, rather than through regrtest.py.


--

Comment By: Nick Coghlan (ncoghlan)
Date: 2004-11-22 07:1

[ python-Bugs-1521947 ] possible bug in mystrtol.c with recent gcc

[SourceForge.net]

Bugs item #1521947, was opened at 2006-07-13 10:39
Message generated for change (Comment added) made by nnorwitz
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: Neal Norwitz (nnorwitz)
Date: 2006-07-26 21: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-26 21: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-26 18: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 who has such a platform could
check against current Python trunk.

--

Comment By: Nick Maclaren (nmm)
Date: 2006-07-17 02:20

Message:
Logged In: YES 
user_id=42444

Yes, this is a duplicate of 1521726.

The compiler people's answer is correct, and mystrtoul.c is
incorrect. LONG_MIN has been in C since C90, so should be
safe, but its value may not always be what you expect.

However, the code breakage is worse that just that test, and
there are the following 3 cases of undefined behaviour:

1) Casting and unsigned long to long above LONG_MAX.
2) That test.
3) result = -result.

The fix should be to make result unsigned long, and check
the range BEFORE any conversion.  Nothing else is safe.

It is a matter of taste whether to include a fiddle for the
number that can be held only when negated - I wouldn't, and
would let that number be converted to a Python long, but
others might disagree.


--

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-16 18:13

Message:
Logged In: YES 
user_id=33168

Is this a duplicate of 1521726?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521947&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1528620 ] Python 2.5b2 fails to build on Solaris 10 (Sun Compiler)

[SourceForge.net]

Bugs item #1528620, was opened at 2006-07-25 13:34
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1528620&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: Guido Ostkamp (ostkamp)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.5b2 fails to build on Solaris 10 (Sun Compiler)

Initial Comment:
Hello,

I tried to build Python 2.5b2 on Solaris 10 with the
Sun Workshop Compiler, which fails.

Please see the attachment for a complete log in several
stages. Here is a short summary:

*
build/temp.solaris-2.10-sun4us-2.5/libffi/include/ffi.h
contains illegal C-syntax __attribute(...)

This might be legal for GCC, but not for other compilers. 

* Even if this is removed, there are other fatal
compiler errors in the _ctypes module later on.

* The build process seems to invoke _cursesmodule.c.
This contains the use of a function  mvwgetnstr(). This
function does not exist in /usr/lib/libcurses.so.

* The build process fails to link with libcurses.so.

The Python 2.4.3 release fails for the same reasons
regarding the curses problems, but the _ctypes stuff
did not exist in this form. 

I would appreciate, if these bugs could be fixed.

Regards,

Guido

--

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-26 20:20

Message:
Logged In: YES 
user_id=33168

Andrew Kuchling just checked in the change to fix the
problem.  The only way you would be able to verify it is if
you checkout from SVN head for 2.5 or release24-main for 2.4.

The only module that should depend on libffi is ctypes.  If
struct doesn't compile that is a different problem.

--

Comment By: Guido Ostkamp (ostkamp)
Date: 2006-07-26 13:52

Message:
Logged In: YES 
user_id=1028306

Hello,

@nnorwitz:

Unfortunately I cannot provide a patch, but can give some hints:

If you (or the developers) have a Solaris 10 box, they can
download the Sun Studio 11 which includes the Sun Compiler
for free from the URL:


Then you should be able to verify the problems yourself
(though I am using an older version of the compiler from the
times when it was commercial).

Regarding the _ctypes module problems:

The module contains a libffi which nowadays appears to be
part of the GNU GCC. This lib was never made to work with
anything else but GCC, as it seems. Even older versions do
not compile.

Therefore, if this module is not really necessary, it should
be removed or at least deactivated by the configuration if
not using GCC. It also seems, that other modules like
_struct appear to be depending on this, if I'm right.

Regarding the curses problem:

I can workaround this if changing the mvwgetnstr() to
mvwgetstr() with omitting the last parameter. However this
should be configured automatically.

Futhermore there was no linking of the correct library
(/usr/lib/libcurses.so). I had to activate the curses entry
in Modules/Setup manually and to call make two more times. 

Regarding GCC on Solaris: I tried with GCC but it failed on
Solaris 10 as well. I will open a new fault report for the
GCC problems.

@akuchling:

You say the curses bug should be fixed in 2.4 and 2.5. It
isn't. I tried 2.4.3 yesterday as well and ran into the very
same problem. Or do you mean it was changed more recently?



--

Comment By: A.M. Kuchling (akuchling)
Date: 2006-07-26 10:28

Message:
Logged In: YES 
user_id=11375

The _cursesmodule mvwgetnstr() problem was reported as bug
#1471938 and should now be fixed on both the 2.4 and 2.5
branches.



--

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-25 21:11

Message:
Logged In: YES 
user_id=33168

Can you provide a patch to address these problems?

I don't know that any developers have access to the sun
workshop compiler.  We have a Solaris 10 box, but it only
has gcc AFAIK.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1528620&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1511497 ] xml.sax.expatreader is missing

[SourceForge.net]

Bugs item #1511497, was opened at 2006-06-23 11:14
Message generated for change (Settings changed) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1511497&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: XML
Group: Python 2.5
Status: Open
Resolution: None
>Priority: 9
Submitted By: Wummel (calvin)
Assigned to: Nobody/Anonymous (nobody)
Summary: xml.sax.expatreader is missing

Initial Comment:
Hi,

when testing the new Python 2.5 subversion tree I
encountered this behaviour:
$ python2.5
Python 2.5b1 (trunk:47065, Jun 22 2006, 20:56:23) 
[GCC 4.1.2 20060613 (prerelease) (Debian 4.1.1-5)] on
linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import xml.sax.expatreader
>>> print xml.sax.expatreader
Traceback (most recent call last):
  File "", line 1, in 
AttributeError: 'module' object has no attribute
'expatreader'
>>> 

So the import went ok, but using the attribute gave an
error. This is very strange. Python 2.4 did not have
this behaviour.

--

Comment By: Žiga Seilnacht (zseil)
Date: 2006-07-10 00:38

Message:
Logged In: YES 
user_id=1326842

See patch #1519796:
http://python.org/sf/1519796

--

Comment By: Žiga Seilnacht (zseil)
Date: 2006-06-26 15:52

Message:
Logged In: YES 
user_id=1326842

I see the same behaviour with the official Python 2.5
beta 1 Windows installer. The interesting thing is that
the expatreader module is present in sys.modules:

Python 2.5b1 (r25b1:47027, Jun 20 2006, 09:31:33)
[MSC v.1310 32 bit (Intel)] on win32
...
>>> import xml.sax.expatreader
>>> xml.sax.expatreader
Traceback (most recent call last):
  ...
AttributeError: 'module' object has no attribute 'expatreader'
>>> import sys
>>> sys.modules['xml.sax.expatreader']


All of the other modules in xml package can be imported
without any trouble.
I don't understand what is the real problem here,
but it goes away if you import xmlcore.sax package
before expatreader:

[restart python]
>>> import xmlcore.sax
>>> import xml.sax.expatreader
>>> xml.sax.expatreader


The simplest fix would be to use at least one absolute
import in ...\lib\xmlcore\sax\__init__.py, for example
you could change line 22:

from xmlreader import InputSource

to:

from xmlcore.sax.xmlreader import InputSource

but that might just hide the real bug.

--

Comment By: Wummel (calvin)
Date: 2006-06-26 11:15

Message:
Logged In: YES 
user_id=9205

I built Python directly from the SVN trunk repository with
$ ./configure && make altinstall
I attached the pyconfig.h that was generated. If you need
more info, feel free to ask.

After building and installing, I started up python2.5 and
executed "import xml.sax.expatreader" and then "print
xml.sax.expatreader", and nothing else.

Another thing I tried is "import from", which works.
But importing xml.sax.expatreader directly, as noted above,
does not work.

Here is the log with the "import from" test:
Python 2.5b1 (trunk:47090, Jun 25 2006, 09:59:02) 
[GCC 4.1.2 20060613 (prerelease) (Debian 4.1.1-5)] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
>>> from xml.sax import expatreader
>>> print expatreader

>>> print xml.sax.expatreader
Traceback (most recent call last):
  File "", line 1, in 
AttributeError: 'module' object has no attribute 'expatreader'


--

Comment By: Martin v. Löwis (loewis)
Date: 2006-06-24 03:39

Message:
Logged In: YES 
user_id=21627

How precisely did you test it? What configure options did
you set up, what commands did you provide to build Python?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1511497&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1529717 ] doc string of read-only properties

[SourceForge.net]

Bugs item #1529717, was opened at 2006-07-27 16:11
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=1529717&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: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Amrhein (mamrhein)
Assigned to: Nobody/Anonymous (nobody)
Summary: doc string of read-only properties

Initial Comment:
It would be nice if read-only properties (only fget
defined) that have no doc string assigned would
automatically show the doc string of the fget function.
This would allow to write code like
@property
def prop(self):
"""Property prop"""
...
while making the doc string visible at the property level.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529717&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1529717 ] doc string of read-only properties

[SourceForge.net]

Bugs item #1529717, was opened at 2006-07-27 14:11
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529717&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: Feature Request
>Status: Closed
>Resolution: Out of Date
Priority: 5
Submitted By: Michael Amrhein (mamrhein)
Assigned to: Nobody/Anonymous (nobody)
Summary: doc string of read-only properties

Initial Comment:
It would be nice if read-only properties (only fget
defined) that have no doc string assigned would
automatically show the doc string of the fget function.
This would allow to write code like
@property
def prop(self):
"""Property prop"""
...
while making the doc string visible at the property level.

--

>Comment By: Georg Brandl (gbrandl)
Date: 2006-07-27 15:03

Message:
Logged In: YES 
user_id=849994

This is already in 2.5.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529717&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1529655 ] BROWSER path with capital letters

[SourceForge.net]

Bugs item #1529655, was opened at 2006-07-27 12:55
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529655&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.4
>Status: Pending
>Resolution: Fixed
Priority: 5
Submitted By: Ken McGaugh (kenmcgaugh)
Assigned to: Nobody/Anonymous (nobody)
Summary: BROWSER path with capital letters

Initial Comment:
If you set the BROWSER environment variable to a path
that has capital letters in it, the webbrowser module
will not work.  This is python 2.4.1 under Fedora Core 4
linux.


--

>Comment By: Georg Brandl (gbrandl)
Date: 2006-07-27 15:07

Message:
Logged In: YES 
user_id=849994

webbrowser was almost completely rewritten in 2.5. I guess
that problem will go away then.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529655&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1529297 ] unrelated variable messing up doctests

[SourceForge.net]

Bugs item #1529297, was opened at 2006-07-26 15:02
Message generated for change (Comment added) made by macquigg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529297&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.5
Status: Open
Resolution: None
Priority: 5
Submitted By: David MacQuigg (macquigg)
Assigned to: Nobody/Anonymous (nobody)
Summary: unrelated variable messing up doctests

Initial Comment:
Version 2.5b2 with IDLE 1.2b2 running on Windows XP 
Home, fully updated.

Unpack the attached zip file.
Open program.py, test_suite.py, in separate IDLE 
windows.  
Run test_suite.py.  
  8 passed and 0 failed.
Now add a variable at the top of program.py, any name 
will do.
  xyz = 2
Re-run test_suite.py.  
  7 passed and 1 failed !!

I haven't been able to isolate the problem, but it is 
repeatable.  Taking out blocks of unrelated statements 
changes the behavior.  Feels like a memory allocation 
error, or something strange.


--

>Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 08:22

Message:
Logged In: YES 
user_id=676422

On my Redhat Linux machine, I see the failure in 2.4.1, but 
not in 2.3.4.

Trying to isolate the problem, I've commented out some 
blocks of unrelated code, but I can't get very far with 
this, because many of the deletions make the problem go 
away.  It's as if the problem depends on the exact position 
in memory of the test variable.

I did manage to delete the DNS queries, so now you can run 
the tests without intermittent failures due to DNS timeouts.
I'll keep the latest at http://www.open-
mail.org/test/test_0607nn.tgz

Thanks for your efforts.


--

Comment By: A.M. Kuchling (akuchling)
Date: 2006-07-27 05:15

Message:
Logged In: YES 
user_id=11375

On a Linux machine, both 2.4.3 and SVN HEAD report 7 tests
passed, one failed.

For both versions, the failure is: 
Failed example:
_envrcpt('[EMAIL PROTECTED]')
Expected:
CONTINUE [['[EMAIL PROTECTED]', 50, 2, 75, 101, '']]
Got:
CONTINUE [['[EMAIL PROTECTED]', 50, 2, 75, 50, '']]


--

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-26 20:59

Message:
Logged In: YES 
user_id=33168

Can you try with SVN head?  There was an unitialized read
that the doctests could trigger.  It has been fixed. 
Perhaps you are running into that?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529297&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1529297 ] unrelated variable messing up doctests

[SourceForge.net]

Bugs item #1529297, was opened at 2006-07-26 18:02
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529297&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.5
Status: Open
Resolution: None
Priority: 5
Submitted By: David MacQuigg (macquigg)
Assigned to: Nobody/Anonymous (nobody)
Summary: unrelated variable messing up doctests

Initial Comment:
Version 2.5b2 with IDLE 1.2b2 running on Windows XP 
Home, fully updated.

Unpack the attached zip file.
Open program.py, test_suite.py, in separate IDLE 
windows.  
Run test_suite.py.  
  8 passed and 0 failed.
Now add a variable at the top of program.py, any name 
will do.
  xyz = 2
Re-run test_suite.py.  
  7 passed and 1 failed !!

I haven't been able to isolate the problem, but it is 
repeatable.  Taking out blocks of unrelated statements 
changes the behavior.  Feels like a memory allocation 
error, or something strange.


--

>Comment By: Tim Peters (tim_one)
Date: 2006-07-27 12:14

Message:
Logged In: YES 
user_id=31435

I see exactly the same failure akuchling reported, on
Windows using current trunk, running from a command shell
(not IDLE -- didn't try IDLE).  The attached test_suite.py
throws away everything not needed to see the same failure;
in particular, it gets rid of doctest, the logging module,
and most of the functions in test_suite.py.

Reduced to this, I don't see a reason to suspect a Python
bug.  ci.IDrating is initialized to 100, and the

_envrcpt('[EMAIL PROTECTED]')

line produces (the expected)

CONTINUE [['[EMAIL PROTECTED]', 50, 2, 75, 101, '']]

if you /leave ci.IDrating alone/.  However, if you do

ci.hello('zz_IP_192.168.0.8_mailout7.simple.tld')

first, that has a (apparently deliberate) side effect of
changing ci.IDrating to None, and then this path is /not/ taken:

# . . Whitelist pass
if self.IDrating > whitelvl:
rcptinfo[4] = 101  # ham > 100% to ignore later
spamscore   ###2e
self.R.append(rcptinfo)

The 101 vanishes from the expected output then, and I get

CONTINUE [['[EMAIL PROTECTED]', 50, 2, 75, 50, '']]

instead.

That exactly reproduces the only failure Andrew & I have
seen, and appears to be what the code is telling it to do
(via side effects on the shared `ci` instance).

--

Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 11:22

Message:
Logged In: YES 
user_id=676422

On my Redhat Linux machine, I see the failure in 2.4.1, but 
not in 2.3.4.

Trying to isolate the problem, I've commented out some 
blocks of unrelated code, but I can't get very far with 
this, because many of the deletions make the problem go 
away.  It's as if the problem depends on the exact position 
in memory of the test variable.

I did manage to delete the DNS queries, so now you can run 
the tests without intermittent failures due to DNS timeouts.
I'll keep the latest at http://www.open-
mail.org/test/test_0607nn.tgz

Thanks for your efforts.


--

Comment By: A.M. Kuchling (akuchling)
Date: 2006-07-27 08:15

Message:
Logged In: YES 
user_id=11375

On a Linux machine, both 2.4.3 and SVN HEAD report 7 tests
passed, one failed.

For both versions, the failure is: 
Failed example:
_envrcpt('[EMAIL PROTECTED]')
Expected:
CONTINUE [['[EMAIL PROTECTED]', 50, 2, 75, 101, '']]
Got:
CONTINUE [['[EMAIL PROTECTED]', 50, 2, 75, 50, '']]


--

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-26 23:59

Message:
Logged In: YES 
user_id=33168

Can you try with SVN head?  There was an unitialized read
that the doctests could trigger.  It has been fixed. 
Perhaps you are running into that?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529297&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1529269 ] Python 2.5b2 fails to build on Solaris 10 (GCC Compiler)

[SourceForge.net]

Bugs item #1529269, was opened at 2006-07-26 23:17
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529269&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: Guido Ostkamp (ostkamp)
Assigned to: Thomas Heller (theller)
Summary: Python 2.5b2 fails to build on Solaris 10 (GCC Compiler)

Initial Comment:
Hello,

as promised here is the second report because of
problems with building Python 2.5b2 on Solaris 10
(Sparc). I have been using the GCC this time.

These are the problems (for full logs please see
attachments):

building '_ctypes' extension
gcc -shared
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modules
/_ctypes/_ctypes.o
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/
Modules/_ctypes/callbacks.o
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Pyth
on-2.5b2/Modules/_ctypes/callproc.o
build/temp.solaris-2.10-sun4us-2.5/home/ostk
amp/Python-2.5b2/Modules/_ctypes/stgdict.o
build/temp.solaris-2.10-sun4us-2.5/ho
me/ostkamp/Python-2.5b2/Modules/_ctypes/cfield.o
build/temp.solaris-2.10-sun4us-
2.5/home/ostkamp/Python-2.5b2/Modules/_ctypes/malloc_closure.o
build/temp.solari
s-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/prep_cif.
o
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modules/_ctypes/l
ibffi/src/sparc/ffi.o
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5
b2/Modules/_ctypes/libffi/src/sparc/v8.o
build/temp.solaris-2.10-sun4us-2.5/home
/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v9.o
-o build/lib.solaris
-2.10-sun4us-2.5/_ctypes.so
ld: fatal: relocation error: R_SPARC_32: file
build/temp.solaris-2.10-sun4us-2.5
/home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o:
symbol : offset 0xfeedcca5 is non-aligned
ld: fatal: relocation error: R_SPARC_32: file
build/temp.solaris-2.10-sun4us-2.5
/home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o:
symbol : offset 0xfeedccab is non-aligned
ld: fatal: relocation error: R_SPARC_32: file
build/temp.solaris-2.10-sun4us-2.5
/home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o:
symbol : offset 0xfeedccaf is non-aligned
ld: fatal: relocation error: R_SPARC_32: file
build/temp.solaris-2.10-sun4us-2.5
/home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o:
symbol : offset 0xfeedccb3 is non-aligned
ld: fatal: relocation error: R_SPARC_32: file
build/temp.solaris-2.10-sun4us-2.5
/home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o:
symbol : offset 0xfeeeae06 is non-aligned
ld: fatal: relocation error: R_SPARC_32: file
build/temp.solaris-2.10-sun4us-2.5
/home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o:
symbol : offset 0xfeeecaf6 is non-aligned
collect2: ld returned 1 exit status

building '_curses' extension
gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall
-Wstrict-prototypes -I. -I/
home/ostkamp/Python-2.5b2/./Include -I./Include -I.
-I/home/ostkamp/Python-2.5b2
/Include -I/home/ostkamp/Python-2.5b2 -c
/home/ostkamp/Python-2.5b2/Modules/_cur
sesmodule.c -o
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modu
les/_cursesmodule.o
/home/ostkamp/Python-2.5b2/Modules/_cursesmodule.c: In
function `PyCursesWindow_
GetStr':
/home/ostkamp/Python-2.5b2/Modules/_cursesmodule.c:822:
warning: implicit declar
ation of function `mvwgetnstr'
gcc -shared
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modules
/_cursesmodule.o -lcurses -ltermcap -o
build/lib.solaris-2.10-sun4us-2.5/_curses
.so
*** WARNING: renaming "_curses" since importing it
failed: ld.so.1: python: fata
l: relocation error: file
build/lib.solaris-2.10-sun4us-2.5/_curses.so: symbol m
vwgetnstr: referenced symbol not found
building '_curses_panel' extension
gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall
-Wstrict-prototypes -I. -I/
home/ostkamp/Python-2.5b2/./Include -I./Include -I.
-I/home/ostkamp/Python-2.5b2
/Include -I/home/ostkamp/Python-2.5b2 -c
/home/ostkamp/Python-2.5b2/Modules/_cur
ses_panel.c -o
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modu
les/_curses_panel.o
gcc -shared
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modules
/_curses_panel.o -lpanel -lcurses -ltermcap -o
build/lib.solaris-2.10-sun4us-2.5
/_curses_panel.so
*** WARNING: renaming "_curses_panel" since importing
it failed: No module named
 _curses
running build_scripts

Regards,

Guido

--

>Comment By: Thomas Heller (theller)
Date: 2006-07-27 19:23

Message:
Logged In: YES 
user_id=11105

I don't have access to a solaris 10 box myself (only the
sourceforge solaris 9 sparc machine).  I'm wondering why the
solaris 10 machine running the Pyt

[ python-Bugs-1529297 ] unrelated variable messing up doctests

[SourceForge.net]

Bugs item #1529297, was opened at 2006-07-26 15:02
Message generated for change (Comment added) made by macquigg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529297&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.5
Status: Open
Resolution: None
Priority: 5
Submitted By: David MacQuigg (macquigg)
Assigned to: Nobody/Anonymous (nobody)
Summary: unrelated variable messing up doctests

Initial Comment:
Version 2.5b2 with IDLE 1.2b2 running on Windows XP 
Home, fully updated.

Unpack the attached zip file.
Open program.py, test_suite.py, in separate IDLE 
windows.  
Run test_suite.py.  
  8 passed and 0 failed.
Now add a variable at the top of program.py, any name 
will do.
  xyz = 2
Re-run test_suite.py.  
  7 passed and 1 failed !!

I haven't been able to isolate the problem, but it is 
repeatable.  Taking out blocks of unrelated statements 
changes the behavior.  Feels like a memory allocation 
error, or something strange.


--

>Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 10:32

Message:
Logged In: YES 
user_id=676422

The failure is not the specific output of doctest, but the 
fact that it *changes* when I add an unrelated variable 
xyz=2 in the module program.py.  I am not able to reproduce 
this failure with Tim's stripped down test_suite.py.

I agree the problem is not in IDLE.  I can do the same from 
a bash command line with
$ python2.4 test_suite.py
but not with 
$ python2.3 test_suite.py


--

Comment By: Tim Peters (tim_one)
Date: 2006-07-27 09:14

Message:
Logged In: YES 
user_id=31435

I see exactly the same failure akuchling reported, on
Windows using current trunk, running from a command shell
(not IDLE -- didn't try IDLE).  The attached test_suite.py
throws away everything not needed to see the same failure;
in particular, it gets rid of doctest, the logging module,
and most of the functions in test_suite.py.

Reduced to this, I don't see a reason to suspect a Python
bug.  ci.IDrating is initialized to 100, and the

_envrcpt('[EMAIL PROTECTED]')

line produces (the expected)

CONTINUE [['[EMAIL PROTECTED]', 50, 2, 75, 101, '']]

if you /leave ci.IDrating alone/.  However, if you do

ci.hello('zz_IP_192.168.0.8_mailout7.simple.tld')

first, that has a (apparently deliberate) side effect of
changing ci.IDrating to None, and then this path is /not/ taken:

# . . Whitelist pass
if self.IDrating > whitelvl:
rcptinfo[4] = 101  # ham > 100% to ignore later
spamscore   ###2e
self.R.append(rcptinfo)

The 101 vanishes from the expected output then, and I get

CONTINUE [['[EMAIL PROTECTED]', 50, 2, 75, 50, '']]

instead.

That exactly reproduces the only failure Andrew & I have
seen, and appears to be what the code is telling it to do
(via side effects on the shared `ci` instance).

--

Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 08:22

Message:
Logged In: YES 
user_id=676422

On my Redhat Linux machine, I see the failure in 2.4.1, but 
not in 2.3.4.

Trying to isolate the problem, I've commented out some 
blocks of unrelated code, but I can't get very far with 
this, because many of the deletions make the problem go 
away.  It's as if the problem depends on the exact position 
in memory of the test variable.

I did manage to delete the DNS queries, so now you can run 
the tests without intermittent failures due to DNS timeouts.
I'll keep the latest at http://www.open-
mail.org/test/test_0607nn.tgz

Thanks for your efforts.


--

Comment By: A.M. Kuchling (akuchling)
Date: 2006-07-27 05:15

Message:
Logged In: YES 
user_id=11375

On a Linux machine, both 2.4.3 and SVN HEAD report 7 tests
passed, one failed.

For both versions, the failure is: 
Failed example:
_envrcpt('[EMAIL PROTECTED]')
Expected:
CONTINUE [['[EMAIL PROTECTED]', 50, 2, 75, 101, '']]
Got:
CONTINUE [['[EMAIL PROTECTED]', 50, 2, 75, 50, '']]


--

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-26 20:59

Message:
Logged In: YES 
user_id=33168

Can you try with SVN head?  There was an unitialized read
that the doctests could trigger.  It has been fixed. 
Perhaps you are running into that?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529297&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive

[ python-Bugs-1529871 ] distutils regression related to Distribution.run_command

[SourceForge.net]

Bugs item #1529871, was opened at 2006-07-27 13:49
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=1529871&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: Collin Winter (collinwinter)
Assigned to: Nobody/Anonymous (nobody)
Summary: distutils regression related to Distribution.run_command

Initial Comment:
The following used to work in Python 2.4.x but fails
under Python 2.5:

>>> import setuptools
>>> import distutils.core
>>> distutils.core._setup_stop_after = 'config'
>>> 
>>> import setup
>>> setup.dist.run_command('test')

Where setup.dist is an instance of
distutils.core.Distribution (which setuptools replaces
with setuptools.dist.Distribution).

Under Python 2.4.x, this code would execute setuptools'
test command. Under Python 2.5b2 (as of r50855), this
code results in the following exception:

/opt/dev/python/2.5/lib/python2.5/distutils/dist.py:263:
UserWarning: Unknown distribution option: 'test_suite'
  warnings.warn(msg)
Traceback (most recent call last):
  File "test.py", line 8, in 
setup.dist.run_command('test')
  File
"/opt/dev/python/2.5/lib/python2.5/distutils/dist.py",
line 992, in run_command
cmd_obj = self.get_command_obj(command)
  File
"/opt/dev/python/2.5/lib/python2.5/distutils/dist.py",
line 868, in get_command_obj
klass = self.get_command_class(command)
  File
"/opt/dev/python/2.5/lib/python2.5/site-packages/setuptools/dist.py",
line 357, in get_command_class
return _Distribution.get_command_class(self, command)
  File
"/opt/dev/python/2.5/lib/python2.5/distutils/dist.py",
line 851, in get_command_class
raise DistutilsModuleError("invalid command '%s'" %
command)
distutils.errors.DistutilsModuleError: invalid command
'test'

I'd greatly appreciate it if this regression could be
fixed before Python 2.5 is released.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529871&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1529871 ] distutils regression related to Distribution.run_command

[SourceForge.net]

Bugs item #1529871, was opened at 2006-07-27 13:49
Message generated for change (Settings changed) made by collinwinter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529871&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: 6
Submitted By: Collin Winter (collinwinter)
Assigned to: Nobody/Anonymous (nobody)
Summary: distutils regression related to Distribution.run_command

Initial Comment:
The following used to work in Python 2.4.x but fails
under Python 2.5:

>>> import setuptools
>>> import distutils.core
>>> distutils.core._setup_stop_after = 'config'
>>> 
>>> import setup
>>> setup.dist.run_command('test')

Where setup.dist is an instance of
distutils.core.Distribution (which setuptools replaces
with setuptools.dist.Distribution).

Under Python 2.4.x, this code would execute setuptools'
test command. Under Python 2.5b2 (as of r50855), this
code results in the following exception:

/opt/dev/python/2.5/lib/python2.5/distutils/dist.py:263:
UserWarning: Unknown distribution option: 'test_suite'
  warnings.warn(msg)
Traceback (most recent call last):
  File "test.py", line 8, in 
setup.dist.run_command('test')
  File
"/opt/dev/python/2.5/lib/python2.5/distutils/dist.py",
line 992, in run_command
cmd_obj = self.get_command_obj(command)
  File
"/opt/dev/python/2.5/lib/python2.5/distutils/dist.py",
line 868, in get_command_obj
klass = self.get_command_class(command)
  File
"/opt/dev/python/2.5/lib/python2.5/site-packages/setuptools/dist.py",
line 357, in get_command_class
return _Distribution.get_command_class(self, command)
  File
"/opt/dev/python/2.5/lib/python2.5/distutils/dist.py",
line 851, in get_command_class
raise DistutilsModuleError("invalid command '%s'" %
command)
distutils.errors.DistutilsModuleError: invalid command
'test'

I'd greatly appreciate it if this regression could be
fixed before Python 2.5 is released.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529871&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1529871 ] distutils regression related to Distribution.run_command

[SourceForge.net]

Bugs item #1529871, was opened at 2006-07-27 13:49
Message generated for change (Comment added) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529871&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: 6
Submitted By: Collin Winter (collinwinter)
>Assigned to: Phillip J. Eby (pje)
Summary: distutils regression related to Distribution.run_command

Initial Comment:
The following used to work in Python 2.4.x but fails
under Python 2.5:

>>> import setuptools
>>> import distutils.core
>>> distutils.core._setup_stop_after = 'config'
>>> 
>>> import setup
>>> setup.dist.run_command('test')

Where setup.dist is an instance of
distutils.core.Distribution (which setuptools replaces
with setuptools.dist.Distribution).

Under Python 2.4.x, this code would execute setuptools'
test command. Under Python 2.5b2 (as of r50855), this
code results in the following exception:

/opt/dev/python/2.5/lib/python2.5/distutils/dist.py:263:
UserWarning: Unknown distribution option: 'test_suite'
  warnings.warn(msg)
Traceback (most recent call last):
  File "test.py", line 8, in 
setup.dist.run_command('test')
  File
"/opt/dev/python/2.5/lib/python2.5/distutils/dist.py",
line 992, in run_command
cmd_obj = self.get_command_obj(command)
  File
"/opt/dev/python/2.5/lib/python2.5/distutils/dist.py",
line 868, in get_command_obj
klass = self.get_command_class(command)
  File
"/opt/dev/python/2.5/lib/python2.5/site-packages/setuptools/dist.py",
line 357, in get_command_class
return _Distribution.get_command_class(self, command)
  File
"/opt/dev/python/2.5/lib/python2.5/distutils/dist.py",
line 851, in get_command_class
raise DistutilsModuleError("invalid command '%s'" %
command)
distutils.errors.DistutilsModuleError: invalid command
'test'

I'd greatly appreciate it if this regression could be
fixed before Python 2.5 is released.

--

>Comment By: A.M. Kuchling (akuchling)
Date: 2006-07-27 14:03

Message:
Logged In: YES 
user_id=11375

Assigned to Phillip.  I don't see any obviously relevant
changes to distutils/dist.py, but maybe this problems stems
from changes to some other module.


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529871&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1529871 ] distutils regression related to Distribution.run_command

[SourceForge.net]

Bugs item #1529871, was opened at 2006-07-27 13:49
Message generated for change (Comment added) made by collinwinter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529871&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: 6
Submitted By: Collin Winter (collinwinter)
Assigned to: Phillip J. Eby (pje)
Summary: distutils regression related to Distribution.run_command

Initial Comment:
The following used to work in Python 2.4.x but fails
under Python 2.5:

>>> import setuptools
>>> import distutils.core
>>> distutils.core._setup_stop_after = 'config'
>>> 
>>> import setup
>>> setup.dist.run_command('test')

Where setup.dist is an instance of
distutils.core.Distribution (which setuptools replaces
with setuptools.dist.Distribution).

Under Python 2.4.x, this code would execute setuptools'
test command. Under Python 2.5b2 (as of r50855), this
code results in the following exception:

/opt/dev/python/2.5/lib/python2.5/distutils/dist.py:263:
UserWarning: Unknown distribution option: 'test_suite'
  warnings.warn(msg)
Traceback (most recent call last):
  File "test.py", line 8, in 
setup.dist.run_command('test')
  File
"/opt/dev/python/2.5/lib/python2.5/distutils/dist.py",
line 992, in run_command
cmd_obj = self.get_command_obj(command)
  File
"/opt/dev/python/2.5/lib/python2.5/distutils/dist.py",
line 868, in get_command_obj
klass = self.get_command_class(command)
  File
"/opt/dev/python/2.5/lib/python2.5/site-packages/setuptools/dist.py",
line 357, in get_command_class
return _Distribution.get_command_class(self, command)
  File
"/opt/dev/python/2.5/lib/python2.5/distutils/dist.py",
line 851, in get_command_class
raise DistutilsModuleError("invalid command '%s'" %
command)
distutils.errors.DistutilsModuleError: invalid command
'test'

I'd greatly appreciate it if this regression could be
fixed before Python 2.5 is released.

--

>Comment By: Collin Winter (collinwinter)
Date: 2006-07-27 14:18

Message:
Logged In: YES 
user_id=1344176

Forgot to mention: I've tried this with setuptools 0.6a9 and
0.6c1. Python 2.4.x (2.4.1, 2.4.2 and 2.4.3 tested) with
both setuptools version worked fine, where Python 2.5b2
fails with both.

--

Comment By: A.M. Kuchling (akuchling)
Date: 2006-07-27 14:03

Message:
Logged In: YES 
user_id=11375

Assigned to Phillip.  I don't see any obviously relevant
changes to distutils/dist.py, but maybe this problems stems
from changes to some other module.


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529871&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1529871 ] distutils regression related to Distribution.run_command

[SourceForge.net]

Bugs item #1529871, was opened at 2006-07-27 13:49
Message generated for change (Comment added) made by collinwinter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529871&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: 6
Submitted By: Collin Winter (collinwinter)
Assigned to: Phillip J. Eby (pje)
Summary: distutils regression related to Distribution.run_command

Initial Comment:
The following used to work in Python 2.4.x but fails
under Python 2.5:

>>> import setuptools
>>> import distutils.core
>>> distutils.core._setup_stop_after = 'config'
>>> 
>>> import setup
>>> setup.dist.run_command('test')

Where setup.dist is an instance of
distutils.core.Distribution (which setuptools replaces
with setuptools.dist.Distribution).

Under Python 2.4.x, this code would execute setuptools'
test command. Under Python 2.5b2 (as of r50855), this
code results in the following exception:

/opt/dev/python/2.5/lib/python2.5/distutils/dist.py:263:
UserWarning: Unknown distribution option: 'test_suite'
  warnings.warn(msg)
Traceback (most recent call last):
  File "test.py", line 8, in 
setup.dist.run_command('test')
  File
"/opt/dev/python/2.5/lib/python2.5/distutils/dist.py",
line 992, in run_command
cmd_obj = self.get_command_obj(command)
  File
"/opt/dev/python/2.5/lib/python2.5/distutils/dist.py",
line 868, in get_command_obj
klass = self.get_command_class(command)
  File
"/opt/dev/python/2.5/lib/python2.5/site-packages/setuptools/dist.py",
line 357, in get_command_class
return _Distribution.get_command_class(self, command)
  File
"/opt/dev/python/2.5/lib/python2.5/distutils/dist.py",
line 851, in get_command_class
raise DistutilsModuleError("invalid command '%s'" %
command)
distutils.errors.DistutilsModuleError: invalid command
'test'

I'd greatly appreciate it if this regression could be
fixed before Python 2.5 is released.

--

>Comment By: Collin Winter (collinwinter)
Date: 2006-07-27 14:34

Message:
Logged In: YES 
user_id=1344176

Further testing reveals that all of setuptools' extension
commands (tested: egg_info, bdist_egg, test, rotate, alias)
are broken under Python 2.5b2, even when called from the
command line, like so:

$ python2.5 setup.py egg_info

This produces an "error: invalid command: 'egg_info'" message.

--

Comment By: Collin Winter (collinwinter)
Date: 2006-07-27 14:18

Message:
Logged In: YES 
user_id=1344176

Forgot to mention: I've tried this with setuptools 0.6a9 and
0.6c1. Python 2.4.x (2.4.1, 2.4.2 and 2.4.3 tested) with
both setuptools version worked fine, where Python 2.5b2
fails with both.

--

Comment By: A.M. Kuchling (akuchling)
Date: 2006-07-27 14:03

Message:
Logged In: YES 
user_id=11375

Assigned to Phillip.  I don't see any obviously relevant
changes to distutils/dist.py, but maybe this problems stems
from changes to some other module.


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529871&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1525447 ] Build fails on OS X with case sensitive fs

[SourceForge.net]

Bugs item #1525447, was opened at 2006-07-19 19:24
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1525447&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: Fixed
Priority: 6
Submitted By: gideon may (gdm)
Assigned to: Ronald Oussoren (ronaldoussoren)
Summary: Build fails on OS X with case sensitive fs

Initial Comment:
When compiling python from svn on a Mac OS X with a 
case sensitive file system I get the following build
error:

running build
running build_ext
db.h: found (4, 3) in /opt/local/include/db4
db lib: using (4, 3) db-4.3
sqlite: found /usr/include/sqlite3.h
/usr/include/sqlite3.h: version 3.1.3
Traceback (most recent call last):
  File "./setup.py", line 1507, in 
main()
.
.
  File "./setup.py", line 1088, in addMacExtension
raise RuntimeError("%s not found" % name)
RuntimeError: MacOS not found
make: *** [sharedmods] Error 1




It can be fixed by either renaming the file:
  Mac/Modules/macosmodule.c 
to
  Mac/Modules/MacOSmodule.c 

or applying the following patch :
Index: setup.py
===
--- setup.py(revision 50687)
+++ setup.py(working copy)
@@ -1101,7 +1101,7 @@
 carbon_kwds = {'extra_compile_args':
carbon_extra_compile_args,
'extra_link_args':
['-framework', 'Carbon'],
   }
-CARBON_EXTS = ['ColorPicker', 'gestalt',
'MacOS', 'Nav',
+CARBON_EXTS = ['ColorPicker', 'gestalt',
'macos', 'Nav',
'OSATerminology', 'icglue',
# All these are in subdirs
'_AE', '_AH', '_App',
'_CarbonEvt', '_Cm', '_Ctl',


Cheers,

Gideon



--

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-25 21:21

Message:
Logged In: YES 
user_id=580910

I've implemented the rename I suggested earlier in revision 50832.

Could you please confirm that this does actually solve your problem?

--

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-23 20:11

Message:
Logged In: YES 
user_id=580910

Could you please test if renaming Mac/Modules/macosmodule.c to Mac/
Modules/MacOS.c solves your problem?  With that rename the build still works 
for me, but I don't have a case-sensitive filesystem.

--

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-23 11:31

Message:
Logged In: YES 
user_id=580910

The patch is incorrect, as this would rename user visible name of the python 
extension ('import MacOS' would stop working). 

The rename would be correct.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1525447&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

[SourceForge.net]

Bugs item #1521947, was opened at 2006-07-13 17:39
Message generated for change (Comment added) made by nmm
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: 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 who has such a platform could
check against current Python trunk.

--

Comment By: Nick Maclaren (nmm)
Date: 2006-07-17 09:20

Message:
Logged In: YES 
user_id=42444

Yes, this is a duplicate of 1521726.

The compiler people's answer is correct, and mystrtoul.c is
incorrect. LONG_MIN has been in C since C90, so should be
safe, but its value may not always be what you expect.

However, the code breakage is worse that just that test, and
there are the following 3 cases of undefined behaviour:

1) Casting and unsigned long to long above LONG_MAX.
2) That test.
3) result = -result.

The fix should be to make result unsigned long, and check
the range BEFORE any conversion.  Nothing else is safe.

It is a matter of taste whether to include a fiddle for the
number that can be held only when negated - I wouldn't, and
would let that number be converted to a Python long, but
others might disagree.


--

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-17 01:13

Message:
Logged In: YES 
user_id=33168

Is this a duplicate of 1521726?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521947&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

[SourceForge.net]

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-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

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 00: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 00: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-26 21: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 who has such a platform could
check against current Python trunk.

--

Comment By: Nick Maclaren (nmm)
Date: 2006-07-17 05:20

Message:
Logged In: YES 
user_id=42444

Yes, this is a duplicate of 1521726.

The compiler people's answer is correct, and mystrtoul.c is
incorrect. LONG_MIN has been in C since C90, so should be
safe, but its value may not always be what you expect.

However, the code breakage is worse that just that test, and
there are the following 3 cases of undefined behaviour:

1) Casting and unsigned long to long above LONG_MAX.
2) That test.
3) result = -result.

The fix should be to make result unsigned long, and check
the range BEFORE any conversion.  Nothing else is safe.

It is a matter of taste whether to include a fiddle for the
number that can be held only when negated - I wouldn't, and
would let that number be converted to a Python long, but
others might disagree.


--

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-16 21:13

Message:
Logged In: YES 
user_id=33168

Is this a duplicate of 1521726?

--

You can respond by 

[ python-Bugs-1529871 ] distutils regression related to Distribution.run_command

[SourceForge.net]

Bugs item #1529871, was opened at 2006-07-27 17:49
Message generated for change (Comment added) made by pje
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529871&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: 6
Submitted By: Collin Winter (collinwinter)
Assigned to: Phillip J. Eby (pje)
Summary: distutils regression related to Distribution.run_command

Initial Comment:
The following used to work in Python 2.4.x but fails
under Python 2.5:

>>> import setuptools
>>> import distutils.core
>>> distutils.core._setup_stop_after = 'config'
>>> 
>>> import setup
>>> setup.dist.run_command('test')

Where setup.dist is an instance of
distutils.core.Distribution (which setuptools replaces
with setuptools.dist.Distribution).

Under Python 2.4.x, this code would execute setuptools'
test command. Under Python 2.5b2 (as of r50855), this
code results in the following exception:

/opt/dev/python/2.5/lib/python2.5/distutils/dist.py:263:
UserWarning: Unknown distribution option: 'test_suite'
  warnings.warn(msg)
Traceback (most recent call last):
  File "test.py", line 8, in 
setup.dist.run_command('test')
  File
"/opt/dev/python/2.5/lib/python2.5/distutils/dist.py",
line 992, in run_command
cmd_obj = self.get_command_obj(command)
  File
"/opt/dev/python/2.5/lib/python2.5/distutils/dist.py",
line 868, in get_command_obj
klass = self.get_command_class(command)
  File
"/opt/dev/python/2.5/lib/python2.5/site-packages/setuptools/dist.py",
line 357, in get_command_class
return _Distribution.get_command_class(self, command)
  File
"/opt/dev/python/2.5/lib/python2.5/distutils/dist.py",
line 851, in get_command_class
raise DistutilsModuleError("invalid command '%s'" %
command)
distutils.errors.DistutilsModuleError: invalid command
'test'

I'd greatly appreciate it if this regression could be
fixed before Python 2.5 is released.

--

>Comment By: Phillip J. Eby (pje)
Date: 2006-07-27 21:13

Message:
Logged In: YES 
user_id=56214

Problem source confirmed: reverting the PEP 302 breakage of
r46372 (need-for-speed import cache hack) fixes the problem.

setuptools 0.7a1 doesn't show any problems because it uses
2.5's "pkgutil" module if possible, and r46372 patches
pkgutil in a way that masks the problem, at least as far as
setuptools is concerned, for this one specific feature. 
(Other code in setuptools is affected in both 0.6 *and* 0.7,
and will require further workaround code to be written.)



--

Comment By: Phillip J. Eby (pje)
Date: 2006-07-27 18:35

Message:
Logged In: YES 
user_id=56214

I can't reproduce this using setuptools 0.7a1 and the Python
2.5 trunk.  Please note that setuptools 0.6 does *not*
support Python 2.5; there were numerous changes needed and
there may still be additional changes needed.  Please try
using setuptools 0.7a1 and let me know what you find out. 
Thanks.


--

Comment By: Collin Winter (collinwinter)
Date: 2006-07-27 18:34

Message:
Logged In: YES 
user_id=1344176

Further testing reveals that all of setuptools' extension
commands (tested: egg_info, bdist_egg, test, rotate, alias)
are broken under Python 2.5b2, even when called from the
command line, like so:

$ python2.5 setup.py egg_info

This produces an "error: invalid command: 'egg_info'" message.

--

Comment By: Collin Winter (collinwinter)
Date: 2006-07-27 18:18

Message:
Logged In: YES 
user_id=1344176

Forgot to mention: I've tried this with setuptools 0.6a9 and
0.6c1. Python 2.4.x (2.4.1, 2.4.2 and 2.4.3 tested) with
both setuptools version worked fine, where Python 2.5b2
fails with both.

--

Comment By: A.M. Kuchling (akuchling)
Date: 2006-07-27 18:03

Message:
Logged In: YES 
user_id=11375

Assigned to Phillip.  I don't see any obviously relevant
changes to distutils/dist.py, but maybe this problems stems
from changes to some other module.


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529871&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1469557 ] FTP modue functions are not re-entrant, give odd exceptions

[SourceForge.net]

Bugs item #1469557, was opened at 2006-04-12 17:13
Message generated for change (Comment added) made by brucepeterson
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1469557&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.4
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: brucepeterson (brucepeterson)
Assigned to: Nobody/Anonymous (nobody)
Summary: FTP modue functions are not re-entrant,give odd exceptions

Initial Comment:
 If I define a class using the Thread and FTP moudles, 
start a process which gathers FTP responses, 
additional calls to the class may have the responses 
of the thread instead of the main loop (or vice versa)
  This causes weird and unexpected exceptions from the 
ftplib.

  For instance I get the following error when the 
thread process does a pwd() function
error_reply: 213 34603008  

  The "213" reply is a response from the main process 
size() function

-
Code
-
from time import sleep
from threading import Thread

class ftpMachine(Thread, ftplib.FTP):
def __init__(self, svr, user, passwd):
Thread.__init__(self)
ftplib.FTP.__init__(self, svr, user, passwd)

def run(self):
for x in xrange(20):
output="Thread -"+str(self.nlst())[:30]
print output
sleep (0.0100)

def main():
aCon = ftpMachine("LocalFTP", "user", "")
aCon.start()
for x in xrange(20):
output = "Main -- " + str(aCon.size("File"))
print output  
sleep (0.010)

Workround:
  Rewrite code to create a third worker thread for 
response isolation?  Don't know that this would solve 
the problem.


---
Exception example
---

Exception in thread Thread-1:
Traceback (most recent call last):
  File "C:\Python24\lib\threading.py", line 442, in 
__bootstrap
self.run()
  File "dualFTPIssue.py", line 17, in run
output  = "Thread output " + str(self.nlst())[:30]
+" ..."
  File "C:\Python24\lib\ftplib.py", line 448, in nlst
self.retrlines(cmd, files.append)
  File "C:\Python24\lib\ftplib.py", line 396, in 
retrlines
conn = self.transfercmd(cmd)
  File "C:\Python24\lib\ftplib.py", line 345, in 
transfercmd
return self.ntransfercmd(cmd, rest)[0]
  File "C:\Python24\lib\ftplib.py", line 321, in 
ntransfercmd
host, port = self.makepasv()
  File "C:\Python24\lib\ftplib.py", line 299, in 
makepasv
host, port = parse227(self.sendcmd('PASV'))
  File "C:\Python24\lib\ftplib.py", line 566, in 
parse227
raise error_reply, resp
error_reply: 213 34603008

--

>Comment By: brucepeterson (brucepeterson)
Date: 2006-07-27 14:39

Message:
Logged In: YES 
user_id=1500983

Unfortunately I can't start two instances of the FTP client 
as the separate instances use two conneciton resources.  I 
was hoping for a non-exception when a unexpsected response 
happens.  That would require re-working the module.
  For my workaround I set a time to determine when the 
transfer should complete instead of a querry.

  Thanks for your attention in this matter.

  Closing this bug as my case is an unusual one.

--

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-13 04:54

Message:
Logged In: YES 
user_id=580910

IMHO this isn't a bug, your accessing a shared resource (the FTP connection) 
from two threads without locking. Most of python's libraries aren't safe for 
this 
kind of use.

BTW. The fact that you subclass form thread and ftplib.FTP is immaterial, you 
will get the same effect if you create an ftplib.FTP and then use it in two 
threads.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1469557&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1112549 ] cgi.FieldStorage memory usage can spike in line-oriented ops

[SourceForge.net]

Bugs item #1112549, was opened at 2005-01-30 08:40
Message generated for change (Comment added) made by chrism
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1112549&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.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Chris McDonough (chrism)
Assigned to: Nobody/Anonymous (nobody)
Summary: cgi.FieldStorage memory usage can spike in line-oriented ops

Initial Comment:
Various parts of cgi.FieldStorage call its
"read_lines_to_outerboundary", "read_lines" and
"skip_lines" methods.These methods use the
"readline" method of the file object that represents an
input stream.  The input stream is typically data
supplied by an untrusted source (such as a user
uploading a file from a web browser).  The input data
is not required by the RFC 822/1521/1522/1867
specifications to contain any newline characters.  For
example, it is within the bounds of the specification
to supply a a multipart/form-data input stream with a
"file-data" part that consists of a 2GB string composed
entirely of "x" characters (which happens to be
something I did that led me to noticing this bug).

The simplest fix is to make use of the "size" argument
of the readline method of the file object where it is
used within all parts of FieldStorage that make use of
it.  A patch against the Python 2.3.4 cgi.py module
that does this is attached.

--

>Comment By: Chris McDonough (chrism)
Date: 2006-07-27 17:42

Message:
Logged In: YES 
user_id=32974

The files I've just uploaded are revisions to the cgi and test_cgi modules for 
the 
current state of the SVN trunk.  If someone could apply these, it would be 
appreciated, or give me access and I'll be happy to.

FTR, this is a bug which exposes systems which use the cgi.FieldStorage class 
(most Python web frameworks do) to a denial of service potential.

--

Comment By: Chris McDonough (chrism)
Date: 2005-04-02 23:00

Message:
Logged In: YES 
user_id=32974

FYI, I'd be happy to do the merging here if you wanted to
give me checkin access.

--

Comment By: Chris McDonough (chrism)
Date: 2005-04-02 22:42

Message:
Logged In: YES 
user_id=32974

An updated test_cgi.py is attached.  I test both the
readline behavior and add a test for basic multipart parsing. 

--

Comment By: Guido van Rossum (gvanrossum)
Date: 2005-03-31 23:48

Message:
Logged In: YES 
user_id=6380

Can I tweak you into uploading a unit test?

--

Comment By: Chris McDonough (chrism)
Date: 2005-03-31 21:56

Message:
Logged In: YES 
user_id=32974

Re: parse_multipart..  yes, it looks like there's no use
fixing that as it just turns around and puts the line into a
list.. it is vulnerable but just by virtue of its non-use of
a tempfile, it appears doomed anyway for large requests.  I
don't know of anything that uses it.
 
Good catch wrt boundary recognition bug, I'm uploading
another patch.

--

Comment By: Guido van Rossum (gvanrossum)
Date: 2005-03-31 17:13

Message:
Logged In: YES 
user_id=6380

Methinks that the fix isn't quite right: it would
incorrectly recognize as a boundary a very long line
starting with "--" followed by the appropriate random string
at offset 2**16. This could probably be taken care of by
adding a flag that is true initially and after that keeps
track of whether the previous line ended in \n.

Also, there's a call to fp.readline() in parse_multipart()
that you didn't patch -- it wouldn't help because that code
is saving the lines in a list anyway, but isn't that code
vulnerable as well? Or is it not used?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1112549&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1529998 ] bz2 lib missing from source distribution

[SourceForge.net]

Bugs item #1529998, was opened at 2006-07-27 21: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=1529998&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: james yoo (jyoo_abn)
Assigned to: Nobody/Anonymous (nobody)
Summary: bz2 lib missing from source distribution

Initial Comment:
python 2.4.3

got an import error trying to test PySqlite 

"No module named bz2"

checked my python dirs and yep, no bz2... I thought
that the bz2 module was part of the standard distribution?

checked the python source dir (python-2.4.3.tar.gz) and
no bz2.py in the Lib dir.

what gives?



--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529998&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1529297 ] unrelated variable messing up doctests

[SourceForge.net]

Bugs item #1529297, was opened at 2006-07-26 15:02
Message generated for change (Comment added) made by macquigg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529297&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.5
Status: Open
Resolution: None
Priority: 5
Submitted By: David MacQuigg (macquigg)
Assigned to: Nobody/Anonymous (nobody)
Summary: unrelated variable messing up doctests

Initial Comment:
Version 2.5b2 with IDLE 1.2b2 running on Windows XP 
Home, fully updated.

Unpack the attached zip file.
Open program.py, test_suite.py, in separate IDLE 
windows.  
Run test_suite.py.  
  8 passed and 0 failed.
Now add a variable at the top of program.py, any name 
will do.
  xyz = 2
Re-run test_suite.py.  
  7 passed and 1 failed !!

I haven't been able to isolate the problem, but it is 
repeatable.  Taking out blocks of unrelated statements 
changes the behavior.  Feels like a memory allocation 
error, or something strange.


--

>Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 14:48

Message:
Logged In: YES 
user_id=676422

Some observations:
If I give the test variable a private name, the problem 
goes away.
.   _xyz = 2
If I assign the variable to an object already in memory, 
the problem doesn't go away.
.   xyz = LocalADDRs
It doesn't matter that the test variable is never used. The 
problem persists, even if I add a second statement:
.   xyz = 2
.   if xyz == 2: pass
It doesn't matter where in the module the statement is 
placed, as long as it is module level, not inside a class 
or function.


--

Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 10:32

Message:
Logged In: YES 
user_id=676422

The failure is not the specific output of doctest, but the 
fact that it *changes* when I add an unrelated variable 
xyz=2 in the module program.py.  I am not able to reproduce 
this failure with Tim's stripped down test_suite.py.

I agree the problem is not in IDLE.  I can do the same from 
a bash command line with
$ python2.4 test_suite.py
but not with 
$ python2.3 test_suite.py


--

Comment By: Tim Peters (tim_one)
Date: 2006-07-27 09:14

Message:
Logged In: YES 
user_id=31435

I see exactly the same failure akuchling reported, on
Windows using current trunk, running from a command shell
(not IDLE -- didn't try IDLE).  The attached test_suite.py
throws away everything not needed to see the same failure;
in particular, it gets rid of doctest, the logging module,
and most of the functions in test_suite.py.

Reduced to this, I don't see a reason to suspect a Python
bug.  ci.IDrating is initialized to 100, and the

_envrcpt('[EMAIL PROTECTED]')

line produces (the expected)

CONTINUE [['[EMAIL PROTECTED]', 50, 2, 75, 101, '']]

if you /leave ci.IDrating alone/.  However, if you do

ci.hello('zz_IP_192.168.0.8_mailout7.simple.tld')

first, that has a (apparently deliberate) side effect of
changing ci.IDrating to None, and then this path is /not/ taken:

# . . Whitelist pass
if self.IDrating > whitelvl:
rcptinfo[4] = 101  # ham > 100% to ignore later
spamscore   ###2e
self.R.append(rcptinfo)

The 101 vanishes from the expected output then, and I get

CONTINUE [['[EMAIL PROTECTED]', 50, 2, 75, 50, '']]

instead.

That exactly reproduces the only failure Andrew & I have
seen, and appears to be what the code is telling it to do
(via side effects on the shared `ci` instance).

--

Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 08:22

Message:
Logged In: YES 
user_id=676422

On my Redhat Linux machine, I see the failure in 2.4.1, but 
not in 2.3.4.

Trying to isolate the problem, I've commented out some 
blocks of unrelated code, but I can't get very far with 
this, because many of the deletions make the problem go 
away.  It's as if the problem depends on the exact position 
in memory of the test variable.

I did manage to delete the DNS queries, so now you can run 
the tests without intermittent failures due to DNS timeouts.
I'll keep the latest at http://www.open-
mail.org/test/test_0607nn.tgz

Thanks for your efforts.


--

Comment By: A.M. Kuchling (akuchling)
Date: 2006-07-27 05:15

Message:
Logged In: YES 
user_id=11375

On a Linux machine, both 2.4.3 and SVN HEAD report 7 tests
passed, one failed.

For both versions, the failure is: 
Failed example:
_envrcpt('[EMAIL PROTECTED]')
Expected:
CONTINUE [['[EMAIL PROTECTED]', 50, 2, 75, 101, '']]
Got:
CONTINUE [['[EMAIL PROTECTED]', 50, 2, 75, 50, '']]


-

[ python-Bugs-1529297 ] unrelated variable messing up doctests

[SourceForge.net]

Bugs item #1529297, was opened at 2006-07-26 15:02
Message generated for change (Comment added) made by macquigg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529297&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.5
Status: Open
Resolution: None
Priority: 5
Submitted By: David MacQuigg (macquigg)
Assigned to: Nobody/Anonymous (nobody)
Summary: unrelated variable messing up doctests

Initial Comment:
Version 2.5b2 with IDLE 1.2b2 running on Windows XP 
Home, fully updated.

Unpack the attached zip file.
Open program.py, test_suite.py, in separate IDLE 
windows.  
Run test_suite.py.  
  8 passed and 0 failed.
Now add a variable at the top of program.py, any name 
will do.
  xyz = 2
Re-run test_suite.py.  
  7 passed and 1 failed !!

I haven't been able to isolate the problem, but it is 
repeatable.  Taking out blocks of unrelated statements 
changes the behavior.  Feels like a memory allocation 
error, or something strange.


--

>Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 14:48

Message:
Logged In: YES 
user_id=676422

Some observations:
If I give the test variable a private name, the problem 
goes away.
.   _xyz = 2
If I assign the variable to an object already in memory, 
the problem doesn't go away.
.   xyz = LocalADDRs
It doesn't matter that the test variable is never used. The 
problem persists, even if I add a second statement:
.   xyz = 2
.   if xyz == 2: pass
It doesn't matter where in the module the statement is 
placed, as long as it is module level, not inside a class 
or function.


--

Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 14:48

Message:
Logged In: YES 
user_id=676422

Some observations:
If I give the test variable a private name, the problem 
goes away.
.   _xyz = 2
If I assign the variable to an object already in memory, 
the problem doesn't go away.
.   xyz = LocalADDRs
It doesn't matter that the test variable is never used. The 
problem persists, even if I add a second statement:
.   xyz = 2
.   if xyz == 2: pass
It doesn't matter where in the module the statement is 
placed, as long as it is module level, not inside a class 
or function.


--

Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 10:32

Message:
Logged In: YES 
user_id=676422

The failure is not the specific output of doctest, but the 
fact that it *changes* when I add an unrelated variable 
xyz=2 in the module program.py.  I am not able to reproduce 
this failure with Tim's stripped down test_suite.py.

I agree the problem is not in IDLE.  I can do the same from 
a bash command line with
$ python2.4 test_suite.py
but not with 
$ python2.3 test_suite.py


--

Comment By: Tim Peters (tim_one)
Date: 2006-07-27 09:14

Message:
Logged In: YES 
user_id=31435

I see exactly the same failure akuchling reported, on
Windows using current trunk, running from a command shell
(not IDLE -- didn't try IDLE).  The attached test_suite.py
throws away everything not needed to see the same failure;
in particular, it gets rid of doctest, the logging module,
and most of the functions in test_suite.py.

Reduced to this, I don't see a reason to suspect a Python
bug.  ci.IDrating is initialized to 100, and the

_envrcpt('[EMAIL PROTECTED]')

line produces (the expected)

CONTINUE [['[EMAIL PROTECTED]', 50, 2, 75, 101, '']]

if you /leave ci.IDrating alone/.  However, if you do

ci.hello('zz_IP_192.168.0.8_mailout7.simple.tld')

first, that has a (apparently deliberate) side effect of
changing ci.IDrating to None, and then this path is /not/ taken:

# . . Whitelist pass
if self.IDrating > whitelvl:
rcptinfo[4] = 101  # ham > 100% to ignore later
spamscore   ###2e
self.R.append(rcptinfo)

The 101 vanishes from the expected output then, and I get

CONTINUE [['[EMAIL PROTECTED]', 50, 2, 75, 50, '']]

instead.

That exactly reproduces the only failure Andrew & I have
seen, and appears to be what the code is telling it to do
(via side effects on the shared `ci` instance).

--

Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 08:22

Message:
Logged In: YES 
user_id=676422

On my Redhat Linux machine, I see the failure in 2.4.1, but 
not in 2.3.4.

Trying to isolate the problem, I've commented out some 
blocks of unrelated code, but I can't get very far with 
this, because many of the deletions make the problem go 
away.  It's as if the problem depends on the exact position 
in memory of the test variable.

I did manage to delete the DNS 

[ python-Bugs-1529297 ] unrelated variable messing up doctests

[SourceForge.net]

Bugs item #1529297, was opened at 2006-07-26 15:02
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529297&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.5
Status: Open
Resolution: None
Priority: 5
Submitted By: David MacQuigg (macquigg)
Assigned to: Nobody/Anonymous (nobody)
Summary: unrelated variable messing up doctests

Initial Comment:
Version 2.5b2 with IDLE 1.2b2 running on Windows XP 
Home, fully updated.

Unpack the attached zip file.
Open program.py, test_suite.py, in separate IDLE 
windows.  
Run test_suite.py.  
  8 passed and 0 failed.
Now add a variable at the top of program.py, any name 
will do.
  xyz = 2
Re-run test_suite.py.  
  7 passed and 1 failed !!

I haven't been able to isolate the problem, but it is 
repeatable.  Taking out blocks of unrelated statements 
changes the behavior.  Feels like a memory allocation 
error, or something strange.


--

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-26 20:59

Message:
Logged In: YES 
user_id=33168

Can you try with SVN head?  There was an unitialized read
that the doctests could trigger.  It has been fixed. 
Perhaps you are running into that?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529297&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1530012 ] Literal strings use BS as octal escape character

[SourceForge.net]

Bugs item #1530012, was opened at 2006-07-27 15:08
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=1530012&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.5
Status: Open
Resolution: None
Priority: 5
Submitted By: brucepeterson (brucepeterson)
Assigned to: Nobody/Anonymous (nobody)
Summary: Literal strings use BS as octal escape character

Initial Comment:
Also in 2.4


  Using a literal to hard code a path.  My directory 
happened to start with a number and I couldn't open 
the file due to the bad directory name.  Found that 
the tripple quote was operating as documented.

  I would have at least expected the tripple double 
quotes to not have an escape character.  (Is this a 
pep?)  (From my reading of the Introduction, the 
triple double quotes should act like a raw string 
except that you can have a single double quote 
included in the string.)

-
code snippet:
-
dir1 = """C:\1stDirecotry"""
dir2 = '''C:\2ndDirecotry'''
dir3 = '''C:\9thDirecotry'''
print dir1, dir2, dir3

C:☺stDirecotry C:☻ndDirecotry C:\9thDirecotry

dir1's format was not expected, dir2's format might be 
expected.

>>> '''\1'''
'\x01'
>>> '''\9'''
'\\9'

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530012&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1529871 ] distutils regression related to Distribution.run_command

[SourceForge.net]

Bugs item #1529871, was opened at 2006-07-27 13:49
Message generated for change (Comment added) made by collinwinter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529871&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: 6
Submitted By: Collin Winter (collinwinter)
Assigned to: Phillip J. Eby (pje)
Summary: distutils regression related to Distribution.run_command

Initial Comment:
The following used to work in Python 2.4.x but fails
under Python 2.5:

>>> import setuptools
>>> import distutils.core
>>> distutils.core._setup_stop_after = 'config'
>>> 
>>> import setup
>>> setup.dist.run_command('test')

Where setup.dist is an instance of
distutils.core.Distribution (which setuptools replaces
with setuptools.dist.Distribution).

Under Python 2.4.x, this code would execute setuptools'
test command. Under Python 2.5b2 (as of r50855), this
code results in the following exception:

/opt/dev/python/2.5/lib/python2.5/distutils/dist.py:263:
UserWarning: Unknown distribution option: 'test_suite'
  warnings.warn(msg)
Traceback (most recent call last):
  File "test.py", line 8, in 
setup.dist.run_command('test')
  File
"/opt/dev/python/2.5/lib/python2.5/distutils/dist.py",
line 992, in run_command
cmd_obj = self.get_command_obj(command)
  File
"/opt/dev/python/2.5/lib/python2.5/distutils/dist.py",
line 868, in get_command_obj
klass = self.get_command_class(command)
  File
"/opt/dev/python/2.5/lib/python2.5/site-packages/setuptools/dist.py",
line 357, in get_command_class
return _Distribution.get_command_class(self, command)
  File
"/opt/dev/python/2.5/lib/python2.5/distutils/dist.py",
line 851, in get_command_class
raise DistutilsModuleError("invalid command '%s'" %
command)
distutils.errors.DistutilsModuleError: invalid command
'test'

I'd greatly appreciate it if this regression could be
fixed before Python 2.5 is released.

--

>Comment By: Collin Winter (collinwinter)
Date: 2006-07-27 18:12

Message:
Logged In: YES 
user_id=1344176

I've tried using setuptools 0.7a1 in conjunction with Python
2.5b2 (r50877), and the problem still exists. setuptools'
extension commands still do not work (tested: rotate, alias,
egg_info, bdist_egg, test), that is, 'python2.5 setup.py
test' still fails with "error: invalid command 'test'".

Also, the code snippet in the bug report does not work. I am
sure Python is picking up setuptools 0.7a1 because the path
/opt/dev/python/2.5/lib/python2.5/site-packages/setuptools-0.7a1dev_r50755-py2.4.egg/setuptools/dist.py
appears in the traceback.

--

Comment By: Phillip J. Eby (pje)
Date: 2006-07-27 17:13

Message:
Logged In: YES 
user_id=56214

Problem source confirmed: reverting the PEP 302 breakage of
r46372 (need-for-speed import cache hack) fixes the problem.

setuptools 0.7a1 doesn't show any problems because it uses
2.5's "pkgutil" module if possible, and r46372 patches
pkgutil in a way that masks the problem, at least as far as
setuptools is concerned, for this one specific feature. 
(Other code in setuptools is affected in both 0.6 *and* 0.7,
and will require further workaround code to be written.)



--

Comment By: Phillip J. Eby (pje)
Date: 2006-07-27 14:35

Message:
Logged In: YES 
user_id=56214

I can't reproduce this using setuptools 0.7a1 and the Python
2.5 trunk.  Please note that setuptools 0.6 does *not*
support Python 2.5; there were numerous changes needed and
there may still be additional changes needed.  Please try
using setuptools 0.7a1 and let me know what you find out. 
Thanks.


--

Comment By: Collin Winter (collinwinter)
Date: 2006-07-27 14:34

Message:
Logged In: YES 
user_id=1344176

Further testing reveals that all of setuptools' extension
commands (tested: egg_info, bdist_egg, test, rotate, alias)
are broken under Python 2.5b2, even when called from the
command line, like so:

$ python2.5 setup.py egg_info

This produces an "error: invalid command: 'egg_info'" message.

--

Comment By: Collin Winter (collinwinter)
Date: 2006-07-27 14:18

Message:
Logged In: YES 
user_id=1344176

Forgot to mention: I've tried this with setuptools 0.6a9 and
0.6c1. Python 2.4.x (2.4.1, 2.4.2 and 2.4.3 tested) with
both setuptools version worked fine, where Python 2.5b2
fails with both.

--

Comment By: A.M. Kuchling (akuchling)
Date: 2006-07-27 14:03

Message:
Logged In: YES 
user_id=11375

Assigned to Phill

[ python-Bugs-1333982 ] Bugs of the new AST compiler

[SourceForge.net]

Bugs item #1333982, was opened at 2005-10-21 03:08
Message generated for change (Settings changed) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1333982&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: AST
Status: Open
Resolution: None
>Priority: 9
Submitted By: Armin Rigo (arigo)
Assigned to: Jeremy Hylton (jhylton)
Summary: Bugs of the new AST compiler

Initial Comment:
The newly merged AST branch is likely to expose
a number of small problems before it stabilizes,
so here is a tentative bug tracker entry to
collect such small problems.


--

Comment By: Neil Schemenauer (nascheme)
Date: 2006-07-09 14:23

Message:
Logged In: YES 
user_id=35752

Unary minus bug has been fixed in SVN rev 50495.

--

Comment By: Neil Schemenauer (nascheme)
Date: 2006-07-09 14:05

Message:
Logged In: YES 
user_id=35752

Regarding the -2147483648 bug: the old compiler tries to
fold unary +, - and ~ if the RHS is a constant.  I think
only the minus case is important since the others are just
optimizations, right?  Attaching what seems to be a minimum fix.

--

Comment By: Armin Rigo (arigo)
Date: 2006-07-02 04:29

Message:
Logged In: YES 
user_id=4771

Attached a patch for the LOAD_CONST POP_TOP optimization
(modified from Georg Brandl on python-dev).

--

Comment By: Michael Hudson (mwh)
Date: 2006-04-11 02:41

Message:
Logged In: YES 
user_id=6656

Good morning Armin!

I've reported that bug already: http://python.org/sf/1441486
There's a patch which purports to fix it: http://python.org/sf/1446922
but I haven't gotten around to testing it.

(this is running the pypy/module/array tests or something, isn't it?)

--

Comment By: Armin Rigo (arigo)
Date: 2006-04-11 01:45

Message:
Logged In: YES 
user_id=4771

Another one: the literal -2147483648 (i.e. the value of
-sys.maxint-1) gives a long in 2.5, but an int in <= 2.4.

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-03 00:30

Message:
Logged In: YES 
user_id=33168

The tuple store problem is fixed.  The only outstanding item
is the LOAD_CONST/POP_TOP.  I will fix that soon.

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-02-17 22:56

Message:
Logged In: YES 
user_id=33168

Jeremy, there's no need to read anything before my last
comment at 2005-12-17 23:10.  The last two by Armin,
Michael, then my last comment are the only important ones. 
Everything that occurred before my 2005-12-17 comment was
taken care of AFAIK.

--

Comment By: Armin Rigo (arigo)
Date: 2006-02-12 13:54

Message:
Logged In: YES 
user_id=4771

Subscripting is generally a bit sloppy: e.g. the AST model has
no way to distinguish between a single value and a one-element
tuple value!  See:

>>> d = {}
>>> d[1,] = 6
>>> d
{1: 6}# !

I suggest we fix the model to turn the 'subs' of the 'Subscript' node
from a list of nodes to a single, mandatory 'sub' node.  If tupling is
necessary, it can be explicitly represented with a 'sub' containing a
'Tuple' node.

--

Comment By: Michael Hudson (mwh)
Date: 2006-02-09 07:02

Message:
Logged In: YES 
user_id=6656

We found another one.  Something is wrong in the compilation of augmented 
assignment to subscriptions containing tuples; running this code:

class C:
def __setitem__(self, i, v):
print i, v
def __getitem__(self, i):
print i
return 0

c = C()
c[4,5] += 1

gives a spurious exception:

Traceback (most recent call last):
  File "", line 1, in 
TypeError: object does not support item assignment

By contrast, "c[(4,5)] += 1" works fine.



--

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-12-17 23:10

Message:
Logged In: YES 
user_id=33168

EXTENDED_ARG problem was fixed a while ago.
The assert/pass problem was fixed with: 41756.

That leaves the LOAD_CONST/POP_TOP optimization that was
lost and one compiler warning: marshal_write_mod() not being
used.

--

Comment By: Michael Hudson (mwh)
Date: 2005-12-10 16:41

Message:
Logged In: YES 
user_id=6656

You have to include those lines in a source file.  It still crashes for me.

---

[ python-Bugs-1529998 ] bz2 lib missing from source distribution

[SourceForge.net]

Bugs item #1529998, was opened at 2006-07-27 21:45
Message generated for change (Comment added) made by jyoo_abn
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529998&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: james yoo (jyoo_abn)
Assigned to: Nobody/Anonymous (nobody)
Summary: bz2 lib missing from source distribution

Initial Comment:
python 2.4.3

got an import error trying to test PySqlite 

"No module named bz2"

checked my python dirs and yep, no bz2... I thought
that the bz2 module was part of the standard distribution?

checked the python source dir (python-2.4.3.tar.gz) and
no bz2.py in the Lib dir.

what gives?



--

>Comment By: james yoo (jyoo_abn)
Date: 2006-07-27 22:30

Message:
Logged In: YES 
user_id=1562754

actually sorry for the poor assumptions regarding the
existence of a bz2.py file... realize that there is a a
bz2module.c file and that my config.log had a bunch of fatal
ld errors... 

fyi: this is on sunOS 5.8, gcc-3.4.3..

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529998&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1529297 ] unrelated variable messing up doctests

[SourceForge.net]

Bugs item #1529297, was opened at 2006-07-26 18:02
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529297&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.5
Status: Open
Resolution: None
Priority: 5
Submitted By: David MacQuigg (macquigg)
Assigned to: Nobody/Anonymous (nobody)
Summary: unrelated variable messing up doctests

Initial Comment:
Version 2.5b2 with IDLE 1.2b2 running on Windows XP 
Home, fully updated.

Unpack the attached zip file.
Open program.py, test_suite.py, in separate IDLE 
windows.  
Run test_suite.py.  
  8 passed and 0 failed.
Now add a variable at the top of program.py, any name 
will do.
  xyz = 2
Re-run test_suite.py.  
  7 passed and 1 failed !!

I haven't been able to isolate the problem, but it is 
repeatable.  Taking out blocks of unrelated statements 
changes the behavior.  Feels like a memory allocation 
error, or something strange.


--

>Comment By: Tim Peters (tim_one)
Date: 2006-07-27 19:21

Message:
Logged In: YES 
user_id=31435

I think I know what's happening here.  doctest was largely
rewritten for Python 2.4, and it lost a subtle intended
feature:  it used to (<= 2.3) sort tests by name before
running them, but in 2.4 started running them in whatever
order they happen to appear in the hash-code-based module
__dict__.

Changing the namespace in program.py in seemingly random
ways matters because test_suite.py starts with

from program import *

and so everything in program.py's module namespace
"pollutes" test_suite.py's namespace too.  That can change
the order tests run in.  And as I noted before, whether or
not the doctest for _envrcpt() passes or fails depends on
whether or not the doctests for _hello() run before them,
due to side effects on the shared `ci` instance.  Look at
your output carefully, and I expect you'll find that the
order of tests /does/ change depending on crap variable
names you stick in (or remove from) program.py.

If you're with me so far, try changing the end of
doctest.py's DocTestFinder.find() from

return tests

to

tests.sort()
return tests


--

Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 17:48

Message:
Logged In: YES 
user_id=676422

Some observations:
If I give the test variable a private name, the problem 
goes away.
.   _xyz = 2
If I assign the variable to an object already in memory, 
the problem doesn't go away.
.   xyz = LocalADDRs
It doesn't matter that the test variable is never used. The 
problem persists, even if I add a second statement:
.   xyz = 2
.   if xyz == 2: pass
It doesn't matter where in the module the statement is 
placed, as long as it is module level, not inside a class 
or function.


--

Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 17:48

Message:
Logged In: YES 
user_id=676422

Some observations:
If I give the test variable a private name, the problem 
goes away.
.   _xyz = 2
If I assign the variable to an object already in memory, 
the problem doesn't go away.
.   xyz = LocalADDRs
It doesn't matter that the test variable is never used. The 
problem persists, even if I add a second statement:
.   xyz = 2
.   if xyz == 2: pass
It doesn't matter where in the module the statement is 
placed, as long as it is module level, not inside a class 
or function.


--

Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 13:32

Message:
Logged In: YES 
user_id=676422

The failure is not the specific output of doctest, but the 
fact that it *changes* when I add an unrelated variable 
xyz=2 in the module program.py.  I am not able to reproduce 
this failure with Tim's stripped down test_suite.py.

I agree the problem is not in IDLE.  I can do the same from 
a bash command line with
$ python2.4 test_suite.py
but not with 
$ python2.3 test_suite.py


--

Comment By: Tim Peters (tim_one)
Date: 2006-07-27 12:14

Message:
Logged In: YES 
user_id=31435

I see exactly the same failure akuchling reported, on
Windows using current trunk, running from a command shell
(not IDLE -- didn't try IDLE).  The attached test_suite.py
throws away everything not needed to see the same failure;
in particular, it gets rid of doctest, the logging module,
and most of the functions in test_suite.py.

Reduced to this, I don't see a reason to suspect a Python
bug.  ci.IDrating is initialized to 100, and the

_envrcpt('[EMAIL PROTECTED]')

line produces (the expected)

CONTINUE [['[EMAIL PROTECTED]', 5

[ python-Bugs-1471938 ] curses mvwgetnstr build problem on Solaris 8

[SourceForge.net]

Bugs item #1471938, was opened at 2006-04-17 16:07
Message generated for change (Settings changed) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1471938&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: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Paul Eggert (eggert)
>Assigned to: A.M. Kuchling (akuchling)
Summary: curses mvwgetnstr build problem on Solaris 8

Initial Comment:
The _curses extension doesn't build on Solaris 8
(64-bit) due to the following problem:

building '_curses' extension
cc -O -xarch=v9 -xcode=pic32 -DNDEBUG -O -I.
-I/w/fac.01/cs/eggert/seasnet/Python-2.5a1/./Include
-I/u/cs/fac/eggert/seasnet/prefix/include -I./Include
-I. -I/w/fac.01/cs/eggert/seasnet/Python-2.5a1/Include
-I/w/fac.01/cs/eggert/seasnet/Python-2.5a1 -c
/w/fac.01/cs/eggert/seasnet/Python-2.5a1/Modules/_cursesmodule.c
-o build/temp.solaris-2.8-sun4u-2.5/_cursesmodule.o
"/w/fac.01/cs/eggert/seasnet/Python-2.5a1/Modules/_cursesmodule.c",
line 822: warning: implicit function declaration:
mvwgetnstr
cc -O -xarch=v9 -G
build/temp.solaris-2.8-sun4u-2.5/_cursesmodule.o
-L/u/cs/fac/eggert/seasnet/prefix/lib -lcurses
-ltermcap -o build/lib.solaris-2.8-sun4u-2.5/_curses.so
*** WARNING: renaming "_curses" since importing it
failed: ld.so.1: python: fatal: relocation error: file
build/lib.solaris-2.8-sun4u-2.5/_curses.so: symbol
mvwgetnstr: referenced symbol not found
building '_curses_panel' extension

This problem occurs with both 2.4.3 and 2.5a1.

I'll attach the obvious patch.


--

>Comment By: A.M. Kuchling (akuchling)
Date: 2006-07-26 13:26

Message:
Logged In: YES 
user_id=11375

Thanks!  I've tried the patch on Linux, including the
STRICT_SYSV_CURSES code, and applied it to the 2.4 and 2.5
branches.


--

Comment By: Paul Eggert (eggert)
Date: 2006-04-20 23:29

Message:
Logged In: YES 
user_id=17848

Sorry, I'm trying again to attach a file now.

--

Comment By: Martin v. Löwis (loewis)
Date: 2006-04-17 18:53

Message:
Logged In: YES 
user_id=21627

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1471938&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1529297 ] unrelated variable messing up doctests

[SourceForge.net]

Bugs item #1529297, was opened at 2006-07-26 18:02
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529297&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.5
Status: Open
Resolution: None
Priority: 5
Submitted By: David MacQuigg (macquigg)
Assigned to: Nobody/Anonymous (nobody)
Summary: unrelated variable messing up doctests

Initial Comment:
Version 2.5b2 with IDLE 1.2b2 running on Windows XP 
Home, fully updated.

Unpack the attached zip file.
Open program.py, test_suite.py, in separate IDLE 
windows.  
Run test_suite.py.  
  8 passed and 0 failed.
Now add a variable at the top of program.py, any name 
will do.
  xyz = 2
Re-run test_suite.py.  
  7 passed and 1 failed !!

I haven't been able to isolate the problem, but it is 
repeatable.  Taking out blocks of unrelated statements 
changes the behavior.  Feels like a memory allocation 
error, or something strange.


--

>Comment By: Tim Peters (tim_one)
Date: 2006-07-27 20:01

Message:
Logged In: YES 
user_id=31435

DocTestFinder has been changed to sort test names again, in
revs 50882 (on the trunk, for 2.5) and 50886 (on the 2.4
branch, for 2.4.4).

--

Comment By: Tim Peters (tim_one)
Date: 2006-07-27 19:21

Message:
Logged In: YES 
user_id=31435

I think I know what's happening here.  doctest was largely
rewritten for Python 2.4, and it lost a subtle intended
feature:  it used to (<= 2.3) sort tests by name before
running them, but in 2.4 started running them in whatever
order they happen to appear in the hash-code-based module
__dict__.

Changing the namespace in program.py in seemingly random
ways matters because test_suite.py starts with

from program import *

and so everything in program.py's module namespace
"pollutes" test_suite.py's namespace too.  That can change
the order tests run in.  And as I noted before, whether or
not the doctest for _envrcpt() passes or fails depends on
whether or not the doctests for _hello() run before them,
due to side effects on the shared `ci` instance.  Look at
your output carefully, and I expect you'll find that the
order of tests /does/ change depending on crap variable
names you stick in (or remove from) program.py.

If you're with me so far, try changing the end of
doctest.py's DocTestFinder.find() from

return tests

to

tests.sort()
return tests


--

Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 17:48

Message:
Logged In: YES 
user_id=676422

Some observations:
If I give the test variable a private name, the problem 
goes away.
.   _xyz = 2
If I assign the variable to an object already in memory, 
the problem doesn't go away.
.   xyz = LocalADDRs
It doesn't matter that the test variable is never used. The 
problem persists, even if I add a second statement:
.   xyz = 2
.   if xyz == 2: pass
It doesn't matter where in the module the statement is 
placed, as long as it is module level, not inside a class 
or function.


--

Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 17:48

Message:
Logged In: YES 
user_id=676422

Some observations:
If I give the test variable a private name, the problem 
goes away.
.   _xyz = 2
If I assign the variable to an object already in memory, 
the problem doesn't go away.
.   xyz = LocalADDRs
It doesn't matter that the test variable is never used. The 
problem persists, even if I add a second statement:
.   xyz = 2
.   if xyz == 2: pass
It doesn't matter where in the module the statement is 
placed, as long as it is module level, not inside a class 
or function.


--

Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 13:32

Message:
Logged In: YES 
user_id=676422

The failure is not the specific output of doctest, but the 
fact that it *changes* when I add an unrelated variable 
xyz=2 in the module program.py.  I am not able to reproduce 
this failure with Tim's stripped down test_suite.py.

I agree the problem is not in IDLE.  I can do the same from 
a bash command line with
$ python2.4 test_suite.py
but not with 
$ python2.3 test_suite.py


--

Comment By: Tim Peters (tim_one)
Date: 2006-07-27 12:14

Message:
Logged In: YES 
user_id=31435

I see exactly the same failure akuchling reported, on
Windows using current trunk, running from a command shell
(not IDLE -- didn't try IDLE).  The attached test_suite.py
throws away everything not needed to see the same failure;

[ python-Bugs-1529297 ] unrelated variable messing up doctests

[SourceForge.net]

Bugs item #1529297, was opened at 2006-07-26 15:02
Message generated for change (Comment added) made by macquigg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529297&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.5
Status: Open
Resolution: None
Priority: 5
Submitted By: David MacQuigg (macquigg)
Assigned to: Nobody/Anonymous (nobody)
Summary: unrelated variable messing up doctests

Initial Comment:
Version 2.5b2 with IDLE 1.2b2 running on Windows XP 
Home, fully updated.

Unpack the attached zip file.
Open program.py, test_suite.py, in separate IDLE 
windows.  
Run test_suite.py.  
  8 passed and 0 failed.
Now add a variable at the top of program.py, any name 
will do.
  xyz = 2
Re-run test_suite.py.  
  7 passed and 1 failed !!

I haven't been able to isolate the problem, but it is 
repeatable.  Taking out blocks of unrelated statements 
changes the behavior.  Feels like a memory allocation 
error, or something strange.


--

>Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 17:46

Message:
Logged In: YES 
user_id=676422

That fixed it!!  Nice catch.

I've been aware for some time of the sensitivity to order 
in the doctests, but it has never been a problem until now, 
and I've been writing programs with doctests since 2.3.  
When I add a test, and it breaks a later test, it has 
always been easy to nail down the piece that changed.

This "behind the scenes" change of test order seems like 
the kind of problem that rarely occurs, but can cause 
serious problems when it does.

Thanks again for an excellent followup.

--

Comment By: Tim Peters (tim_one)
Date: 2006-07-27 17:01

Message:
Logged In: YES 
user_id=31435

DocTestFinder has been changed to sort test names again, in
revs 50882 (on the trunk, for 2.5) and 50886 (on the 2.4
branch, for 2.4.4).

--

Comment By: Tim Peters (tim_one)
Date: 2006-07-27 16:21

Message:
Logged In: YES 
user_id=31435

I think I know what's happening here.  doctest was largely
rewritten for Python 2.4, and it lost a subtle intended
feature:  it used to (<= 2.3) sort tests by name before
running them, but in 2.4 started running them in whatever
order they happen to appear in the hash-code-based module
__dict__.

Changing the namespace in program.py in seemingly random
ways matters because test_suite.py starts with

from program import *

and so everything in program.py's module namespace
"pollutes" test_suite.py's namespace too.  That can change
the order tests run in.  And as I noted before, whether or
not the doctest for _envrcpt() passes or fails depends on
whether or not the doctests for _hello() run before them,
due to side effects on the shared `ci` instance.  Look at
your output carefully, and I expect you'll find that the
order of tests /does/ change depending on crap variable
names you stick in (or remove from) program.py.

If you're with me so far, try changing the end of
doctest.py's DocTestFinder.find() from

return tests

to

tests.sort()
return tests


--

Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 14:48

Message:
Logged In: YES 
user_id=676422

Some observations:
If I give the test variable a private name, the problem 
goes away.
.   _xyz = 2
If I assign the variable to an object already in memory, 
the problem doesn't go away.
.   xyz = LocalADDRs
It doesn't matter that the test variable is never used. The 
problem persists, even if I add a second statement:
.   xyz = 2
.   if xyz == 2: pass
It doesn't matter where in the module the statement is 
placed, as long as it is module level, not inside a class 
or function.


--

Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 14:48

Message:
Logged In: YES 
user_id=676422

Some observations:
If I give the test variable a private name, the problem 
goes away.
.   _xyz = 2
If I assign the variable to an object already in memory, 
the problem doesn't go away.
.   xyz = LocalADDRs
It doesn't matter that the test variable is never used. The 
problem persists, even if I add a second statement:
.   xyz = 2
.   if xyz == 2: pass
It doesn't matter where in the module the statement is 
placed, as long as it is module level, not inside a class 
or function.


--

Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 10:32

Message:
Logged In: YES 
user_id=676422

The failure is not the specific output of doctest, but the 
fact that it *changes* when I add an unrelat

[ python-Bugs-1529157 ] readline module description should mention raw_input()

[SourceForge.net]

Bugs item #1529157, was opened at 2006-07-26 14:13
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=1529157&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.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Thom Harp (thomharp)
Assigned to: Nobody/Anonymous (nobody)
Summary: readline module description should mention raw_input()

Initial Comment:
The description of the readline module in the library
reference should mention that it alters the behavior of
the input() and raw_input() functions.  Without this
change, it isn't obvious how to use readline to provide
a command line in applications.

The information requested *is* in the docs where
input() and raw_input() are described, but an
inexperienced python programmer, just learning his way
around the standard library, won't know that and may
conclude that the readline module exists only because
it's used for interactive python.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529157&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1529297 ] unrelated variable messing up doctests

[SourceForge.net]

Bugs item #1529297, was opened at 2006-07-26 18:02
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529297&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: David MacQuigg (macquigg)
Assigned to: Nobody/Anonymous (nobody)
Summary: unrelated variable messing up doctests

Initial Comment:
Version 2.5b2 with IDLE 1.2b2 running on Windows XP 
Home, fully updated.

Unpack the attached zip file.
Open program.py, test_suite.py, in separate IDLE 
windows.  
Run test_suite.py.  
  8 passed and 0 failed.
Now add a variable at the top of program.py, any name 
will do.
  xyz = 2
Re-run test_suite.py.  
  7 passed and 1 failed !!

I haven't been able to isolate the problem, but it is 
repeatable.  Taking out blocks of unrelated statements 
changes the behavior.  Feels like a memory allocation 
error, or something strange.


--

>Comment By: Tim Peters (tim_one)
Date: 2006-07-27 20:53

Message:
Logged In: YES 
user_id=31435

Glad it solved your mystery!  Note that 2.4.4 and 2.5 /will/
sort the tests by name again (the code for that has already
been checked in) -- it was very intentional that it did that
before 2.4, and it was a bug that it stopped doing it in 2.4
through 2.4.3.  OTOH, you're the only one so far who noticed :-)

--

Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 20:46

Message:
Logged In: YES 
user_id=676422

That fixed it!!  Nice catch.

I've been aware for some time of the sensitivity to order 
in the doctests, but it has never been a problem until now, 
and I've been writing programs with doctests since 2.3.  
When I add a test, and it breaks a later test, it has 
always been easy to nail down the piece that changed.

This "behind the scenes" change of test order seems like 
the kind of problem that rarely occurs, but can cause 
serious problems when it does.

Thanks again for an excellent followup.

--

Comment By: Tim Peters (tim_one)
Date: 2006-07-27 20:01

Message:
Logged In: YES 
user_id=31435

DocTestFinder has been changed to sort test names again, in
revs 50882 (on the trunk, for 2.5) and 50886 (on the 2.4
branch, for 2.4.4).

--

Comment By: Tim Peters (tim_one)
Date: 2006-07-27 19:21

Message:
Logged In: YES 
user_id=31435

I think I know what's happening here.  doctest was largely
rewritten for Python 2.4, and it lost a subtle intended
feature:  it used to (<= 2.3) sort tests by name before
running them, but in 2.4 started running them in whatever
order they happen to appear in the hash-code-based module
__dict__.

Changing the namespace in program.py in seemingly random
ways matters because test_suite.py starts with

from program import *

and so everything in program.py's module namespace
"pollutes" test_suite.py's namespace too.  That can change
the order tests run in.  And as I noted before, whether or
not the doctest for _envrcpt() passes or fails depends on
whether or not the doctests for _hello() run before them,
due to side effects on the shared `ci` instance.  Look at
your output carefully, and I expect you'll find that the
order of tests /does/ change depending on crap variable
names you stick in (or remove from) program.py.

If you're with me so far, try changing the end of
doctest.py's DocTestFinder.find() from

return tests

to

tests.sort()
return tests


--

Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 17:48

Message:
Logged In: YES 
user_id=676422

Some observations:
If I give the test variable a private name, the problem 
goes away.
.   _xyz = 2
If I assign the variable to an object already in memory, 
the problem doesn't go away.
.   xyz = LocalADDRs
It doesn't matter that the test variable is never used. The 
problem persists, even if I add a second statement:
.   xyz = 2
.   if xyz == 2: pass
It doesn't matter where in the module the statement is 
placed, as long as it is module level, not inside a class 
or function.


--

Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 17:48

Message:
Logged In: YES 
user_id=676422

Some observations:
If I give the test variable a private name, the problem 
goes away.
.   _xyz = 2
If I assign the variable to an object already in memory, 
the problem doesn't go away.
.   xyz = LocalADDRs
It doesn't matter that the test variable is never used. The 
problem pers

[ python-Bugs-1529297 ] unrelated variable messing up doctests

[SourceForge.net]

Bugs item #1529297, was opened at 2006-07-26 15:02
Message generated for change (Comment added) made by macquigg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529297&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.5
>Status: Open
>Resolution: None
Priority: 5
Submitted By: David MacQuigg (macquigg)
Assigned to: Nobody/Anonymous (nobody)
Summary: unrelated variable messing up doctests

Initial Comment:
Version 2.5b2 with IDLE 1.2b2 running on Windows XP 
Home, fully updated.

Unpack the attached zip file.
Open program.py, test_suite.py, in separate IDLE 
windows.  
Run test_suite.py.  
  8 passed and 0 failed.
Now add a variable at the top of program.py, any name 
will do.
  xyz = 2
Re-run test_suite.py.  
  7 passed and 1 failed !!

I haven't been able to isolate the problem, but it is 
repeatable.  Taking out blocks of unrelated statements 
changes the behavior.  Feels like a memory allocation 
error, or something strange.


--

>Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 18:03

Message:
Logged In: YES 
user_id=676422

I hope this is not too much to ask, but would it be 
possible to run the tests in the order they are written, 
rather than in alphabetical order?  This isn't a big deal, 
as long as the order is stable, but it would abide by the 
rule of least astonishment. :>)

--

Comment By: Tim Peters (tim_one)
Date: 2006-07-27 17:53

Message:
Logged In: YES 
user_id=31435

Glad it solved your mystery!  Note that 2.4.4 and 2.5 /will/
sort the tests by name again (the code for that has already
been checked in) -- it was very intentional that it did that
before 2.4, and it was a bug that it stopped doing it in 2.4
through 2.4.3.  OTOH, you're the only one so far who noticed :-)

--

Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 17:46

Message:
Logged In: YES 
user_id=676422

That fixed it!!  Nice catch.

I've been aware for some time of the sensitivity to order 
in the doctests, but it has never been a problem until now, 
and I've been writing programs with doctests since 2.3.  
When I add a test, and it breaks a later test, it has 
always been easy to nail down the piece that changed.

This "behind the scenes" change of test order seems like 
the kind of problem that rarely occurs, but can cause 
serious problems when it does.

Thanks again for an excellent followup.

--

Comment By: Tim Peters (tim_one)
Date: 2006-07-27 17:01

Message:
Logged In: YES 
user_id=31435

DocTestFinder has been changed to sort test names again, in
revs 50882 (on the trunk, for 2.5) and 50886 (on the 2.4
branch, for 2.4.4).

--

Comment By: Tim Peters (tim_one)
Date: 2006-07-27 16:21

Message:
Logged In: YES 
user_id=31435

I think I know what's happening here.  doctest was largely
rewritten for Python 2.4, and it lost a subtle intended
feature:  it used to (<= 2.3) sort tests by name before
running them, but in 2.4 started running them in whatever
order they happen to appear in the hash-code-based module
__dict__.

Changing the namespace in program.py in seemingly random
ways matters because test_suite.py starts with

from program import *

and so everything in program.py's module namespace
"pollutes" test_suite.py's namespace too.  That can change
the order tests run in.  And as I noted before, whether or
not the doctest for _envrcpt() passes or fails depends on
whether or not the doctests for _hello() run before them,
due to side effects on the shared `ci` instance.  Look at
your output carefully, and I expect you'll find that the
order of tests /does/ change depending on crap variable
names you stick in (or remove from) program.py.

If you're with me so far, try changing the end of
doctest.py's DocTestFinder.find() from

return tests

to

tests.sort()
return tests


--

Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 14:48

Message:
Logged In: YES 
user_id=676422

Some observations:
If I give the test variable a private name, the problem 
goes away.
.   _xyz = 2
If I assign the variable to an object already in memory, 
the problem doesn't go away.
.   xyz = LocalADDRs
It doesn't matter that the test variable is never used. The 
problem persists, even if I add a second statement:
.   xyz = 2
.   if xyz == 2: pass
It doesn't matter where in the module the statement is 
placed, as long as it is module level, not inside a class 
or function.

[ python-Bugs-1529297 ] unrelated variable messing up doctests

[SourceForge.net]

Bugs item #1529297, was opened at 2006-07-26 18:02
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529297&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.5
Status: Open
Resolution: None
Priority: 5
Submitted By: David MacQuigg (macquigg)
Assigned to: Nobody/Anonymous (nobody)
Summary: unrelated variable messing up doctests

Initial Comment:
Version 2.5b2 with IDLE 1.2b2 running on Windows XP 
Home, fully updated.

Unpack the attached zip file.
Open program.py, test_suite.py, in separate IDLE 
windows.  
Run test_suite.py.  
  8 passed and 0 failed.
Now add a variable at the top of program.py, any name 
will do.
  xyz = 2
Re-run test_suite.py.  
  7 passed and 1 failed !!

I haven't been able to isolate the problem, but it is 
repeatable.  Taking out blocks of unrelated statements 
changes the behavior.  Feels like a memory allocation 
error, or something strange.


--

>Comment By: Tim Peters (tim_one)
Date: 2006-07-27 21:31

Message:
Logged In: YES 
user_id=31435

> would it be possible to run the tests in the order
> they are written, rather than in alphabetical order?

Sorry, that's impossible.  doctest never sees the source
code, it crawls through module and class __dict__s to find
objects with docstrings, and the order things appear in
those is undefined.

--

Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 21:03

Message:
Logged In: YES 
user_id=676422

I hope this is not too much to ask, but would it be 
possible to run the tests in the order they are written, 
rather than in alphabetical order?  This isn't a big deal, 
as long as the order is stable, but it would abide by the 
rule of least astonishment. :>)

--

Comment By: Tim Peters (tim_one)
Date: 2006-07-27 20:53

Message:
Logged In: YES 
user_id=31435

Glad it solved your mystery!  Note that 2.4.4 and 2.5 /will/
sort the tests by name again (the code for that has already
been checked in) -- it was very intentional that it did that
before 2.4, and it was a bug that it stopped doing it in 2.4
through 2.4.3.  OTOH, you're the only one so far who noticed :-)

--

Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 20:46

Message:
Logged In: YES 
user_id=676422

That fixed it!!  Nice catch.

I've been aware for some time of the sensitivity to order 
in the doctests, but it has never been a problem until now, 
and I've been writing programs with doctests since 2.3.  
When I add a test, and it breaks a later test, it has 
always been easy to nail down the piece that changed.

This "behind the scenes" change of test order seems like 
the kind of problem that rarely occurs, but can cause 
serious problems when it does.

Thanks again for an excellent followup.

--

Comment By: Tim Peters (tim_one)
Date: 2006-07-27 20:01

Message:
Logged In: YES 
user_id=31435

DocTestFinder has been changed to sort test names again, in
revs 50882 (on the trunk, for 2.5) and 50886 (on the 2.4
branch, for 2.4.4).

--

Comment By: Tim Peters (tim_one)
Date: 2006-07-27 19:21

Message:
Logged In: YES 
user_id=31435

I think I know what's happening here.  doctest was largely
rewritten for Python 2.4, and it lost a subtle intended
feature:  it used to (<= 2.3) sort tests by name before
running them, but in 2.4 started running them in whatever
order they happen to appear in the hash-code-based module
__dict__.

Changing the namespace in program.py in seemingly random
ways matters because test_suite.py starts with

from program import *

and so everything in program.py's module namespace
"pollutes" test_suite.py's namespace too.  That can change
the order tests run in.  And as I noted before, whether or
not the doctest for _envrcpt() passes or fails depends on
whether or not the doctests for _hello() run before them,
due to side effects on the shared `ci` instance.  Look at
your output carefully, and I expect you'll find that the
order of tests /does/ change depending on crap variable
names you stick in (or remove from) program.py.

If you're with me so far, try changing the end of
doctest.py's DocTestFinder.find() from

return tests

to

tests.sort()
return tests


--

Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 17:48

Message:
Logged In: YES 
user_id=676422

Some observations:
If I give the test 

[ python-Bugs-1391608 ] missing module names in email package

[SourceForge.net]

Bugs item #1391608, was opened at 2005-12-27 21:04
Message generated for change (Comment added) made by bwarsaw
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1391608&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: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Gabriel Genellina (gagenellina)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: missing module names in email package

Initial Comment:
Documentation for modules inside the email package 
lacks reference to module name in title (and body too).
By example, there is no clue in 12.2.1 that the Message 
class being described is contained in the email.Message 
module. Or 12.2.2 doesnt menction that FeedParser, 
HeaderParser and Parser are all classes contained in 
module email.Parser. And so on.

Looking at other similar standard packages (like 
curses) seems that the module name should appear first 
in the title.


--

>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2006-07-27 22:19

Message:
Logged In: YES 
user_id=12800

This is actually handled in Python 2.5 (email 4.0) much
better, and I don't plan on backporting this to Python 2.4
(email 3.0).

--

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-04-26 19:16

Message:
Logged In: YES 
user_id=3066

Assigned to the email tsar.  This is complicated by the
dual-naming approach for Python 2.5.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1391608&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1513913 ] mimetools message's To field can't be changed

[SourceForge.net]

Bugs item #1513913, was opened at 2006-06-28 06:51
Message generated for change (Settings changed) made by bwarsaw
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1513913&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: Rejected
Priority: 5
Submitted By: Albert Strasheim (fullung2)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: mimetools message's To field can't be changed

Initial Comment:
Steps to reproduce:

>>> from email.MIMEText import MIMEText
>>> msg = MIMEText('')
>>> msg['To'] = '[EMAIL PROTECTED]'
>>> msg['To']
'[EMAIL PROTECTED]'
>>> msg['To'] = '[EMAIL PROTECTED]'
>>> msg['To']
'[EMAIL PROTECTED]' (should be @baz.com?)

Same problem exists in Python 2.4.3 and Python 2.5b1.

--

>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2006-07-27 22:29

Message:
Logged In: YES 
user_id=12800

Remember that you can add multiple headers to any message,
so in you're example you've added two To headers.  Also
remember that the dictionary interface will return one of
those multiple headers, but not all of them.  Use
msg.get_all('to') to see them all or del msg['to'] to delete
them all.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1513913&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1481650 ] Docs on import of email.MIMExxx classes wrong

[SourceForge.net]

Bugs item #1481650, was opened at 2006-05-04 03:24
Message generated for change (Comment added) made by bwarsaw
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1481650&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.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Hugh Gibson (hgibson50)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: Docs on import of email.MIMExxx classes wrong

Initial Comment:
http://docs.python.org/lib/node588.html says: 

--
Each of these classes should be imported from a module 
with the same name as the class, from within the email 
package. E.g.: 


import email.MIMEImage.MIMEImage

or 

from email.MIMEText import MIMEText
--

However, here is a Python IDLE session showing that 
the first import format doesn't work:

--
Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 
32 bit (Intel)] on win32
Type "copyright", "credits" or "license()" for more 
information.



IDLE 1.1.3  
>>> import email.MIMEImage.MIMEImage

Traceback (most recent call last):
  File "", line 1, in -toplevel-
import email.MIMEImage.MIMEImage
ImportError: No module named MIMEImage
>>> 
--

This method *does* work:

--
>>> import email.MIMEImage
>>> 
--

This got one of my inexperienced programmers tied up 
in knots!

Hugh

--

>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2006-07-27 22:36

Message:
Logged In: YES 
user_id=12800

r50890


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1481650&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1529297 ] unrelated variable messing up doctests

[SourceForge.net]

Bugs item #1529297, was opened at 2006-07-26 15:02
Message generated for change (Comment added) made by macquigg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529297&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.5
Status: Open
Resolution: None
Priority: 5
Submitted By: David MacQuigg (macquigg)
Assigned to: Nobody/Anonymous (nobody)
Summary: unrelated variable messing up doctests

Initial Comment:
Version 2.5b2 with IDLE 1.2b2 running on Windows XP 
Home, fully updated.

Unpack the attached zip file.
Open program.py, test_suite.py, in separate IDLE 
windows.  
Run test_suite.py.  
  8 passed and 0 failed.
Now add a variable at the top of program.py, any name 
will do.
  xyz = 2
Re-run test_suite.py.  
  7 passed and 1 failed !!

I haven't been able to isolate the problem, but it is 
repeatable.  Taking out blocks of unrelated statements 
changes the behavior.  Feels like a memory allocation 
error, or something strange.


--

>Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 20:09

Message:
Logged In: YES 
user_id=676422

I've got a workaround.  I changed the names of my test 
functions to _1connect, _2hello, _3envfrom, _4envrcpt, 
_5addheader, and _6eom.
Could we set the order explicitly, maybe
doctest.order = [connect, hello, envfrom, envrcpt, ... ]


--

Comment By: Tim Peters (tim_one)
Date: 2006-07-27 18:31

Message:
Logged In: YES 
user_id=31435

> would it be possible to run the tests in the order
> they are written, rather than in alphabetical order?

Sorry, that's impossible.  doctest never sees the source
code, it crawls through module and class __dict__s to find
objects with docstrings, and the order things appear in
those is undefined.

--

Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 18:03

Message:
Logged In: YES 
user_id=676422

I hope this is not too much to ask, but would it be 
possible to run the tests in the order they are written, 
rather than in alphabetical order?  This isn't a big deal, 
as long as the order is stable, but it would abide by the 
rule of least astonishment. :>)

--

Comment By: Tim Peters (tim_one)
Date: 2006-07-27 17:53

Message:
Logged In: YES 
user_id=31435

Glad it solved your mystery!  Note that 2.4.4 and 2.5 /will/
sort the tests by name again (the code for that has already
been checked in) -- it was very intentional that it did that
before 2.4, and it was a bug that it stopped doing it in 2.4
through 2.4.3.  OTOH, you're the only one so far who noticed :-)

--

Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 17:46

Message:
Logged In: YES 
user_id=676422

That fixed it!!  Nice catch.

I've been aware for some time of the sensitivity to order 
in the doctests, but it has never been a problem until now, 
and I've been writing programs with doctests since 2.3.  
When I add a test, and it breaks a later test, it has 
always been easy to nail down the piece that changed.

This "behind the scenes" change of test order seems like 
the kind of problem that rarely occurs, but can cause 
serious problems when it does.

Thanks again for an excellent followup.

--

Comment By: Tim Peters (tim_one)
Date: 2006-07-27 17:01

Message:
Logged In: YES 
user_id=31435

DocTestFinder has been changed to sort test names again, in
revs 50882 (on the trunk, for 2.5) and 50886 (on the 2.4
branch, for 2.4.4).

--

Comment By: Tim Peters (tim_one)
Date: 2006-07-27 16:21

Message:
Logged In: YES 
user_id=31435

I think I know what's happening here.  doctest was largely
rewritten for Python 2.4, and it lost a subtle intended
feature:  it used to (<= 2.3) sort tests by name before
running them, but in 2.4 started running them in whatever
order they happen to appear in the hash-code-based module
__dict__.

Changing the namespace in program.py in seemingly random
ways matters because test_suite.py starts with

from program import *

and so everything in program.py's module namespace
"pollutes" test_suite.py's namespace too.  That can change
the order tests run in.  And as I noted before, whether or
not the doctest for _envrcpt() passes or fails depends on
whether or not the doctests for _hello() run before them,
due to side effects on the shared `ci` instance.  Look at
your output carefully, and I expect you'll find that the
order of tests /does/ change depending on crap variabl

[ python-Bugs-1414018 ] email.Utils.py: UnicodeError in RFC2322 header

[SourceForge.net]

Bugs item #1414018, was opened at 2006-01-24 15:19
Message generated for change (Comment added) made by bwarsaw
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1414018&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.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: A. Sagawa (qbin)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: email.Utils.py: UnicodeError in RFC2322 header

Initial Comment:
Description:
collapse_rfc2231_value does not handle UnicodeError
exception. Therefore a header like this one can cause
UnicodeError in attempting unicode conversion.

---
Content-Type: text/plain; charset="ISO-2022-JP"
Content-Disposition: attachment;
 filename*=iso-2022-jp''%1B%24BJs9p%3Dq%2D%21%1B%28B%2Etxt
---

Test script:
---
#! /usr/bin/env python
import sys
import email

msg = email.message_from_file(sys.stdin)
for part in msg.walk():
  print part.get_params()
  print part.get_filename()
---
run
% env LANG=ja_JP.eucJP ./test.py < attached_sample.eml

Background:
Character 0x2d21 is invalid in JIS X0208 but defined in
CP932 (Shift_JIS's superset by Microsoft).  Conversion
between Shift_JIS and ISO-2022-JP are computable
because both of them based on JIS X0208. So sometimes
CP932 characters appear in ISO-2022-JP encoded string,
typically produced by Windows MUA.
But Python's "ISO-2022-JP" means *pure* JIS X0208, thus
conversion is failed.

Workaround:
Convert to fallback_charset and/or skip invalid character.

--

>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2006-07-27 23:19

Message:
Logged In: YES 
user_id=12800

r50894 for Python 2.4/email 3.0.  This is already fixed in
Python 2.5/email 4.0


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1414018&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1528802 ] Turkish Character

[SourceForge.net]

Bugs item #1528802, was opened at 2006-07-26 10:05
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=1528802&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: Open
Resolution: None
Priority: 5
Submitted By: Ahmet Bişkinler (ahmetbiskinler)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Turkish Character

Initial Comment:
>>> print "Mayıs".upper()
>>> MAYıS
>>> import locale
>>> locale.setlocale(locale.LC_ALL,'Turkish_Turkey.1254')
>>> print "Mayıs".upper()
>>> MAYıS

>>> print "ğüşiöçı".upper()
>>> ğüşIöçı


MAYıS should be MAYIS
ğüşIöçı   should be ĞÜŞİÖÇI

but 
>>> "Mayıs".upper()
>>> "MAYIS"

is right





--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1528802&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1529297 ] unrelated variable messing up doctests

[SourceForge.net]

Bugs item #1529297, was opened at 2006-07-26 18:02
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529297&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.5
Status: Open
Resolution: None
Priority: 5
Submitted By: David MacQuigg (macquigg)
Assigned to: Nobody/Anonymous (nobody)
Summary: unrelated variable messing up doctests

Initial Comment:
Version 2.5b2 with IDLE 1.2b2 running on Windows XP 
Home, fully updated.

Unpack the attached zip file.
Open program.py, test_suite.py, in separate IDLE 
windows.  
Run test_suite.py.  
  8 passed and 0 failed.
Now add a variable at the top of program.py, any name 
will do.
  xyz = 2
Re-run test_suite.py.  
  7 passed and 1 failed !!

I haven't been able to isolate the problem, but it is 
repeatable.  Taking out blocks of unrelated statements 
changes the behavior.  Feels like a memory allocation 
error, or something strange.


--

>Comment By: Tim Peters (tim_one)
Date: 2006-07-27 23:34

Message:
Logged In: YES 
user_id=31435

Renaming the tests isn't a workaround in the absence of
sorting:  nothing is guaranteed about __dict__ traversal
order, because nothing is defined about string hash codes.

You could suggest adding a way to force order as a new
feature request, but I won't look at it.  It should simply
never be necessary for /reasonable/ tests.  And, yes, that
means I think it's unreasonable to write tests that rely on
side effects across distinct tests occurring in a specific
order :-)

At this point I suggest you stop writing doctests in
function docstrings and use the newer doctest /file/
facilities instead.  Then you can have a file full of tests
run in exactly the order you want -- although it's still
dubious practice to rely on side effects across distinct
sections of tests.

If you have to force order across function docstring tests,
you'll have to build your doctest driver out of lower-level
doctest components.  That means, e.g., creating your own
instance of DocTestFinder, forcing the test order you want
in the list of test objects it creates, and feeding them
into a DocTestRunner instance.

--

Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 23:09

Message:
Logged In: YES 
user_id=676422

I've got a workaround.  I changed the names of my test 
functions to _1connect, _2hello, _3envfrom, _4envrcpt, 
_5addheader, and _6eom.
Could we set the order explicitly, maybe
doctest.order = [connect, hello, envfrom, envrcpt, ... ]


--

Comment By: Tim Peters (tim_one)
Date: 2006-07-27 21:31

Message:
Logged In: YES 
user_id=31435

> would it be possible to run the tests in the order
> they are written, rather than in alphabetical order?

Sorry, that's impossible.  doctest never sees the source
code, it crawls through module and class __dict__s to find
objects with docstrings, and the order things appear in
those is undefined.

--

Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 21:03

Message:
Logged In: YES 
user_id=676422

I hope this is not too much to ask, but would it be 
possible to run the tests in the order they are written, 
rather than in alphabetical order?  This isn't a big deal, 
as long as the order is stable, but it would abide by the 
rule of least astonishment. :>)

--

Comment By: Tim Peters (tim_one)
Date: 2006-07-27 20:53

Message:
Logged In: YES 
user_id=31435

Glad it solved your mystery!  Note that 2.4.4 and 2.5 /will/
sort the tests by name again (the code for that has already
been checked in) -- it was very intentional that it did that
before 2.4, and it was a bug that it stopped doing it in 2.4
through 2.4.3.  OTOH, you're the only one so far who noticed :-)

--

Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 20:46

Message:
Logged In: YES 
user_id=676422

That fixed it!!  Nice catch.

I've been aware for some time of the sensitivity to order 
in the doctests, but it has never been a problem until now, 
and I've been writing programs with doctests since 2.3.  
When I add a test, and it breaks a later test, it has 
always been easy to nail down the piece that changed.

This "behind the scenes" change of test order seems like 
the kind of problem that rarely occurs, but can cause 
serious problems when it does.

Thanks again for an excellent followup.

--

Comment By: Tim

[ python-Bugs-1529998 ] bz2 lib missing from source distribution

[SourceForge.net]

Bugs item #1529998, was opened at 2006-07-27 14:45
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529998&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: 3rd Party
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: james yoo (jyoo_abn)
Assigned to: Nobody/Anonymous (nobody)
Summary: bz2 lib missing from source distribution

Initial Comment:
python 2.4.3

got an import error trying to test PySqlite 

"No module named bz2"

checked my python dirs and yep, no bz2... I thought
that the bz2 module was part of the standard distribution?

checked the python source dir (python-2.4.3.tar.gz) and
no bz2.py in the Lib dir.

what gives?



--

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-27 21:35

Message:
Logged In: YES 
user_id=33168

You'll need to ensure the bz2 dev headers and libraries are
installed to build/use the bz2 module in python.

--

Comment By: james yoo (jyoo_abn)
Date: 2006-07-27 15:30

Message:
Logged In: YES 
user_id=1562754

actually sorry for the poor assumptions regarding the
existence of a bz2.py file... realize that there is a a
bz2module.c file and that my config.log had a bunch of fatal
ld errors... 

fyi: this is on sunOS 5.8, gcc-3.4.3..

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529998&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1529297 ] unrelated variable messing up doctests

[SourceForge.net]

Bugs item #1529297, was opened at 2006-07-26 15:02
Message generated for change (Settings changed) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529297&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.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: David MacQuigg (macquigg)
Assigned to: Nobody/Anonymous (nobody)
Summary: unrelated variable messing up doctests

Initial Comment:
Version 2.5b2 with IDLE 1.2b2 running on Windows XP 
Home, fully updated.

Unpack the attached zip file.
Open program.py, test_suite.py, in separate IDLE 
windows.  
Run test_suite.py.  
  8 passed and 0 failed.
Now add a variable at the top of program.py, any name 
will do.
  xyz = 2
Re-run test_suite.py.  
  7 passed and 1 failed !!

I haven't been able to isolate the problem, but it is 
repeatable.  Taking out blocks of unrelated statements 
changes the behavior.  Feels like a memory allocation 
error, or something strange.


--

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-27 21:37

Message:
Logged In: YES 
user_id=33168

Closing again since the bug has been fixed.  If you want a
feature request, you can open a new one.

--

Comment By: Tim Peters (tim_one)
Date: 2006-07-27 20:34

Message:
Logged In: YES 
user_id=31435

Renaming the tests isn't a workaround in the absence of
sorting:  nothing is guaranteed about __dict__ traversal
order, because nothing is defined about string hash codes.

You could suggest adding a way to force order as a new
feature request, but I won't look at it.  It should simply
never be necessary for /reasonable/ tests.  And, yes, that
means I think it's unreasonable to write tests that rely on
side effects across distinct tests occurring in a specific
order :-)

At this point I suggest you stop writing doctests in
function docstrings and use the newer doctest /file/
facilities instead.  Then you can have a file full of tests
run in exactly the order you want -- although it's still
dubious practice to rely on side effects across distinct
sections of tests.

If you have to force order across function docstring tests,
you'll have to build your doctest driver out of lower-level
doctest components.  That means, e.g., creating your own
instance of DocTestFinder, forcing the test order you want
in the list of test objects it creates, and feeding them
into a DocTestRunner instance.

--

Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 20:09

Message:
Logged In: YES 
user_id=676422

I've got a workaround.  I changed the names of my test 
functions to _1connect, _2hello, _3envfrom, _4envrcpt, 
_5addheader, and _6eom.
Could we set the order explicitly, maybe
doctest.order = [connect, hello, envfrom, envrcpt, ... ]


--

Comment By: Tim Peters (tim_one)
Date: 2006-07-27 18:31

Message:
Logged In: YES 
user_id=31435

> would it be possible to run the tests in the order
> they are written, rather than in alphabetical order?

Sorry, that's impossible.  doctest never sees the source
code, it crawls through module and class __dict__s to find
objects with docstrings, and the order things appear in
those is undefined.

--

Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 18:03

Message:
Logged In: YES 
user_id=676422

I hope this is not too much to ask, but would it be 
possible to run the tests in the order they are written, 
rather than in alphabetical order?  This isn't a big deal, 
as long as the order is stable, but it would abide by the 
rule of least astonishment. :>)

--

Comment By: Tim Peters (tim_one)
Date: 2006-07-27 17:53

Message:
Logged In: YES 
user_id=31435

Glad it solved your mystery!  Note that 2.4.4 and 2.5 /will/
sort the tests by name again (the code for that has already
been checked in) -- it was very intentional that it did that
before 2.4, and it was a bug that it stopped doing it in 2.4
through 2.4.3.  OTOH, you're the only one so far who noticed :-)

--

Comment By: David MacQuigg (macquigg)
Date: 2006-07-27 17:46

Message:
Logged In: YES 
user_id=676422

That fixed it!!  Nice catch.

I've been aware for some time of the sensitivity to order 
in the doctests, but it has never been a problem until now, 
and I've been writing programs with doctests since 2.3.  
When I add a test, and it breaks a later test, it has 
always been easy to nail down the piece that c

[ python-Bugs-1529871 ] distutils regression related to Distribution.run_command

[SourceForge.net]

Bugs item #1529871, was opened at 2006-07-27 17:49
Message generated for change (Comment added) made by pje
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529871&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: 6
Submitted By: Collin Winter (collinwinter)
Assigned to: Phillip J. Eby (pje)
Summary: distutils regression related to Distribution.run_command

Initial Comment:
The following used to work in Python 2.4.x but fails
under Python 2.5:

>>> import setuptools
>>> import distutils.core
>>> distutils.core._setup_stop_after = 'config'
>>> 
>>> import setup
>>> setup.dist.run_command('test')

Where setup.dist is an instance of
distutils.core.Distribution (which setuptools replaces
with setuptools.dist.Distribution).

Under Python 2.4.x, this code would execute setuptools'
test command. Under Python 2.5b2 (as of r50855), this
code results in the following exception:

/opt/dev/python/2.5/lib/python2.5/distutils/dist.py:263:
UserWarning: Unknown distribution option: 'test_suite'
  warnings.warn(msg)
Traceback (most recent call last):
  File "test.py", line 8, in 
setup.dist.run_command('test')
  File
"/opt/dev/python/2.5/lib/python2.5/distutils/dist.py",
line 992, in run_command
cmd_obj = self.get_command_obj(command)
  File
"/opt/dev/python/2.5/lib/python2.5/distutils/dist.py",
line 868, in get_command_obj
klass = self.get_command_class(command)
  File
"/opt/dev/python/2.5/lib/python2.5/site-packages/setuptools/dist.py",
line 357, in get_command_class
return _Distribution.get_command_class(self, command)
  File
"/opt/dev/python/2.5/lib/python2.5/distutils/dist.py",
line 851, in get_command_class
raise DistutilsModuleError("invalid command '%s'" %
command)
distutils.errors.DistutilsModuleError: invalid command
'test'

I'd greatly appreciate it if this regression could be
fixed before Python 2.5 is released.

--

>Comment By: Phillip J. Eby (pje)
Date: 2006-07-28 04:53

Message:
Logged In: YES 
user_id=56214

Um, why is there a py2.4 egg on your python 2.5 path?

Setuptools configures itself according to the Python version
it is built with, so a 2.4 egg is not going to be correctly
configured for 2.5.  I don't know if this is related to your
problem or not, but I was unable to reproduce your problem
with a setuptools 0.7a1 checkout.  I was only able to
reproduce it with setuptools 0.6.


--

Comment By: Collin Winter (collinwinter)
Date: 2006-07-27 22:12

Message:
Logged In: YES 
user_id=1344176

I've tried using setuptools 0.7a1 in conjunction with Python
2.5b2 (r50877), and the problem still exists. setuptools'
extension commands still do not work (tested: rotate, alias,
egg_info, bdist_egg, test), that is, 'python2.5 setup.py
test' still fails with "error: invalid command 'test'".

Also, the code snippet in the bug report does not work. I am
sure Python is picking up setuptools 0.7a1 because the path
/opt/dev/python/2.5/lib/python2.5/site-packages/setuptools-0.7a1dev_r50755-py2.4.egg/setuptools/dist.py
appears in the traceback.

--

Comment By: Phillip J. Eby (pje)
Date: 2006-07-27 21:13

Message:
Logged In: YES 
user_id=56214

Problem source confirmed: reverting the PEP 302 breakage of
r46372 (need-for-speed import cache hack) fixes the problem.

setuptools 0.7a1 doesn't show any problems because it uses
2.5's "pkgutil" module if possible, and r46372 patches
pkgutil in a way that masks the problem, at least as far as
setuptools is concerned, for this one specific feature. 
(Other code in setuptools is affected in both 0.6 *and* 0.7,
and will require further workaround code to be written.)



--

Comment By: Phillip J. Eby (pje)
Date: 2006-07-27 18:35

Message:
Logged In: YES 
user_id=56214

I can't reproduce this using setuptools 0.7a1 and the Python
2.5 trunk.  Please note that setuptools 0.6 does *not*
support Python 2.5; there were numerous changes needed and
there may still be additional changes needed.  Please try
using setuptools 0.7a1 and let me know what you find out. 
Thanks.


--

Comment By: Collin Winter (collinwinter)
Date: 2006-07-27 18:34

Message:
Logged In: YES 
user_id=1344176

Further testing reveals that all of setuptools' extension
commands (tested: egg_info, bdist_egg, test, rotate, alias)
are broken under Python 2.5b2, even when called from the
command line, like so:

$ python2.5 setup.py egg_info

This produces an "error: invalid command: 'egg_info'" message.

[ python-Bugs-1529269 ] Python 2.5b2 fails to build on Solaris 10 (GCC Compiler)

[SourceForge.net]

Bugs item #1529269, was opened at 2006-07-26 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=1529269&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: Guido Ostkamp (ostkamp)
Assigned to: Thomas Heller (theller)
Summary: Python 2.5b2 fails to build on Solaris 10 (GCC Compiler)

Initial Comment:
Hello,

as promised here is the second report because of
problems with building Python 2.5b2 on Solaris 10
(Sparc). I have been using the GCC this time.

These are the problems (for full logs please see
attachments):

building '_ctypes' extension
gcc -shared
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modules
/_ctypes/_ctypes.o
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/
Modules/_ctypes/callbacks.o
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Pyth
on-2.5b2/Modules/_ctypes/callproc.o
build/temp.solaris-2.10-sun4us-2.5/home/ostk
amp/Python-2.5b2/Modules/_ctypes/stgdict.o
build/temp.solaris-2.10-sun4us-2.5/ho
me/ostkamp/Python-2.5b2/Modules/_ctypes/cfield.o
build/temp.solaris-2.10-sun4us-
2.5/home/ostkamp/Python-2.5b2/Modules/_ctypes/malloc_closure.o
build/temp.solari
s-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/prep_cif.
o
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modules/_ctypes/l
ibffi/src/sparc/ffi.o
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5
b2/Modules/_ctypes/libffi/src/sparc/v8.o
build/temp.solaris-2.10-sun4us-2.5/home
/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v9.o
-o build/lib.solaris
-2.10-sun4us-2.5/_ctypes.so
ld: fatal: relocation error: R_SPARC_32: file
build/temp.solaris-2.10-sun4us-2.5
/home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o:
symbol : offset 0xfeedcca5 is non-aligned
ld: fatal: relocation error: R_SPARC_32: file
build/temp.solaris-2.10-sun4us-2.5
/home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o:
symbol : offset 0xfeedccab is non-aligned
ld: fatal: relocation error: R_SPARC_32: file
build/temp.solaris-2.10-sun4us-2.5
/home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o:
symbol : offset 0xfeedccaf is non-aligned
ld: fatal: relocation error: R_SPARC_32: file
build/temp.solaris-2.10-sun4us-2.5
/home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o:
symbol : offset 0xfeedccb3 is non-aligned
ld: fatal: relocation error: R_SPARC_32: file
build/temp.solaris-2.10-sun4us-2.5
/home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o:
symbol : offset 0xfeeeae06 is non-aligned
ld: fatal: relocation error: R_SPARC_32: file
build/temp.solaris-2.10-sun4us-2.5
/home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o:
symbol : offset 0xfeeecaf6 is non-aligned
collect2: ld returned 1 exit status

building '_curses' extension
gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall
-Wstrict-prototypes -I. -I/
home/ostkamp/Python-2.5b2/./Include -I./Include -I.
-I/home/ostkamp/Python-2.5b2
/Include -I/home/ostkamp/Python-2.5b2 -c
/home/ostkamp/Python-2.5b2/Modules/_cur
sesmodule.c -o
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modu
les/_cursesmodule.o
/home/ostkamp/Python-2.5b2/Modules/_cursesmodule.c: In
function `PyCursesWindow_
GetStr':
/home/ostkamp/Python-2.5b2/Modules/_cursesmodule.c:822:
warning: implicit declar
ation of function `mvwgetnstr'
gcc -shared
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modules
/_cursesmodule.o -lcurses -ltermcap -o
build/lib.solaris-2.10-sun4us-2.5/_curses
.so
*** WARNING: renaming "_curses" since importing it
failed: ld.so.1: python: fata
l: relocation error: file
build/lib.solaris-2.10-sun4us-2.5/_curses.so: symbol m
vwgetnstr: referenced symbol not found
building '_curses_panel' extension
gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall
-Wstrict-prototypes -I. -I/
home/ostkamp/Python-2.5b2/./Include -I./Include -I.
-I/home/ostkamp/Python-2.5b2
/Include -I/home/ostkamp/Python-2.5b2 -c
/home/ostkamp/Python-2.5b2/Modules/_cur
ses_panel.c -o
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modu
les/_curses_panel.o
gcc -shared
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modules
/_curses_panel.o -lpanel -lcurses -ltermcap -o
build/lib.solaris-2.10-sun4us-2.5
/_curses_panel.so
*** WARNING: renaming "_curses_panel" since importing
it failed: No module named
 _curses
running build_scripts

Regards,

Guido

--

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-27 21:53

Message:
Logged In: YES 
user_id=33168

Hmmm, I thought this was the report from using sun studio
compiler.  Guido, are you sure you did a make clean in
between using different compilers?

--

[ python-Bugs-1191458 ] [AST] Failing tests

[SourceForge.net]

Bugs item #1191458, was opened at 2005-04-27 20:30
Message generated for change (Settings changed) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1191458&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: AST
Status: Open
Resolution: None
>Priority: 9
Submitted By: Brett Cannon (bcannon)
Assigned to: Jeremy Hylton (jhylton)
Summary: [AST] Failing tests

Initial Comment:
This tracker item is to be used to keep track of what
tests are currently failing on the AST branch.  This is
somewhat important sinced there are so many failures it
can be hard to detect if a change fixed what it was
supposed to or actually managed to break more code.

When posting follow-ups of fixed tests, please re-list
the currently failing tests so as to make it simple to
reference the current state of things.

So, the current offenders are (from a straight
``regrtest.py`` run on my OS X box, which always has
test__locale fail so I removed it)::

test_compile test_cookielib test_dis test_doctest
test_future test_genexps test_inspect
test_itertools test_new
test_peepholer test_scope test_socket test_sort
test_subprocess
test_symtable test_syntax test_trace test_traceback
test_warnings
test_zipfile

--

Comment By: Jeremy Hylton (jhylton)
Date: 2006-04-03 08:31

Message:
Logged In: YES 
user_id=31392

Just wanted to note that I have fixes for the failing tests
on my laptop.  Need to sync with the current trunk before I
can check in.


--

Comment By: Brett Cannon (bcannon)
Date: 2005-10-25 15:03

Message:
Logged In: YES 
user_id=357491

Yep, all tests pass, so that just leaves the test_trace
tests that are currently commented out.

--

Comment By: Neil Schemenauer (nascheme)
Date: 2005-10-23 21:51

Message:
Logged In: YES 
user_id=35752

I believe the only remaining broken tests are the ones
commented out in test_trace.

--

Comment By: Jeremy Hylton (jhylton)
Date: 2005-10-07 11:46

Message:
Logged In: YES 
user_id=31392

test_dis update:

Fixed one of two failing tests.  test_dis() was easy. 
test_bug_708901() is harder.  The current AST only stores
line numbers for statements.  The test case is checking that
the lnotab can assign a single statement multiple line
numbers; in this case, the statement spans multiple lines
and the disassembled code should reflect that.  The fix is
probably to add line numbers to expressions, which requires
changing the AST definition and updating ast.c to assign
line numbers.

--

Comment By: Jeremy Hylton (jhylton)
Date: 2005-10-07 11:01

Message:
Logged In: YES 
user_id=31392

Here's a quick status report on Linux + GCC 3.2.2 from today:

12 tests failed:
test_dis test_doctest test_future test_genexps test_inspect
test_new test_peepholer test_pwd test_scope test_subprocess
test_symtable test_trace

7 skips unexpected on linux2:
test_hotshot test_bsddb test_email test_parser
test_transformer
test_email_codecs test_compiler

I'm going to trace into the details of why each of these
tests is failing.


--

Comment By: Brett Cannon (bcannon)
Date: 2005-07-10 21:15

Message:
Logged In: YES 
user_id=357491

Scratch the "all open bugs" comment; didn't get to bug #1195576.

--

Comment By: Brett Cannon (bcannon)
Date: 2005-07-10 21:13

Message:
Logged In: YES 
user_id=357491

After applying all patches associated with all open bugs,
the failing tests from ``./python.exe Lib/test/regrtest.py``
are:

14 tests failed:
test_cookielib test_dis test_future test_genexps
test_inspect
test_new test_peepholer test_scope test_subprocess
test_symtable
test_syntax test_trace test_traceback test_warnings

--

Comment By: Nick Coghlan (ncoghlan)
Date: 2005-05-28 04:40

Message:
Logged In: YES 
user_id=1038590

Fixing #1186353 (lambda argument unpacking) fixes test_sort and  
test_itertools: 
 
17 tests failed: 
test_compile test_cookielib test_dis test_doctest test_future 
test_genexps test_inspect test_new test_ossaudiodev 
test_peepholer 
test_scope test_subprocess test_symtable test_syntax test_trace 
test_traceback test_warnings 
 

--

Comment By: Nick Coghlan (ncoghlan)
Date: 2005-05-28 01:33

Message:
Logged In: YES 
user_id=1038590

[ python-Bugs-1530142 ] Mac Universal Build of Python confuses distutils

[SourceForge.net]

Bugs item #1530142, was opened at 2006-07-28 16:02
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=1530142&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: Mac Universal Build of Python confuses distutils

Initial Comment:
I'm sorry I can't provide a fully-detailed report 
here, but I'm not in a position to be able to 
reproduce the problem.

In short, I installed the Universal build of Python 
2.4.3 for the Mac downloaded from:

http://pythonmac.org/packages/py24-fat/index.html

I don't know whether this is the same as the download 
from:

http://www.python.org/download/releases/2.4.3/

Once installed, I attempted to build ctypes.

The build failed due to an assembly error (unknown 
instruction). I'm not familiar with the PPC or x86 
assembler code so couldn't do a thorough analysis.

I needed Python2.4 to work, so I found an older 
PPC-only installer and used that.


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530142&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1519571 ] turtle.py Docs still incomplete

[SourceForge.net]

Bugs item #1519571, was opened at 2006-07-09 10:49
Message generated for change (Settings changed) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1519571&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: Lingl (gregorlingl)
Assigned to: Martin v. Löwis (loewis)
Summary: turtle.py Docs still incomplete

Initial Comment:
There are three functions in turtle.py (which do not
occur as methods of Pen), which are still not
documented:

setup()
title()
done()

Regards,
Gregor

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1519571&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1469557 ] FTP modue functions are not re-entrant, give odd exceptions

[SourceForge.net]

Bugs item #1469557, was opened at 2006-04-13 02:13
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1469557&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.4
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: brucepeterson (brucepeterson)
Assigned to: Nobody/Anonymous (nobody)
Summary: FTP modue functions are not re-entrant,give odd exceptions

Initial Comment:
 If I define a class using the Thread and FTP moudles, 
start a process which gathers FTP responses, 
additional calls to the class may have the responses 
of the thread instead of the main loop (or vice versa)
  This causes weird and unexpected exceptions from the 
ftplib.

  For instance I get the following error when the 
thread process does a pwd() function
error_reply: 213 34603008  

  The "213" reply is a response from the main process 
size() function

-
Code
-
from time import sleep
from threading import Thread

class ftpMachine(Thread, ftplib.FTP):
def __init__(self, svr, user, passwd):
Thread.__init__(self)
ftplib.FTP.__init__(self, svr, user, passwd)

def run(self):
for x in xrange(20):
output="Thread -"+str(self.nlst())[:30]
print output
sleep (0.0100)

def main():
aCon = ftpMachine("LocalFTP", "user", "")
aCon.start()
for x in xrange(20):
output = "Main -- " + str(aCon.size("File"))
print output  
sleep (0.010)

Workround:
  Rewrite code to create a third worker thread for 
response isolation?  Don't know that this would solve 
the problem.


---
Exception example
---

Exception in thread Thread-1:
Traceback (most recent call last):
  File "C:\Python24\lib\threading.py", line 442, in 
__bootstrap
self.run()
  File "dualFTPIssue.py", line 17, in run
output  = "Thread output " + str(self.nlst())[:30]
+" ..."
  File "C:\Python24\lib\ftplib.py", line 448, in nlst
self.retrlines(cmd, files.append)
  File "C:\Python24\lib\ftplib.py", line 396, in 
retrlines
conn = self.transfercmd(cmd)
  File "C:\Python24\lib\ftplib.py", line 345, in 
transfercmd
return self.ntransfercmd(cmd, rest)[0]
  File "C:\Python24\lib\ftplib.py", line 321, in 
ntransfercmd
host, port = self.makepasv()
  File "C:\Python24\lib\ftplib.py", line 299, in 
makepasv
host, port = parse227(self.sendcmd('PASV'))
  File "C:\Python24\lib\ftplib.py", line 566, in 
parse227
raise error_reply, resp
error_reply: 213 34603008

--

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-28 08:26

Message:
Logged In: YES 
user_id=580910

I don't understand why you cannot use two connection resources. Are you 
running in a severely resource constrained environment?

Anyway, what you're doing right now is undefined behaviour. Unless explicitly 
stated otherwise classes in the stdlib aren't fully reentrant. You will 
therefore 
have to arrange some kind of exclusion mechanism. One way of doing that is 
to introduce a lock (probably wrapping the FTP client instead of using 
multiple inheritance in the progress). Another way it to introduce a 3th thread 
that performs the actual FTP operations and communicate with that using a 
queue. Please ask around on python-list/comp.lang.python if you need help 
with this.

BTW. I didn't close this bug, although I do understand why it was closed: the 
behaviour you describe isn't a bug but expected behaviour. 

--

Comment By: brucepeterson (brucepeterson)
Date: 2006-07-27 23:39

Message:
Logged In: YES 
user_id=1500983

Unfortunately I can't start two instances of the FTP client 
as the separate instances use two conneciton resources.  I 
was hoping for a non-exception when a unexpsected response 
happens.  That would require re-working the module.
  For my workaround I set a time to determine when the 
transfer should complete instead of a querry.

  Thanks for your attention in this matter.

  Closing this bug as my case is an unusual one.

--

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-13 13:54

Message:
Logged In: YES 
user_id=580910

IMHO this isn't a bug, your accessing a shared resource (the FTP connection) 
from two threads without locking. Most of python's libraries aren't safe for 
this 
kind of use.

BTW. The fact that you subclass form thread and ftplib.FTP is immaterial, you 
will get the same effect if you create an ftplib.FTP and then use it in two 
threads.

--

You can respond by v

[ python-Feature Requests-1528593 ] Printing: No print dialog or page setup

[SourceForge.net]

Feature Requests item #1528593, was opened at 2006-07-25 15:49
Message generated for change (Comment added) made by kbk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1528593&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.6
Status: Open
Resolution: None
Priority: 3
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Nobody/Anonymous (nobody)
>Summary: Printing: No print dialog or page setup

Initial Comment:
The printing solution for IDLE on OSX is lacking a page setup dialog, or 
even a print dialog. This means output will also be sent to the default 
printer.

If there is no default printer (which means the user hasn't defined a 
printer at all) the user will get a confusing message (lpr failed). BTW. the 
message is clear for technical users, but not for mac users that aren't unix 
saffy.

It would be nice if IDLE could interface with the Carbon/Cocoa print 
system using a real print dialog. That way users can select another than 
the default printer, change page settings and can even print to PDF.

I've filed this as a low-priority issue for 2.6 because there's no way this 
will get into 2.5 and it likey non-trivial as well.

BTW. this might be a feature-request rather than a bug.

--

>Comment By: Kurt B. Kaiser (kbk)
Date: 2006-07-26 16:45

Message:
Logged In: YES 
user_id=149084

It's not just an OSX problem.  Printing in IDLE
is very rudimentary at this point.

Making this an RFE.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1528593&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1530142 ] Mac Universal Build of Python confuses distutils

[SourceForge.net]

Bugs item #1530142, was opened at 2006-07-28 08:02
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530142&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: Ronald Oussoren (ronaldoussoren)
Summary: Mac Universal Build of Python confuses distutils

Initial Comment:
I'm sorry I can't provide a fully-detailed report 
here, but I'm not in a position to be able to 
reproduce the problem.

In short, I installed the Universal build of Python 
2.4.3 for the Mac downloaded from:

http://pythonmac.org/packages/py24-fat/index.html

I don't know whether this is the same as the download 
from:

http://www.python.org/download/releases/2.4.3/

Once installed, I attempted to build ctypes.

The build failed due to an assembly error (unknown 
instruction). I'm not familiar with the PPC or x86 
assembler code so couldn't do a thorough analysis.

I needed Python2.4 to work, so I found an older 
PPC-only installer and used that.


--

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-28 08:28

Message:
Logged In: YES 
user_id=580910

Which version of ctypes did you try to build?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530142&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-1528154 ] New sequences for Unicode groups and block ranges needed

[SourceForge.net]

Feature Requests item #1528154, was opened at 2006-07-25 15:44
Message generated for change (Comment added) made by gmarketer
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1528154&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: Regular Expressions
Group: None
Status: Open
Resolution: None
Priority: 6
Submitted By: gmarketer (gmarketer)
Assigned to: Nobody/Anonymous (nobody)
>Summary: New sequences for Unicode groups and block ranges needed

Initial Comment:
The special sequences consist of "\" and another
character need to be added to RE sintax to simplify the
finding of several Unicode classes like:
 * All uppercase letters
 * All lowercase letters


--

>Comment By: gmarketer (gmarketer)
Date: 2006-07-26 13:06

Message:
Logged In: YES 
user_id=1334865

We need to process several strings in utf-8 and need to use
regular expressions to match pattern, for ex.:
r"[ANY_LANGUAGE_UPPERCASE_LETTER,0-9ANY_LANGUAGE_LOWERCASE_LETTER]+|NOT_ANY_LANGUAGE_CURRENCY"

We don't know how to implement this logic by our hands.

Also, I found this logic implemented in Microsoft dot NET
regular expressions:

\p{name}Matches any character in the named character
class 'name'. Supported names are Unicode groups and block
ranges. For example Ll, Nd, Z, IsGreek, IsBoxDrawing, and Sc
(currency). 

\P{name}Matches text not included in the named
character class 'name'. 

We need same logic in regular expressions.


--

Comment By: M.-A. Lemburg (lemburg)
Date: 2006-07-25 18:45

Message:
Logged In: YES 
user_id=38388

Could you make your request a little more specific ?

We already have catregories in the re module, so adding a
few more would be possible (patches are welcome !). However,
we do need to know why you need them and whether there are
other RE implementations that already have such special
matching characters, e.g. the Perl RE implementation.


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1528154&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1530142 ] Mac Universal Build of Python confuses distutils

[SourceForge.net]

Bugs item #1530142, was opened at 2006-07-28 16:02
Message generated for change (Comment added) made by richard
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530142&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: Ronald Oussoren (ronaldoussoren)
Summary: Mac Universal Build of Python confuses distutils

Initial Comment:
I'm sorry I can't provide a fully-detailed report 
here, but I'm not in a position to be able to 
reproduce the problem.

In short, I installed the Universal build of Python 
2.4.3 for the Mac downloaded from:

http://pythonmac.org/packages/py24-fat/index.html

I don't know whether this is the same as the download 
from:

http://www.python.org/download/releases/2.4.3/

Once installed, I attempted to build ctypes.

The build failed due to an assembly error (unknown 
instruction). I'm not familiar with the PPC or x86 
assembler code so couldn't do a thorough analysis.

I needed Python2.4 to work, so I found an older 
PPC-only installer and used that.


--

>Comment By: Richard Jones (richard)
Date: 2006-07-28 16:47

Message:
Logged In: YES 
user_id=6405

0.9.9.6

--

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-28 16:28

Message:
Logged In: YES 
user_id=580910

Which version of ctypes did you try to build?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530142&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com