From noreply at sourceforge.net  Mon May  1 06:55:33 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 30 Apr 2006 21:55:33 -0700
Subject: [ python-Bugs-1479586 ] Segmentation fault while using Tkinter
Message-ID: <E1FaQRZ-0006kI-2Z@sc8-sf-web4-b.sourceforge.net>

Bugs item #1479586, was opened at 2006-05-01 09:25
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=1479586&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: Tkinter
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Ali Gholami Rudi (aligrudi)
Assigned to: Martin v. L??wis (loewis)
Summary: Segmentation fault while using Tkinter

Initial Comment:
While using Tkinter I encountere segmentation faults
regularly. I ran my program using gdb using python2.4
and Fedora Core 5 and received:

(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread -1209063760 (LWP 2024)]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[New Thread -1212232800 (LWP 2027)]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
---Type <return> to continue, or q <return> to quit---
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1209063760 (LWP 2024)]
0x001519ce in TkUndoSetDepth () from /usr/lib/libtk8.4.so
(gdb) 


I ran the same program using python2.5a2 and again
received:

Starting program: /usr/local/bin/python
~/temp/rope/rope/rope.py
Reading symbols from shared object read from target
memory...done.
Loaded system supplied DSO at 0xa05000
[Thread debugging using libthread_db enabled]
[New Thread -1208899920 (LWP 2415)]
[New Thread -1212068960 (LWP 2418)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1208899920 (LWP 2415)]
0x001519ce in TkUndoSetDepth () from /usr/lib/libtk8.4.so
(gdb)


Are these information enough for fixing the problem or
should I send my program?

Thanks


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1479586&group_id=5470

From noreply at sourceforge.net  Mon May  1 08:30:42 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 30 Apr 2006 23:30:42 -0700
Subject: [ python-Bugs-1475162 ] Tkinter hangs in test_tcl
Message-ID: <E1FaRve-00082v-H2@sc8-sf-web3.sourceforge.net>

Bugs item #1475162, was opened at 2006-04-23 23:34
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1475162&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: Tkinter
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Thomas Wouters (twouters)
Assigned to: Martin v. L??wis (loewis)
Summary: Tkinter hangs in test_tcl

Initial Comment:

For a while now, I've noticed test_tcl locking up when
trying to refleaktest it. I was able to reproduce it
quite simply:

import Tkinter, os
if "DISPLAY" in os.environ: del os.environ["DISPLAY"]
tcl = Tkinter.Tcl()
try: tcl.loadtk()
except Exception, e: print e
tcl.loadtk()

Or using _tkinter directly:

import _tkinter, os
if "DISPLAY" in os.environ: del os.environ["DISPLAY"]
tk = _tkinter.create(None, "test", "Tk", 0, 1, 0)
try: tk.loadtk()
except: pass
tk.loadtk()

In either case, the second loadtk never finishes.

It seems that, on my platform at least, Tk_Init()
doesn't like being called twice even when the first
call resulted in an error. That's Tcl and Tk 8.4.12.
Tkapp_Init() (which is the Tkinter part that calls
Tk_Init()) does its best to guard against calling
Tk_Init() twice when the first call was succesful, but
it doesn't remember failure cases. I don't know enough
about Tcl/Tk or Tkinter to know how this is best handled.


----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-05-01 08:30

Message:
Logged In: YES 
user_id=21627

This should now be fixed with r45833 and r45834.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1475162&group_id=5470

From noreply at sourceforge.net  Mon May  1 08:34:12 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 30 Apr 2006 23:34:12 -0700
Subject: [ python-Bugs-1479586 ] Segmentation fault while using Tkinter
Message-ID: <E1FaRz2-0000jt-0s@sc8-sf-web1.sourceforge.net>

Bugs item #1479586, was opened at 2006-05-01 06:55
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1479586&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: Tkinter
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Ali Gholami Rudi (aligrudi)
Assigned to: Martin v. L??wis (loewis)
Summary: Segmentation fault while using Tkinter

Initial Comment:
While using Tkinter I encountere segmentation faults
regularly. I ran my program using gdb using python2.4
and Fedora Core 5 and received:

(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread -1209063760 (LWP 2024)]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[New Thread -1212232800 (LWP 2027)]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
---Type <return> to continue, or q <return> to quit---
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1209063760 (LWP 2024)]
0x001519ce in TkUndoSetDepth () from /usr/lib/libtk8.4.so
(gdb) 


I ran the same program using python2.5a2 and again
received:

Starting program: /usr/local/bin/python
~/temp/rope/rope/rope.py
Reading symbols from shared object read from target
memory...done.
Loaded system supplied DSO at 0xa05000
[Thread debugging using libthread_db enabled]
[New Thread -1208899920 (LWP 2415)]
[New Thread -1212068960 (LWP 2418)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1208899920 (LWP 2415)]
0x001519ce in TkUndoSetDepth () from /usr/lib/libtk8.4.so
(gdb)


Are these information enough for fixing the problem or
should I send my program?

Thanks


----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-05-01 08:34

Message:
Logged In: YES 
user_id=21627

Please do send your program, or better yet a small test case
that allows to reproduce the problem. It looks like a Tk bug
at first glance, in TkUndoSetDepth.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1479586&group_id=5470

From noreply at sourceforge.net  Mon May  1 09:21:07 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 01 May 2006 00:21:07 -0700
Subject: [ python-Bugs-1385040 ] compiler module does not detect a syntax error
Message-ID: <E1FaSiR-00048B-To@sc8-sf-web5.sourceforge.net>

Bugs item #1385040, was opened at 2005-12-19 01:58
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1385040&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Harri Pasanen (harripasanen)
Assigned to: Jeremy Hylton (jhylton)
Summary: compiler module does not detect a syntax error

Initial Comment:
import compiler 
compiler.parse("def foo(a=1,b): pass") 
 
Gives: 
 
Module(None, Stmt([Function(None, 'foo', ['a', 'b'], 
[Const(1)], 0, None, Stmt([Pass()]))])) 
 
However, the python interpreter itself barks for the 
same code: 
 
SyntaxError: non-default argument follows default 
argument 
 
 
-Harri 
 
 

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-05-01 00:21

Message:
Logged In: YES 
user_id=33168

Any reason you do:
  not i >= len(nodelist) 

instead of:
  i < len(nodelist)

?

The patch seems fine if everything passes with -u compiler
test_compiler.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-04-30 13:20

Message:
Logged In: YES 
user_id=849994

Attaching patch. Please review.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-02-25 13:59

Message:
Logged In: YES 
user_id=33168

FYI.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1385040&group_id=5470

From noreply at sourceforge.net  Mon May  1 09:25:23 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 01 May 2006 00:25:23 -0700
Subject: [ python-Bugs-1479586 ] Segmentation fault while using Tkinter
Message-ID: <E1FaSmZ-0006IM-Jp@sc8-sf-web5.sourceforge.net>

Bugs item #1479586, was opened at 2006-04-30 21:55
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1479586&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: Tkinter
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Ali Gholami Rudi (aligrudi)
Assigned to: Martin v. L??wis (loewis)
Summary: Segmentation fault while using Tkinter

Initial Comment:
While using Tkinter I encountere segmentation faults
regularly. I ran my program using gdb using python2.4
and Fedora Core 5 and received:

(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread -1209063760 (LWP 2024)]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[New Thread -1212232800 (LWP 2027)]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
---Type <return> to continue, or q <return> to quit---
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1209063760 (LWP 2024)]
0x001519ce in TkUndoSetDepth () from /usr/lib/libtk8.4.so
(gdb) 


I ran the same program using python2.5a2 and again
received:

Starting program: /usr/local/bin/python
~/temp/rope/rope/rope.py
Reading symbols from shared object read from target
memory...done.
Loaded system supplied DSO at 0xa05000
[Thread debugging using libthread_db enabled]
[New Thread -1208899920 (LWP 2415)]
[New Thread -1212068960 (LWP 2418)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1208899920 (LWP 2415)]
0x001519ce in TkUndoSetDepth () from /usr/lib/libtk8.4.so
(gdb)


Are these information enough for fixing the problem or
should I send my program?

Thanks


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-05-01 00:25

Message:
Logged In: YES 
user_id=33168

If you can send a small test case that would be great. 
Also, can you attach the backtrace (bt command in gdb)?

How did you configure python?  Did you use an
--enable-unicode or --enable-threads?  Did you built Tcl/Tk
or are you using the default version with FC5?

When python starts up, what do you see?  It should be
something like:

Python 2.5a2 (trunk:45831M, Apr 30 2006, 23:27:02) 
[GCC 4.0.0 20041026 (Apple Computer, Inc. build 4061)] on darwin


Also, what does this print:  
    import sys ; print sys.maxunicode

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-30 23:34

Message:
Logged In: YES 
user_id=21627

Please do send your program, or better yet a small test case
that allows to reproduce the problem. It looks like a Tk bug
at first glance, in TkUndoSetDepth.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1479586&group_id=5470

From noreply at sourceforge.net  Mon May  1 09:48:07 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 01 May 2006 00:48:07 -0700
Subject: [ python-Bugs-1479626 ] Uninstall does not clearn registry
Message-ID: <E1FaT8Z-0006DT-Tu@sc8-sf-web3.sourceforge.net>

Bugs item #1479626, was opened at 2006-05-01 10:48
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=1479626&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: Installation
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Miki Tebeka (tebeka)
Assigned to: Nobody/Anonymous (nobody)
Summary: Uninstall does not clearn registry

Initial Comment:
After uninstalling Python2.5a2 (winXP) the registry key
/HKLM/Software/Python/PythonCore/2.5 is left in the
registry.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1479626&group_id=5470

From noreply at sourceforge.net  Mon May  1 16:37:31 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 01 May 2006 07:37:31 -0700
Subject: [ python-Bugs-1479776 ] float->str rounding bug
Message-ID: <E1FaZWl-00066x-DZ@sc8-sf-web4-b.sourceforge.net>

Bugs item #1479776, was opened at 2006-05-01 10:37
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1479776&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: Michael Nolta (mrnolta)
Assigned to: Nobody/Anonymous (nobody)
Summary: float->str rounding bug

Initial Comment:
Hi,

Here's my problem:

  >>> print "%.2f" % 2.195
  2.19

The output should be "2.20".

It's sensitive to whether the value is greater than 1.
For example, this works:

  >>> print "%.4f" % 2.195e-2
  0.0220

Here's my full version info:

  Python 2.4.1 (#1, May 16 2005, 15:19:29)
  [GCC 4.0.0 20050512 (Red Hat 4.0.0-5)] on linux2

-Mike

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1479776&group_id=5470

From noreply at sourceforge.net  Mon May  1 17:01:41 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 01 May 2006 08:01:41 -0700
Subject: [ python-Bugs-1479785 ] Quitter object masked
Message-ID: <E1FaZu9-0001CC-JQ@sc8-sf-web2.sourceforge.net>

Bugs item #1479785, was opened at 2006-05-01 11:01
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=1479785&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Jim Jewett (jimjjewett)
Assigned to: Nobody/Anonymous (nobody)
Summary: Quitter object masked

Initial Comment:
2.5 introduces a Quitter object (defined in site.py) 
to make the quit/exit message more friendly.

Lines 480-482 of PyShell.py override this, so that 
users of Idle never see the improved feature.

Unfortunately, simply removing those lines isn't quite 
enough to solve the problem, as IDLE catches 
SystemExit exceptions.  Getting around that, I didn't 
have time to track down yet.




----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1479785&group_id=5470

From noreply at sourceforge.net  Mon May  1 17:54:47 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 01 May 2006 08:54:47 -0700
Subject: [ python-Bugs-1479776 ] float->str rounding bug
Message-ID: <E1FaajX-0000hr-R4@sc8-sf-web5.sourceforge.net>

Bugs item #1479776, was opened at 2006-05-01 10:37
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1479776&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: Not a Bug
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Michael Nolta (mrnolta)
Assigned to: Nobody/Anonymous (nobody)
Summary: float->str rounding bug

Initial Comment:
Hi,

Here's my problem:

  >>> print "%.2f" % 2.195
  2.19

The output should be "2.20".

It's sensitive to whether the value is greater than 1.
For example, this works:

  >>> print "%.4f" % 2.195e-2
  0.0220

Here's my full version info:

  Python 2.4.1 (#1, May 16 2005, 15:19:29)
  [GCC 4.0.0 20050512 (Red Hat 4.0.0-5)] on linux2

-Mike

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2006-05-01 11:54

Message:
Logged In: YES 
user_id=31435

This isn't a bug.  You should read the Python Tutorial's
Appendix on floating-point issues.  As you can see from

>>> 2.195
2.1949999999999998

the closest representable float is actually a little bit
smaller than the decimal 2.195, so there's no reason for it
to "round up".  Try the same thing in C (or any other
language exposing your hardware's binary floating point),
and you should see the same result.

If you need exact decimal values, use Python's "decimal"
module instead.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1479776&group_id=5470

From noreply at sourceforge.net  Mon May  1 22:20:07 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 01 May 2006 13:20:07 -0700
Subject: [ python-Feature Requests-735515 ] urllib / urllib2 should cache 301
	redirections
Message-ID: <E1FaesJ-0004Bm-0I@sc8-sf-web1.sourceforge.net>

Feature Requests item #735515, was opened at 2003-05-10 00:21
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=735515&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: John J Lee (jjlee)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib / urllib2 should cache 301 redirections

Initial Comment:
urllib / urllib2 should cache the results of 301 
(permanent) redirections.  This shouldn't break 
anything, since it's just an internal optimisation 
from one point of view -- but it's also what the 
RFC (2616, section 10.3.2, first para) says 
SHOULD happen. 
 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=735515&group_id=5470

From noreply at sourceforge.net  Mon May  1 22:25:24 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 01 May 2006 13:25:24 -0700
Subject: [ python-Bugs-1471407 ] setup.py --help-commands exception
Message-ID: <E1FaexQ-0008C5-8f@sc8-sf-web4-b.sourceforge.net>

Bugs item #1471407, was opened at 2006-04-16 19:23
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1471407&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Distutils
Group: Python 2.5
>Status: Pending
Resolution: None
Priority: 5
Submitted By: James William Pye (jwpye)
Assigned to: Nobody/Anonymous (nobody)
Summary: setup.py --help-commands exception

Initial Comment:
>From a recent trunk build(2.5a1) on FreeBSD 6.1:

jwp at lit:/src/org/pgfoundry/python/fe/local %
/usr/dev/bin/python ./setup.py --help-commands
Standard commands:
  build            build everything needed to install
  build_py         "build" pure Python modules (copy to
build directory)
  build_ext        build C/C++ extensions (compile/link
to build directory)
  build_clib       build C/C++ libraries used by Python
extensions
  build_scripts    "build" scripts (copy and fixup #! line)
  clean            clean up temporary files from
'build' command
  install          install everything from build directory
  install_lib      install all Python modules
(extensions and pure Python)
  install_headers  install C/C++ header files
  install_scripts  install scripts (Python or otherwise)
  install_data     install data files
  sdist            create a source distribution
(tarball, zip file, etc.)
Traceback (most recent call last):
  File "./setup.py", line 52, in <module>
    setup(defaults)
  File "./setup.py", line 46, in setup
    d = distutils.core.setup(**kw)
  File "/usr/dev/lib/python2.5/distutils/core.py", line
137, in setup
    ok = dist.parse_command_line()
  File "/usr/dev/lib/python2.5/distutils/dist.py", line
455, in parse_command_line
    if self.handle_display_options(option_order):
  File "/usr/dev/lib/python2.5/distutils/dist.py", line
680, in handle_display_options
    self.print_commands()
  File "/usr/dev/lib/python2.5/distutils/dist.py", line
758, in print_commands
    max_length)
  File "/usr/dev/lib/python2.5/distutils/dist.py", line
720, in print_command_list
    klass = self.get_command_class(cmd)
  File "/usr/dev/lib/python2.5/distutils/dist.py", line
851, in get_command_class
    raise DistutilsModuleError("invalid command '%s'" %
command)
distutils.errors.DistutilsModuleError: invalid command
'register'

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-05-01 20:25

Message:
Logged In: YES 
user_id=849994

It looks like the "distutils.command.register" module is not
importable. Can you retry with alpha2 and see if the problem
persists?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1471407&group_id=5470

From noreply at sourceforge.net  Tue May  2 07:25:48 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 01 May 2006 22:25:48 -0700
Subject: [ python-Bugs-1479586 ] Segmentation fault while using Tkinter
Message-ID: <E1FanOO-0000Rm-Mk@sc8-sf-web5.sourceforge.net>

Bugs item #1479586, was opened at 2006-05-01 09:25
Message generated for change (Comment added) made by aligrudi
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1479586&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: Tkinter
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Ali Gholami Rudi (aligrudi)
Assigned to: Martin v. L??wis (loewis)
Summary: Segmentation fault while using Tkinter

Initial Comment:
While using Tkinter I encountere segmentation faults
regularly. I ran my program using gdb using python2.4
and Fedora Core 5 and received:

(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread -1209063760 (LWP 2024)]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[New Thread -1212232800 (LWP 2027)]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
---Type <return> to continue, or q <return> to quit---
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1209063760 (LWP 2024)]
0x001519ce in TkUndoSetDepth () from /usr/lib/libtk8.4.so
(gdb) 


I ran the same program using python2.5a2 and again
received:

Starting program: /usr/local/bin/python
~/temp/rope/rope/rope.py
Reading symbols from shared object read from target
memory...done.
Loaded system supplied DSO at 0xa05000
[Thread debugging using libthread_db enabled]
[New Thread -1208899920 (LWP 2415)]
[New Thread -1212068960 (LWP 2418)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1208899920 (LWP 2415)]
0x001519ce in TkUndoSetDepth () from /usr/lib/libtk8.4.so
(gdb)


Are these information enough for fixing the problem or
should I send my program?

Thanks


----------------------------------------------------------------------

>Comment By: Ali Gholami Rudi (aligrudi)
Date: 2006-05-02 09:55

Message:
Logged In: YES 
user_id=965314

I don't know when the segmentation fault occurs. So I can't
write
a test case to reproduce it. That is when I work with my
program(which
is attached) after a some time(a few minutes or a few hours)
I receive
SIGSEGV.

I did not compile Tcl/Tk. And I used the default
configuration for
compiling Python2.5a2. The 'import sys; print
sys.maxunicode;' prints
65535 in both Python versions I've used.


Python 2.4.2
------------
Python 2.4.2 (#1, Feb 12 2006, 03:59:46) 
[GCC 4.1.0 20060210 (Red Hat 4.1.0-0.24)] on linux2

<<<gdb output start>>>
GNU gdb Red Hat Linux (6.3.0.0-1.122rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public
License, and you are
welcome to change it and/or distribute copies of it under
certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show
warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...(no
debugging symbols found)
Using host libthread_db library "/lib/libthread_db.so.1".

(gdb) run ~/temp/rope/rope/rope.py 
Starting program: /usr/bin/python2.4 ~/temp/rope/rope/rope.py
Reading symbols from shared object read from target
memory...(no debugging symbols found)...done.
Loaded system supplied DSO at 0x8a8000
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread -1208494416 (LWP 2121)]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[New Thread -1211663456 (LWP 2124)]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1208494416 (LWP 2121)]
0x0099e9ce in TkUndoSetDepth () from /usr/lib/libtk8.4.so
(gdb) bt
#0  0x0099e9ce in TkUndoSetDepth () from /usr/lib/libtk8.4.so
#1  0x0099eac9 in TkUndoInsertUndoSeparator () from
/usr/lib/libtk8.4.so
#2  0x009f7208 in TkTextLostSelection () from
/usr/lib/libtk8.4.so
#3  0x0017fc7e in TclInvokeStringCommand () from
/usr/lib/libtcl8.4.so
#4  0x001815e4 in TclEvalObjvInternal () from
/usr/lib/libtcl8.4.so
#5  0x001ae2aa in Tcl_ExprObj () from /usr/lib/libtcl8.4.so
#6  0x001b218c in TclCompEvalObj () from /usr/lib/libtcl8.4.so
#7  0x001df09c in TclObjInterpProc () from /usr/lib/libtcl8.4.so
#8  0x001815e4 in TclEvalObjvInternal () from
/usr/lib/libtcl8.4.so
#9  0x00181b8f in Tcl_EvalEx () from /usr/lib/libtcl8.4.so
#10 0x00181e9c in Tcl_Eval () from /usr/lib/libtcl8.4.so
#11 0x00181f36 in Tcl_GlobalEval () from /usr/lib/libtcl8.4.so
#12 0x0097a9d9 in Tk_BindEvent () from /usr/lib/libtk8.4.so
#13 0x00980414 in TkBindEventProc () from /usr/lib/libtk8.4.so
#14 0x00985cbf in Tk_HandleEvent () from /usr/lib/libtk8.4.so
#15 0x009862db in Tk_HandleEvent () from /usr/lib/libtk8.4.so
#16 0x001d4267 in Tcl_ServiceEvent () from /usr/lib/libtcl8.4.so
#17 0x001d4537 in Tcl_DoOneEvent () from /usr/lib/libtcl8.4.so
#18 0x00114c6c in init_tkinter () from
/usr/lib/python2.4/lib-dynload/_tkinter.so
#19 0x007da92d in PyCFunction_Call () from
/usr/lib/libpython2.4.so.1.0
#20 0x00815646 in PyEval_EvalFrame () from
/usr/lib/libpython2.4.so.1.0
#21 0x008162c6 in PyEval_EvalCodeEx () from
/usr/lib/libpython2.4.so.1.0
#22 0x00814950 in PyEval_EvalFrame () from
/usr/lib/libpython2.4.so.1.0
#23 0x008151d7 in PyEval_EvalFrame () from
/usr/lib/libpython2.4.so.1.0
#24 0x008162c6 in PyEval_EvalCodeEx () from
/usr/lib/libpython2.4.so.1.0
#25 0x00816353 in PyEval_EvalCode () from
/usr/lib/libpython2.4.so.1.0
#26 0x00832f78 in Py_CompileString () from
/usr/lib/libpython2.4.so.1.0
#27 0x00834688 in PyRun_SimpleFileExFlags () from
/usr/lib/libpython2.4.so.1.0
#28 0x00834d6a in PyRun_AnyFileExFlags () from
/usr/lib/libpython2.4.so.1.0
#29 0x0083b45f in Py_Main () from /usr/lib/libpython2.4.so.1.0
#30 0x080485b2 in main ()
(gdb) 
<<<gdb output end>>>



Python 2.5a2
------------
Python 2.5a2 (r25a2:45740, Apr 29 2006, 18:39:09) 
[GCC 4.1.0 20060304 (Red Hat 4.1.0-3)] on linux2

<<<gdb output start>>>
GNU gdb Red Hat Linux (6.3.0.0-1.122rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public
License, and you are
welcome to change it and/or distribute copies of it under
certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show
warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...Using
host libthread_db library "/lib/libthread_db.so.1".

(gdb) run ~/temp/rope/rope/rope.py 
Starting program: /usr/local/bin/python ~/temp/rope/rope/rope.py
Reading symbols from shared object read from target
memory...done.
Loaded system supplied DSO at 0x4c6000
[Thread debugging using libthread_db enabled]
[New Thread -1208731984 (LWP 2176)]
[New Thread -1211835488 (LWP 2179)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1208731984 (LWP 2176)]
0x0099e9ce in TkUndoSetDepth () from /usr/lib/libtk8.4.so
(gdb) bt
#0  0x0099e9ce in TkUndoSetDepth () from /usr/lib/libtk8.4.so
#1  0x0099eac9 in TkUndoInsertUndoSeparator () from
/usr/lib/libtk8.4.so
#2  0x009f75e7 in TkTextLostSelection () from
/usr/lib/libtk8.4.so
#3  0x0013bc7e in TclInvokeStringCommand () from
/usr/lib/libtcl8.4.so
#4  0x0013d5e4 in TclEvalObjvInternal () from
/usr/lib/libtcl8.4.so
#5  0x0013e59b in Tcl_EvalObjv () from /usr/lib/libtcl8.4.so
#6  0x00118606 in Tkapp_Call (_self=0xb71d4640, args=0xb72337d4)
    at /dev/shm/Python-2.5a2/Modules/_tkinter.c:1324
#7  0x080bc0b2 in PyEval_EvalFrameEx (f=0x89c4a0c,
throwflag=0) at Python/ceval.c:3534
#8  0x080bd807 in PyEval_EvalCodeEx (co=0xb7c627e0,
globals=0xb7ed39bc, locals=0x0, 
    args=0x89c48ac, argcount=2, kws=0x89c48b4, kwcount=0,
defs=0x0, defcount=0, closure=0x0)
    at Python/ceval.c:2809
#9  0x080bb884 in PyEval_EvalFrameEx (f=0x89c475c,
throwflag=0) at Python/ceval.c:3630
#10 0x080bcac5 in PyEval_EvalFrameEx (f=0x8a41fd4,
throwflag=0) at Python/ceval.c:3619
#11 0x080bcac5 in PyEval_EvalFrameEx (f=0x87c931c,
throwflag=0) at Python/ceval.c:3619
#12 0x080bcac5 in PyEval_EvalFrameEx (f=0x87b1ee4,
throwflag=0) at Python/ceval.c:3619
#13 0x080bcac5 in PyEval_EvalFrameEx (f=0x89a0a24,
throwflag=0) at Python/ceval.c:3619
#14 0x080bd807 in PyEval_EvalCodeEx (co=0xb7ecff60,
globals=0xb7ed38ac, locals=0x0, 
    args=0xb71e4258, argcount=1, kws=0x0, kwcount=0,
defs=0x0, defcount=0, closure=0xb71e2f8c)
    at Python/ceval.c:2809
#15 0x081044f1 in function_call (func=0xb71a8374,
arg=0xb71e424c, kw=0x0)
    at Objects/funcobject.c:517
#16 0x08059c77 in PyObject_Call (func=0xb71a8374,
arg=0xb71e424c, kw=0x0)
    at Objects/abstract.c:1792
#17 0x080ba663 in PyEval_EvalFrameEx (f=0x87e732c,
throwflag=0) at Python/ceval.c:3814
#18 0x080bd807 in PyEval_EvalCodeEx (co=0xb7ef90a0,
globals=0xb7ed39bc, locals=0x0, 
    args=0xb723e310, argcount=20, kws=0x0, kwcount=0,
defs=0x0, defcount=0, closure=0x0)
    at Python/ceval.c:2809
#19 0x081044f1 in function_call (func=0xb7c76b54,
arg=0xb723e304, kw=0x0)
    at Objects/funcobject.c:517
#20 0x08059c77 in PyObject_Call (func=0xb7c76b54,
arg=0xb723e304, kw=0x0)
    at Objects/abstract.c:1792
#21 0x0805f847 in instancemethod_call (func=0xb71a78ec,
arg=0xb723e304, kw=0x0)
    at Objects/classobject.c:2421
#22 0x08059c77 in PyObject_Call (func=0xb71a78ec,
arg=0xb7f0a9ec, kw=0x0)
    at Objects/abstract.c:1792
#23 0x080b5aac in PyEval_CallObjectWithKeywords
(func=0xb71a78ec, arg=0xb7f0a9ec, kw=0x0)
---Type <return> to continue, or q <return> to quit---
    at Python/ceval.c:3403
#24 0x001171b2 in PythonCmd (clientData=0x8b84960,
interp=0x87a2080, argc=20, argv=0x8cf1f78)
    at /dev/shm/Python-2.5a2/Modules/_tkinter.c:2011
#25 0x0013bc7e in TclInvokeStringCommand () from
/usr/lib/libtcl8.4.so
#26 0x0013d5e4 in TclEvalObjvInternal () from
/usr/lib/libtcl8.4.so
#27 0x0016a2aa in Tcl_ExprObj () from /usr/lib/libtcl8.4.so
#28 0x001674cd in Tcl_ExprObj () from /usr/lib/libtcl8.4.so
#29 0x0013ce63 in Tcl_ExprBooleanObj () from
/usr/lib/libtcl8.4.so
#30 0x0014b072 in Tcl_IfObjCmd () from /usr/lib/libtcl8.4.so
#31 0x0013d5e4 in TclEvalObjvInternal () from
/usr/lib/libtcl8.4.so
#32 0x0013db8f in Tcl_EvalEx () from /usr/lib/libtcl8.4.so
#33 0x0013de9c in Tcl_Eval () from /usr/lib/libtcl8.4.so
#34 0x0013df36 in Tcl_GlobalEval () from /usr/lib/libtcl8.4.so
#35 0x0097a9d9 in Tk_BindEvent () from /usr/lib/libtk8.4.so
#36 0x00980414 in TkBindEventProc () from /usr/lib/libtk8.4.so
#37 0x00985cbf in Tk_HandleEvent () from /usr/lib/libtk8.4.so
#38 0x009862db in Tk_HandleEvent () from /usr/lib/libtk8.4.so
#39 0x00190267 in Tcl_ServiceEvent () from /usr/lib/libtcl8.4.so
#40 0x00190537 in Tcl_DoOneEvent () from /usr/lib/libtcl8.4.so
#41 0x00116eca in Tkapp_MainLoop (_self=0xb71d4640,
args=0xb7ed690c)
    at /dev/shm/Python-2.5a2/Modules/_tkinter.c:2542
#42 0x080bc0b2 in PyEval_EvalFrameEx (f=0x8752afc,
throwflag=0) at Python/ceval.c:3534
#43 0x080bd807 in PyEval_EvalCodeEx (co=0xb7ef1520,
globals=0xb7ed39bc, locals=0x0, 
    args=0x8741154, argcount=1, kws=0x8741158, kwcount=0,
defs=0xb7c74df8, defcount=1, closure=0x0)
    at Python/ceval.c:2809
#44 0x080bb884 in PyEval_EvalFrameEx (f=0x8741004,
throwflag=0) at Python/ceval.c:3630
#45 0x080bcac5 in PyEval_EvalFrameEx (f=0x873d0c4,
throwflag=0) at Python/ceval.c:3619
#46 0x080bd807 in PyEval_EvalCodeEx (co=0xb7ecbba0,
globals=0xb7f20934, locals=0xb7f20934, 
    args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0,
defcount=0, closure=0x0)
    at Python/ceval.c:2809
#47 0x080bd877 in PyEval_EvalCode (co=0xb7ecbba0,
globals=0xb7f20934, locals=0xb7f20934)
    at Python/ceval.c:491
#48 0x080dbc2e in PyRun_FileExFlags (fp=0x870b008, 
    filename=0xbfa51aae "/home/ali/temp/rope/rope/rope.py",
start=257, globals=0xb7f20934, 
    locals=0xb7f20934, closeit=1, flags=0xbfa51538) at
Python/pythonrun.c:1224
#49 0x080dbed7 in PyRun_SimpleFileExFlags (fp=0x870b008, 
    filename=0xbfa51aae "/home/ali/temp/rope/rope/rope.py",
closeit=1, flags=0xbfa51538)
---Type <return> to continue, or q <return> to quit---
    at Python/pythonrun.c:854
#50 0x08056934 in Py_Main (argc=1, argv=0xbfa51604) at
Modules/main.c:492
#51 0x08055f02 in main (argc=Cannot access memory at address
0x13
) at ./Modules/python.c:23
(gdb) 
<<<gdb output end>>>


The attached program, using which I encounter the above
problem, is 
rope<http://sf.net/project/rope/>. The editor is in
'rope/editor.py' module.


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-05-01 11:55

Message:
Logged In: YES 
user_id=33168

If you can send a small test case that would be great. 
Also, can you attach the backtrace (bt command in gdb)?

How did you configure python?  Did you use an
--enable-unicode or --enable-threads?  Did you built Tcl/Tk
or are you using the default version with FC5?

When python starts up, what do you see?  It should be
something like:

Python 2.5a2 (trunk:45831M, Apr 30 2006, 23:27:02) 
[GCC 4.0.0 20041026 (Apple Computer, Inc. build 4061)] on darwin


Also, what does this print:  
    import sys ; print sys.maxunicode

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-05-01 11:04

Message:
Logged In: YES 
user_id=21627

Please do send your program, or better yet a small test case
that allows to reproduce the problem. It looks like a Tk bug
at first glance, in TkUndoSetDepth.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1479586&group_id=5470

From noreply at sourceforge.net  Tue May  2 08:27:25 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 01 May 2006 23:27:25 -0700
Subject: [ python-Bugs-1479586 ] Segmentation fault while using Tkinter
Message-ID: <E1FaoM1-0007f7-6C@sc8-sf-web5.sourceforge.net>

Bugs item #1479586, was opened at 2006-05-01 06:55
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1479586&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: Tkinter
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Ali Gholami Rudi (aligrudi)
Assigned to: Martin v. L??wis (loewis)
Summary: Segmentation fault while using Tkinter

Initial Comment:
While using Tkinter I encountere segmentation faults
regularly. I ran my program using gdb using python2.4
and Fedora Core 5 and received:

(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread -1209063760 (LWP 2024)]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[New Thread -1212232800 (LWP 2027)]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
---Type <return> to continue, or q <return> to quit---
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1209063760 (LWP 2024)]
0x001519ce in TkUndoSetDepth () from /usr/lib/libtk8.4.so
(gdb) 


I ran the same program using python2.5a2 and again
received:

Starting program: /usr/local/bin/python
~/temp/rope/rope/rope.py
Reading symbols from shared object read from target
memory...done.
Loaded system supplied DSO at 0xa05000
[Thread debugging using libthread_db enabled]
[New Thread -1208899920 (LWP 2415)]
[New Thread -1212068960 (LWP 2418)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1208899920 (LWP 2415)]
0x001519ce in TkUndoSetDepth () from /usr/lib/libtk8.4.so
(gdb)


Are these information enough for fixing the problem or
should I send my program?

Thanks


----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-05-02 08:27

Message:
Logged In: YES 
user_id=21627

Apparently, this has something to do with the undo mechanism
of the text widget; I would expect the problem to go away if
you disable undo (text["undo"]=0). Other than that, there is
not much I can tell, from either looking at the source or at
the backtrace.

Most likely, it is some bug in Tcl/Tk. It also could be that
Python is corrupting memory somehow, and that this causes Tk
to crash.

If you want to debug this yourself, compile Tcl/Tk (with,
say, --prefix==/var/tmp). Use --disable-shared
--enable-symbols for both Tcl and Tk, then edit
Modules/Setup to statically link _tkinter into the Python
interpreter. Replace the -ltk8.2 line with an explict
/var/tmp/lib/libtk8.4g.a, to be sure that your version of tk
is used.

Then run it in a debugger, and find out why it crashes. Is
it really crashing inside TkUndoSetDepth? If so, what is the
value of stack? What is the value of maxdepth? What is the
Tcl command being executed (if Tcl_Eval is on the stack, go
up several times, and print the value of its string argument).

----------------------------------------------------------------------

Comment By: Ali Gholami Rudi (aligrudi)
Date: 2006-05-02 07:25

Message:
Logged In: YES 
user_id=965314

I don't know when the segmentation fault occurs. So I can't
write
a test case to reproduce it. That is when I work with my
program(which
is attached) after a some time(a few minutes or a few hours)
I receive
SIGSEGV.

I did not compile Tcl/Tk. And I used the default
configuration for
compiling Python2.5a2. The 'import sys; print
sys.maxunicode;' prints
65535 in both Python versions I've used.


Python 2.4.2
------------
Python 2.4.2 (#1, Feb 12 2006, 03:59:46) 
[GCC 4.1.0 20060210 (Red Hat 4.1.0-0.24)] on linux2

<<<gdb output start>>>
GNU gdb Red Hat Linux (6.3.0.0-1.122rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public
License, and you are
welcome to change it and/or distribute copies of it under
certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show
warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...(no
debugging symbols found)
Using host libthread_db library "/lib/libthread_db.so.1".

(gdb) run ~/temp/rope/rope/rope.py 
Starting program: /usr/bin/python2.4 ~/temp/rope/rope/rope.py
Reading symbols from shared object read from target
memory...(no debugging symbols found)...done.
Loaded system supplied DSO at 0x8a8000
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread -1208494416 (LWP 2121)]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[New Thread -1211663456 (LWP 2124)]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1208494416 (LWP 2121)]
0x0099e9ce in TkUndoSetDepth () from /usr/lib/libtk8.4.so
(gdb) bt
#0  0x0099e9ce in TkUndoSetDepth () from /usr/lib/libtk8.4.so
#1  0x0099eac9 in TkUndoInsertUndoSeparator () from
/usr/lib/libtk8.4.so
#2  0x009f7208 in TkTextLostSelection () from
/usr/lib/libtk8.4.so
#3  0x0017fc7e in TclInvokeStringCommand () from
/usr/lib/libtcl8.4.so
#4  0x001815e4 in TclEvalObjvInternal () from
/usr/lib/libtcl8.4.so
#5  0x001ae2aa in Tcl_ExprObj () from /usr/lib/libtcl8.4.so
#6  0x001b218c in TclCompEvalObj () from /usr/lib/libtcl8.4.so
#7  0x001df09c in TclObjInterpProc () from /usr/lib/libtcl8.4.so
#8  0x001815e4 in TclEvalObjvInternal () from
/usr/lib/libtcl8.4.so
#9  0x00181b8f in Tcl_EvalEx () from /usr/lib/libtcl8.4.so
#10 0x00181e9c in Tcl_Eval () from /usr/lib/libtcl8.4.so
#11 0x00181f36 in Tcl_GlobalEval () from /usr/lib/libtcl8.4.so
#12 0x0097a9d9 in Tk_BindEvent () from /usr/lib/libtk8.4.so
#13 0x00980414 in TkBindEventProc () from /usr/lib/libtk8.4.so
#14 0x00985cbf in Tk_HandleEvent () from /usr/lib/libtk8.4.so
#15 0x009862db in Tk_HandleEvent () from /usr/lib/libtk8.4.so
#16 0x001d4267 in Tcl_ServiceEvent () from /usr/lib/libtcl8.4.so
#17 0x001d4537 in Tcl_DoOneEvent () from /usr/lib/libtcl8.4.so
#18 0x00114c6c in init_tkinter () from
/usr/lib/python2.4/lib-dynload/_tkinter.so
#19 0x007da92d in PyCFunction_Call () from
/usr/lib/libpython2.4.so.1.0
#20 0x00815646 in PyEval_EvalFrame () from
/usr/lib/libpython2.4.so.1.0
#21 0x008162c6 in PyEval_EvalCodeEx () from
/usr/lib/libpython2.4.so.1.0
#22 0x00814950 in PyEval_EvalFrame () from
/usr/lib/libpython2.4.so.1.0
#23 0x008151d7 in PyEval_EvalFrame () from
/usr/lib/libpython2.4.so.1.0
#24 0x008162c6 in PyEval_EvalCodeEx () from
/usr/lib/libpython2.4.so.1.0
#25 0x00816353 in PyEval_EvalCode () from
/usr/lib/libpython2.4.so.1.0
#26 0x00832f78 in Py_CompileString () from
/usr/lib/libpython2.4.so.1.0
#27 0x00834688 in PyRun_SimpleFileExFlags () from
/usr/lib/libpython2.4.so.1.0
#28 0x00834d6a in PyRun_AnyFileExFlags () from
/usr/lib/libpython2.4.so.1.0
#29 0x0083b45f in Py_Main () from /usr/lib/libpython2.4.so.1.0
#30 0x080485b2 in main ()
(gdb) 
<<<gdb output end>>>



Python 2.5a2
------------
Python 2.5a2 (r25a2:45740, Apr 29 2006, 18:39:09) 
[GCC 4.1.0 20060304 (Red Hat 4.1.0-3)] on linux2

<<<gdb output start>>>
GNU gdb Red Hat Linux (6.3.0.0-1.122rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public
License, and you are
welcome to change it and/or distribute copies of it under
certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show
warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...Using
host libthread_db library "/lib/libthread_db.so.1".

(gdb) run ~/temp/rope/rope/rope.py 
Starting program: /usr/local/bin/python ~/temp/rope/rope/rope.py
Reading symbols from shared object read from target
memory...done.
Loaded system supplied DSO at 0x4c6000
[Thread debugging using libthread_db enabled]
[New Thread -1208731984 (LWP 2176)]
[New Thread -1211835488 (LWP 2179)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1208731984 (LWP 2176)]
0x0099e9ce in TkUndoSetDepth () from /usr/lib/libtk8.4.so
(gdb) bt
#0  0x0099e9ce in TkUndoSetDepth () from /usr/lib/libtk8.4.so
#1  0x0099eac9 in TkUndoInsertUndoSeparator () from
/usr/lib/libtk8.4.so
#2  0x009f75e7 in TkTextLostSelection () from
/usr/lib/libtk8.4.so
#3  0x0013bc7e in TclInvokeStringCommand () from
/usr/lib/libtcl8.4.so
#4  0x0013d5e4 in TclEvalObjvInternal () from
/usr/lib/libtcl8.4.so
#5  0x0013e59b in Tcl_EvalObjv () from /usr/lib/libtcl8.4.so
#6  0x00118606 in Tkapp_Call (_self=0xb71d4640, args=0xb72337d4)
    at /dev/shm/Python-2.5a2/Modules/_tkinter.c:1324
#7  0x080bc0b2 in PyEval_EvalFrameEx (f=0x89c4a0c,
throwflag=0) at Python/ceval.c:3534
#8  0x080bd807 in PyEval_EvalCodeEx (co=0xb7c627e0,
globals=0xb7ed39bc, locals=0x0, 
    args=0x89c48ac, argcount=2, kws=0x89c48b4, kwcount=0,
defs=0x0, defcount=0, closure=0x0)
    at Python/ceval.c:2809
#9  0x080bb884 in PyEval_EvalFrameEx (f=0x89c475c,
throwflag=0) at Python/ceval.c:3630
#10 0x080bcac5 in PyEval_EvalFrameEx (f=0x8a41fd4,
throwflag=0) at Python/ceval.c:3619
#11 0x080bcac5 in PyEval_EvalFrameEx (f=0x87c931c,
throwflag=0) at Python/ceval.c:3619
#12 0x080bcac5 in PyEval_EvalFrameEx (f=0x87b1ee4,
throwflag=0) at Python/ceval.c:3619
#13 0x080bcac5 in PyEval_EvalFrameEx (f=0x89a0a24,
throwflag=0) at Python/ceval.c:3619
#14 0x080bd807 in PyEval_EvalCodeEx (co=0xb7ecff60,
globals=0xb7ed38ac, locals=0x0, 
    args=0xb71e4258, argcount=1, kws=0x0, kwcount=0,
defs=0x0, defcount=0, closure=0xb71e2f8c)
    at Python/ceval.c:2809
#15 0x081044f1 in function_call (func=0xb71a8374,
arg=0xb71e424c, kw=0x0)
    at Objects/funcobject.c:517
#16 0x08059c77 in PyObject_Call (func=0xb71a8374,
arg=0xb71e424c, kw=0x0)
    at Objects/abstract.c:1792
#17 0x080ba663 in PyEval_EvalFrameEx (f=0x87e732c,
throwflag=0) at Python/ceval.c:3814
#18 0x080bd807 in PyEval_EvalCodeEx (co=0xb7ef90a0,
globals=0xb7ed39bc, locals=0x0, 
    args=0xb723e310, argcount=20, kws=0x0, kwcount=0,
defs=0x0, defcount=0, closure=0x0)
    at Python/ceval.c:2809
#19 0x081044f1 in function_call (func=0xb7c76b54,
arg=0xb723e304, kw=0x0)
    at Objects/funcobject.c:517
#20 0x08059c77 in PyObject_Call (func=0xb7c76b54,
arg=0xb723e304, kw=0x0)
    at Objects/abstract.c:1792
#21 0x0805f847 in instancemethod_call (func=0xb71a78ec,
arg=0xb723e304, kw=0x0)
    at Objects/classobject.c:2421
#22 0x08059c77 in PyObject_Call (func=0xb71a78ec,
arg=0xb7f0a9ec, kw=0x0)
    at Objects/abstract.c:1792
#23 0x080b5aac in PyEval_CallObjectWithKeywords
(func=0xb71a78ec, arg=0xb7f0a9ec, kw=0x0)
---Type <return> to continue, or q <return> to quit---
    at Python/ceval.c:3403
#24 0x001171b2 in PythonCmd (clientData=0x8b84960,
interp=0x87a2080, argc=20, argv=0x8cf1f78)
    at /dev/shm/Python-2.5a2/Modules/_tkinter.c:2011
#25 0x0013bc7e in TclInvokeStringCommand () from
/usr/lib/libtcl8.4.so
#26 0x0013d5e4 in TclEvalObjvInternal () from
/usr/lib/libtcl8.4.so
#27 0x0016a2aa in Tcl_ExprObj () from /usr/lib/libtcl8.4.so
#28 0x001674cd in Tcl_ExprObj () from /usr/lib/libtcl8.4.so
#29 0x0013ce63 in Tcl_ExprBooleanObj () from
/usr/lib/libtcl8.4.so
#30 0x0014b072 in Tcl_IfObjCmd () from /usr/lib/libtcl8.4.so
#31 0x0013d5e4 in TclEvalObjvInternal () from
/usr/lib/libtcl8.4.so
#32 0x0013db8f in Tcl_EvalEx () from /usr/lib/libtcl8.4.so
#33 0x0013de9c in Tcl_Eval () from /usr/lib/libtcl8.4.so
#34 0x0013df36 in Tcl_GlobalEval () from /usr/lib/libtcl8.4.so
#35 0x0097a9d9 in Tk_BindEvent () from /usr/lib/libtk8.4.so
#36 0x00980414 in TkBindEventProc () from /usr/lib/libtk8.4.so
#37 0x00985cbf in Tk_HandleEvent () from /usr/lib/libtk8.4.so
#38 0x009862db in Tk_HandleEvent () from /usr/lib/libtk8.4.so
#39 0x00190267 in Tcl_ServiceEvent () from /usr/lib/libtcl8.4.so
#40 0x00190537 in Tcl_DoOneEvent () from /usr/lib/libtcl8.4.so
#41 0x00116eca in Tkapp_MainLoop (_self=0xb71d4640,
args=0xb7ed690c)
    at /dev/shm/Python-2.5a2/Modules/_tkinter.c:2542
#42 0x080bc0b2 in PyEval_EvalFrameEx (f=0x8752afc,
throwflag=0) at Python/ceval.c:3534
#43 0x080bd807 in PyEval_EvalCodeEx (co=0xb7ef1520,
globals=0xb7ed39bc, locals=0x0, 
    args=0x8741154, argcount=1, kws=0x8741158, kwcount=0,
defs=0xb7c74df8, defcount=1, closure=0x0)
    at Python/ceval.c:2809
#44 0x080bb884 in PyEval_EvalFrameEx (f=0x8741004,
throwflag=0) at Python/ceval.c:3630
#45 0x080bcac5 in PyEval_EvalFrameEx (f=0x873d0c4,
throwflag=0) at Python/ceval.c:3619
#46 0x080bd807 in PyEval_EvalCodeEx (co=0xb7ecbba0,
globals=0xb7f20934, locals=0xb7f20934, 
    args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0,
defcount=0, closure=0x0)
    at Python/ceval.c:2809
#47 0x080bd877 in PyEval_EvalCode (co=0xb7ecbba0,
globals=0xb7f20934, locals=0xb7f20934)
    at Python/ceval.c:491
#48 0x080dbc2e in PyRun_FileExFlags (fp=0x870b008, 
    filename=0xbfa51aae "/home/ali/temp/rope/rope/rope.py",
start=257, globals=0xb7f20934, 
    locals=0xb7f20934, closeit=1, flags=0xbfa51538) at
Python/pythonrun.c:1224
#49 0x080dbed7 in PyRun_SimpleFileExFlags (fp=0x870b008, 
    filename=0xbfa51aae "/home/ali/temp/rope/rope/rope.py",
closeit=1, flags=0xbfa51538)
---Type <return> to continue, or q <return> to quit---
    at Python/pythonrun.c:854
#50 0x08056934 in Py_Main (argc=1, argv=0xbfa51604) at
Modules/main.c:492
#51 0x08055f02 in main (argc=Cannot access memory at address
0x13
) at ./Modules/python.c:23
(gdb) 
<<<gdb output end>>>


The attached program, using which I encounter the above
problem, is 
rope<http://sf.net/project/rope/>. The editor is in
'rope/editor.py' module.


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-05-01 09:25

Message:
Logged In: YES 
user_id=33168

If you can send a small test case that would be great. 
Also, can you attach the backtrace (bt command in gdb)?

How did you configure python?  Did you use an
--enable-unicode or --enable-threads?  Did you built Tcl/Tk
or are you using the default version with FC5?

When python starts up, what do you see?  It should be
something like:

Python 2.5a2 (trunk:45831M, Apr 30 2006, 23:27:02) 
[GCC 4.0.0 20041026 (Apple Computer, Inc. build 4061)] on darwin


Also, what does this print:  
    import sys ; print sys.maxunicode

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-05-01 08:34

Message:
Logged In: YES 
user_id=21627

Please do send your program, or better yet a small test case
that allows to reproduce the problem. It looks like a Tk bug
at first glance, in TkUndoSetDepth.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1479586&group_id=5470

From noreply at sourceforge.net  Tue May  2 11:11:10 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 02 May 2006 02:11:10 -0700
Subject: [ python-Feature Requests-1474577 ] feature requests for logging lib
Message-ID: <E1FaquU-0002NM-Fa@sc8-sf-web2.sourceforge.net>

Feature Requests item #1474577, was opened at 2006-04-22 09:50
Message generated for change (Comment added) made by vsajip
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1474577&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: blaize rhodes (blaize)
Assigned to: Nobody/Anonymous (nobody)
Summary: feature requests for logging lib

Initial Comment:


The logger module interface is a bit broken, I reckon.
 My problems specifically are:
 
	i) It's hard to get access to the LogRecord classes
for customization.
	ii) the semantics of the debug, log, info, etc calls
is a bit strange/confusing...



Here are my proposed fixes:

a)  Add a method 
   Logger.setLogRecordClass( myLogRecordSubClass )

which sets the class that is instantiated in the
makeRecord() fn/method (yes there are two of them).

This would make customizing the LogRecord easier... 
Otherwise (I believe) in order to subclass the
LogRecord you also have to overload the Logger and
possibly the root makeRecord() function as well?  This
bloke's writen up his approach to this (it's doable but
not as nice as it should be).
 
http://qix.it/~ludoo/archive/2004/05/python_logging_customization.html

Another problem is that LogRecords are instantiated in
Logger._log so it's difficult to customize __init__
behaviour for the LogRecord (and I argue that this is a
useful thing)..  

b) A second problem is that the semantics of the log,
info, debug, etc fns is a bit broken.  Currently the
defn looks like this:

  def debug(self, msg, *args, **kwargs):

this suggests to me that a call like this is OK...

  logger.debug("here we go %(foo)s", foo = 'bar')

but it's not.  This is discussed further here...

http://groups.google.com.au/group/comp.lang.python/browse_thread/thread/322919fcac0113ec/98ceaf6fc0c56881?lnk=st&q=python+logging+keywords&rnum=1#98ceaf6fc0c56881

Instead kwargs are used for customizing the behaviour
of the debug method (e.g. exc_info, and extra).  This
seems i) a bit incongrous with its definition and
therefore confusing, and ii) a bit of a hack (it's not
completely insane though when you think about what's
happening under the hood).  Instead I propose using a
couple of calls along the lines of printf/fprintf.  In
my world we'd have a simple printf-style function... 

  def debug(self, msg, *args):  

and a more complex, more easily customizable
fprintf-style one

  def x_debug(self, log_record, msg, *args):  

In these calls *args is a valid argument for the string
formatting operator %, either a tuple of the right
length or a dictionary.  Any customization of the
behaviour of the system can be done (using keyword args
if you wish) in the log_record initializer (an example
will follow).

(Having said that perhaps we can check whether the
first arg to the new simple debug() is a logrecord and
if it is call the (hidden) extended version - that's
more pythonic I imagine)


c) This is not so much a feature request but a
motivating mode of operation that I'd like to be able
to use...

Currently you can set up log filters.  What you can
filter is largely based on what information appears in
the log record.  It'd be nice to filter messages based
on metadata  that you add at log time (i.e. in the
logger.debug(...) method).  Currently it's quite
painfull to set this up.  This is because we can't
customize the initialization of the log_record.  The
call structure in ii) above allows us to setup nice
filtering mechanisms
eg..

class GUIFilter:
   "A filter that only lets messges with gui tags
through."""
	def filter(self, log_record):
	    return hasattr(log_record, 'gui')

# set up a log, and a handler...
log = logging.getLogger(..)
file_handler = FileHandler(..)
log.addHandler(file_handler)
gui_msg_bar_handler = StreamHandler(..)
log.addHandler(gui_msg_bar_handler)
gui_msg_bar_handler.addFilter(GUIFilter())

# msg only goes to the file_handler
log.debug("here we go %s", "here's an arg")  

# msg goes to the file_handler and to the gui_handler.
log.x_debug(LogRecord(gui=True), "what you just tried
to do didn't work %s", "fool")


Change a) could be made with no backward compatability
problems (I can see), change b) could be made without
probs if you didn't overload the existing logging
methods with the new ones, and then deprecate the
existing ones  (though what you'd call the new fns I
don't know).

That said I quite like the logger lib and I use it. 
It's a lot better than anything I would have thought up.


cheers
    blaize



----------------------------------------------------------------------

>Comment By: Vinay Sajip (vsajip)
Date: 2006-05-02 09:11

Message:
Logged In: YES 
user_id=308438

Why does the recent introduction of the 'extra' keyword
argument, meant to allow easily adding extra attributes to
the LogRecord, not meet your use cases? The LogRecord is
meant to be just a handy container and not have much logic
(e.g. it needs to be serialised as XML, pickle etc.); why do
you need to customise LogRecord.__init__? I didn't see an
actual argument above for doing this, please point it out.

It's also the case that the msg argument passed to a logging
call need not be a string; it can be an arbitrary object on
which str() is called at message formatting time to get the
actual format string. So a custom object defining __str__
can return a customised message string.

Perhaps I'm not seeing the use case you have in sufficient
detail to understand why existing functionality does not
meet your needs; please feel free to follow up with more
detailed info.



----------------------------------------------------------------------

Comment By: blaize rhodes (blaize)
Date: 2006-04-22 09:56

Message:
Logged In: YES 
user_id=264689



For readability put an "if __name__ == '__main__':" above the 

# set up a log, and a handler...

line.  Sorry I didn't realize all my whitespace would get
eaten rendering the code ambiguous.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1474577&group_id=5470

From noreply at sourceforge.net  Tue May  2 12:48:27 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 02 May 2006 03:48:27 -0700
Subject: [ python-Bugs-1478529 ] size limit exceeded for read() from network
	drive
Message-ID: <E1FasQd-0003m6-Sf@sc8-sf-web1.sourceforge.net>

Bugs item #1478529, was opened at 2006-04-28 17:46
Message generated for change (Comment added) made by markshep
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1478529&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: Windows
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Sheppard (markshep)
Assigned to: Nobody/Anonymous (nobody)
Summary: size limit exceeded for read() from network drive

Initial Comment:
If you've got a network share mounted as a local drive
then Windows has a limit of 67,076,095 (0x03ff7fff)
bytes for a read from an open file on that drive.

Running the python read() method on an open file larger
than this size throws an "IOError: [Errno 22] Invalid
argument" exception.

A fix would be for python to internally use multiple
reads so as to not exceed this limit.


----------------------------------------------------------------------

>Comment By: Mark Sheppard (markshep)
Date: 2006-05-02 11:48

Message:
Logged In: YES 
user_id=1512331

I'm running Windows XP.  I've been unable to find any
documentation about this exact problem - only that fwrite
thing.  But my testing shows that it works if I do
file.read(67076095), but throws an exception with
file.read(67076096).

I'm not suggesting limiting all reads from Python.  All I'm
suggesting is that under the hood the Windows implementation
of Python's read() call actually uses multiple fread() (or
whatever) calls if more than 67076095 bytes need to be read.
 That's all.  No interface changes.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-04-30 17:23

Message:
Logged In: YES 
user_id=31435

Martin, here's an MS article seemingly related to this:

http://support.microsoft.com/default.aspx?scid=kb;en-us;899149

However, it's about writing to a file on a network drive,
not reading from it.  It says that opening the file in 'w+b'
mode, instead of 'wb' mode, is a workaround.

I couldn't find anything documenting the same kind of
problem for reading.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-30 11:10

Message:
Logged In: YES 
user_id=21627

What version of Windows are you using? Do you know of any
documentation of this limit? (without actually testing, I
find it hard to believe that this limit exists in Windows)

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-04-29 14:23

Message:
Logged In: YES 
user_id=849994

How can it be determined whether exactly this restriction
caused the "invalid argument" error? If it can't, there's
nothing that can be done -- restricting all reads just
because of a Windows limitation doesn't seem right.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1478529&group_id=5470

From noreply at sourceforge.net  Tue May  2 21:00:48 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 02 May 2006 12:00:48 -0700
Subject: [ python-Bugs-1478529 ] size limit exceeded for read() from network
	drive
Message-ID: <E1Fb076-00030J-0n@sc8-sf-web1.sourceforge.net>

Bugs item #1478529, was opened at 2006-04-28 18:46
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1478529&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: Windows
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Sheppard (markshep)
Assigned to: Nobody/Anonymous (nobody)
Summary: size limit exceeded for read() from network drive

Initial Comment:
If you've got a network share mounted as a local drive
then Windows has a limit of 67,076,095 (0x03ff7fff)
bytes for a read from an open file on that drive.

Running the python read() method on an open file larger
than this size throws an "IOError: [Errno 22] Invalid
argument" exception.

A fix would be for python to internally use multiple
reads so as to not exceed this limit.


----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-05-02 21:00

Message:
Logged In: YES 
user_id=21627

I could reproduce the write problem on XPSP2; I get the
Win32 error ERROR_NO_SYSTEM_RESOURCES after fwrite returns
(from GetLastError).

I can't reproduce the fread problem, though: in Python,
f.read(90*2**20) just returns with a 90MiB string. So it
could be a limitation of your machine (e.g. it might not
have enough memory), or of the server machine. I'm hesitant
to add a work-around for that into Python if this isn't a
system limitation. Performing multiple reads is also bad:
what happens if the first read succeeds, and the second one
fails? It might be that the system *really* is out of resources.

----------------------------------------------------------------------

Comment By: Mark Sheppard (markshep)
Date: 2006-05-02 12:48

Message:
Logged In: YES 
user_id=1512331

I'm running Windows XP.  I've been unable to find any
documentation about this exact problem - only that fwrite
thing.  But my testing shows that it works if I do
file.read(67076095), but throws an exception with
file.read(67076096).

I'm not suggesting limiting all reads from Python.  All I'm
suggesting is that under the hood the Windows implementation
of Python's read() call actually uses multiple fread() (or
whatever) calls if more than 67076095 bytes need to be read.
 That's all.  No interface changes.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-04-30 18:23

Message:
Logged In: YES 
user_id=31435

Martin, here's an MS article seemingly related to this:

http://support.microsoft.com/default.aspx?scid=kb;en-us;899149

However, it's about writing to a file on a network drive,
not reading from it.  It says that opening the file in 'w+b'
mode, instead of 'wb' mode, is a workaround.

I couldn't find anything documenting the same kind of
problem for reading.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-30 12:10

Message:
Logged In: YES 
user_id=21627

What version of Windows are you using? Do you know of any
documentation of this limit? (without actually testing, I
find it hard to believe that this limit exists in Windows)

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-04-29 15:23

Message:
Logged In: YES 
user_id=849994

How can it be determined whether exactly this restriction
caused the "invalid argument" error? If it can't, there's
nothing that can be done -- restricting all reads just
because of a Windows limitation doesn't seem right.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1478529&group_id=5470

From noreply at sourceforge.net  Tue May  2 22:15:37 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 02 May 2006 13:15:37 -0700
Subject: [ python-Bugs-1051840 ] HTMLParser doesn't treat endtags in <script>
	tags as CDATA
Message-ID: <E1Fb1HV-00050k-JC@sc8-sf-web2.sourceforge.net>

Bugs item #1051840, was opened at 2004-10-21 19:02
Message generated for change (Settings changed) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1051840&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Luke Bradley (neptune235)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: HTMLParser doesn't treat endtags in <script> tags as CDATA

Initial Comment:
HTMLParser.HTMLParser in Python 2.3.4 calls
self.handle_endtag() for end tags within script and
style sections, which it should not, because the
content is supposed to be CDATA, as defined in
CDATA_CONTENT_ELEMENTS within HTMLParser. The following
script will demonstrate this problem:

import HTMLParser

class MyHandler(HTMLParser.HTMLParser):
    tags = []
    def handle_starttag(self, tag, attr):
        self.tags.append(tag)
    def handle_endtag(self, tag):
        if tag != self.tags[-1]:
            #this should never happen in a well formed
document
            raise "Not well-formed, endtag '" + tag +
"' doesn't match starttag '" + self.lasttag + "'"
        self.tags.pop(-1)

s = """
<html>
    <body>
    This page is completely well formed
        <script language="javascript">
            alert("</a></a>");
        </script>
        blah blah
    </body>
</html>
"""

m = MyHandler()
m.feed(s)

This will raise an exception. I fixed the bug by
changing the parse_endtag function on line 318 of
HTMLParser to the following:

def parse_endtag(self, i):
    rawdata = self.rawdata
    assert rawdata[i:i+2] == "</", "unexpected call to
parse_endtag"
    match = endendtag.search(rawdata, i+1) # >
    if not match:
        return -1
    j = match.end()
    match = endtagfind.match(rawdata, i) # </ + tag + >
    if not match:
        self.error("bad end tag: %s" % `rawdata[i:j]`)
    tag = match.group(1)
    #START BUGFIX
    if self.interesting == interesting_cdata:
        #we're in of of the CDATA_CONTENT_ELEMENTS
        if tag == self.lasttag and tag in
self.CDATA_CONTENT_ELEMENTS:
            #its the end of the CDATA_CONTENT_ELEMENTS
tag we are in.
            self.handle_endtag(tag.lower())
            self.clear_cdata_mode()#backto normal mode
        else:
            #we're inside the CDATA_CONTENT_ELEMENTS
tag still. throw the tag to handle_data instead.
            self.handle_data(match.group())
    else:
        #we're not in a CDATA_CONTENT_ELEMENTS tag.
standard ending:
        self.handle_endtag(tag.lower())
    return j


----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-05-02 16:15

Message:
Logged In: YES 
user_id=3066

This is a common complaint (because no-one reads the specs),
but since people have lived with it this long, I'm inclined
to leave it alone.  If people want to read every two-bit
piece of broken HTML, they can use BeautifulSoup, which
handles that task quite nicely.

Rejecting as "don't go there."

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-10-23 20:46

Message:
Logged In: YES 
user_id=80475

Fred, what do you think?

----------------------------------------------------------------------

Comment By: Luke Bradley (neptune235)
Date: 2004-10-22 19:52

Message:
Logged In: YES 
user_id=178561

<i>Although a fix may be worthwhile, as this happens a lot in 
practice, HTMLParser is following the letter of the law in 
throwing exceptions on pages that aren't strictly valid. 

http://www.w3.org/TR/html4/appendix/notes.html#notes-
specifying-data</i>

Well you're right, I'll be damned! 
Hmm. I want to use HTMLParser to access other people's pages
on the net, and I can't fix their bad HTML. The problem here
is I'm not sure how to handle this at the level of my
Handler, without inadvertantly changing thier javascript by
doing something like:
handle_data("</" + tag + ">")
in the handle_entag event. Which lowercases the tag. Is
there a way to access the literal string of the endtag in my
handler I wonder? If not, it might be useful to add some
functionality to HTMLParser that allows us to handle invalid
HTML at the level of our handler without sacrificing
HTMLParsers commitment to standards compliance. 

----------------------------------------------------------------------

Comment By: Richard Brodie (leogah)
Date: 2004-10-22 14:02

Message:
Logged In: YES 
user_id=356893

Although a fix may be worthwhile, as this happens a lot in 
practice, HTMLParser is following the letter of the law in 
throwing exceptions on pages that aren't strictly valid. 

http://www.w3.org/TR/html4/appendix/notes.html#notes-
specifying-data

----------------------------------------------------------------------

Comment By: Luke Bradley (neptune235)
Date: 2004-10-21 19:04

Message:
Logged In: YES 
user_id=178561

oops, I didn't know this would remove indentation. Let me
attach a file.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1051840&group_id=5470

From noreply at sourceforge.net  Tue May  2 22:20:34 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 02 May 2006 13:20:34 -0700
Subject: [ python-Bugs-1076070 ] HTMLParser can't handle page with javascript
Message-ID: <E1Fb1MI-0007EX-GE@sc8-sf-web2.sourceforge.net>

Bugs item #1076070, was opened at 2004-11-30 10:22
Message generated for change (Settings changed) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076070&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: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Jeremy Hylton (jhylton)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: HTMLParser can't handle page with javascript

Initial Comment:
Perhaps the page is malformed -- I notice at least one
other problem with it -- but I'd like to parse it. 
Relevant excerpts appear to be:

<script language="JavaScript">
<!--
um.menuCode[i].replace(/<\/(li|ul)>/ig,'</$1>\n');
-->
</script>

goahead() identifies the next interesting part of the
page as the </$1> inside the javascript.  It's not
seeing the comment.  Should it?  I changed
interesting_cdata to lookup for <! as one interesting
possibility and it parsed the comment successfully.


----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-05-02 16:20

Message:
Logged In: YES 
user_id=3066

The "<!--" hackery is used to deal with really old browsers
that don't understand <script>.  Technically, all it should
have to look for is "</".

Closing as not worth changing.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076070&group_id=5470

From noreply at sourceforge.net  Tue May  2 22:47:44 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 02 May 2006 13:47:44 -0700
Subject: [ python-Bugs-1055864 ] HTMLParser not compliant to XHTML spec
Message-ID: <E1Fb1ma-0005lf-M4@sc8-sf-web4-b.sourceforge.net>

Bugs item #1055864, was opened at 2004-10-28 00:59
Message generated for change (Settings changed) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1055864&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: Luke Bradley (neptune235)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: HTMLParser not compliant to XHTML spec

Initial Comment:
HTMLParser has a problem related to the fact that is
doesn't seem to comply to the spec for XHTML. What I am
refering to can be read about here:
http://www.w3.org/TR/xhtml1/#h-4.8
In a nutshell, HTMLParser doesn't treat data inside
'script' or 'style' elements as #PCDATA, but rather
behaves like an HTML 4 parser even for XHTML documents,
parsing only end tags. As a result, entity references
in javascript are not converted as they should be.
XHTML authors writing to spec can expect entities in
script sections of XHTML documents to be converted if
the script is not explicitly escaped as a CDATA
section. which brings up problem two, That sections
explicitly escaped as CDATA are also parsed as HTML 4
'script' and 'style' sections...End tags are parsed...
My understanding is that this is bad as well:
http://www.w3.org/TR/2004/REC-xml-20040204/#dt-cdsection
because CDend is the only thing that's supposed to be
parsed in a CDATA section for all XML documents?



----------------------------------------------------------------------

Comment By: Luke Bradley (neptune235)
Date: 2004-10-28 18:23

Message:
Logged In: YES 
user_id=178561

Sure. I'll attach it as a file: tidytest2.py

btw: I'm no guru so tell me if I'm misinterpretting the w3c.
I'm just trying to use HTMLParser in such a way that it
won't mangle anybodies script sections, and I want to have
all my bases covered.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2004-10-28 15:41

Message:
Logged In: YES 
user_id=21627

Can you give an example demonstrating this problem, please?
A Python script with a small embedded HTML file, and a
PASS/FAIL condition would be best.

----------------------------------------------------------------------

Comment By: Luke Bradley (neptune235)
Date: 2004-10-28 04:31

Message:
Logged In: YES 
user_id=178561

I also reported bug 1051840. I discovered this when I was
looking for a universal way to handle all the wierd things
people do with their script sections on HTML/XHTML pages on
the net. I've ended up modifying HTMLParser.py so that the
HTMLParser class has an extra attribute called last_match,
which is the exact string of HTML that whatever handler
event  is being called for...So that putting:
sys.stdout.write(self.last_match) 
or
sys.stdout.write(self.get_last_match())
for every handler event (except handle_data, which can be
directly outputted) will output the page exactly as was
inputted. This allows me to handle all oddities in people's
code at the level of my handler, without changing HTMLParser
in any other way...
Here's the code, attached. Not that you care, but on the off
chance that you guys might want to think about doing
something like this....:)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1055864&group_id=5470

From noreply at sourceforge.net  Tue May  2 22:56:38 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 02 May 2006 13:56:38 -0700
Subject: [ python-Bugs-1480678 ] mmap tries to truncate special files
Message-ID: <E1Fb1vC-00057K-EH@sc8-sf-web6.sourceforge.net>

Bugs item #1480678, was opened at 2006-05-02 16:56
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=1480678&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: Carl Banks (aerojockey)
Assigned to: Nobody/Anonymous (nobody)
Summary: mmap tries to truncate special files

Initial Comment:
One Unix, the resize() method of an mmap object calls
ftruncate to also resize the associated file.  Problem
is, ftruncate fails if the fd refers to a special file.
 This is a problem for someone trying to resize an
anonymous memory map using /dev/zero.

Apparently hasn't been fixed in 2.5 (based on SVN and
changelogs) but I haven't tested it.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1480678&group_id=5470

From noreply at sourceforge.net  Tue May  2 22:58:07 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 02 May 2006 13:58:07 -0700
Subject: [ python-Bugs-1465014 ] CSV regression in 2.5a1: multi-line cells
Message-ID: <E1Fb1wd-0007LO-As@sc8-sf-web3.sourceforge.net>

Bugs item #1465014, was opened at 2006-04-05 11:14
Message generated for change (Comment added) made by goodger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465014&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: 9
Submitted By: David Goodger (goodger)
Assigned to: Nobody/Anonymous (nobody)
Summary: CSV regression in 2.5a1: multi-line cells

Initial Comment:
Running the attached csv_test.py under Python 2.4.2
(Windows XP SP1) produces:

>c:\apps\python24\python.exe ./csv_test.py
['one', '2', 'three (line 1)\n(line 2)']

Note that the third item in the row contains a newline
between "(line 1)" and "(line 2)".

With Python 2.5a1, I get:

>c:\apps\python25\python.exe ./csv_test.py
['one', '2', 'three (line 1)(line 2)']

Notice the missing newline, which is significant.  The
CSV module under 2.5a1 seems to lose data.


----------------------------------------------------------------------

>Comment By: David Goodger (goodger)
Date: 2006-05-02 16:58

Message:
Logged In: YES 
user_id=7733

Further investigation has revealed that the regression only
affects iterator I/O, not file I/O.  The attached
csv_test.py demonstrates.  Run with Python 2.5 to get:

results from file I/O:
[['one', '2', 'three (line 1)\n(line 2)']]

results from iterator I/O:
[['one', '2', 'three (line 1)(line 2)']]

----------------------------------------------------------------------

Comment By: David Goodger (goodger)
Date: 2006-04-05 11:44

Message:
Logged In: YES 
user_id=7733

This bug seems to be a side effect of revision 38290 on
Modules/_csv.c, which was prompted by bug 967934
(http://www.python.org/sf/967934).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465014&group_id=5470

From noreply at sourceforge.net  Tue May  2 23:04:08 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 02 May 2006 14:04:08 -0700
Subject: [ python-Bugs-1465014 ] CSV regression in 2.5a1: multi-line cells
Message-ID: <E1Fb22S-00052T-0t@sc8-sf-web1.sourceforge.net>

Bugs item #1465014, was opened at 2006-04-05 11:14
Message generated for change (Comment added) made by goodger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465014&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: 9
Submitted By: David Goodger (goodger)
>Assigned to: Andrew McNamara (andrewmcnamara)
Summary: CSV regression in 2.5a1: multi-line cells

Initial Comment:
Running the attached csv_test.py under Python 2.4.2
(Windows XP SP1) produces:

>c:\apps\python24\python.exe ./csv_test.py
['one', '2', 'three (line 1)\n(line 2)']

Note that the third item in the row contains a newline
between "(line 1)" and "(line 2)".

With Python 2.5a1, I get:

>c:\apps\python25\python.exe ./csv_test.py
['one', '2', 'three (line 1)(line 2)']

Notice the missing newline, which is significant.  The
CSV module under 2.5a1 seems to lose data.


----------------------------------------------------------------------

>Comment By: David Goodger (goodger)
Date: 2006-05-02 17:04

Message:
Logged In: YES 
user_id=7733

Assigned to Andrew McNamara, since his change appears to
have caused this regression (revision 38290 on
Modules/_csv.c).

----------------------------------------------------------------------

Comment By: David Goodger (goodger)
Date: 2006-05-02 16:58

Message:
Logged In: YES 
user_id=7733

Further investigation has revealed that the regression only
affects iterator I/O, not file I/O.  The attached
csv_test.py demonstrates.  Run with Python 2.5 to get:

results from file I/O:
[['one', '2', 'three (line 1)\n(line 2)']]

results from iterator I/O:
[['one', '2', 'three (line 1)(line 2)']]

----------------------------------------------------------------------

Comment By: David Goodger (goodger)
Date: 2006-04-05 11:44

Message:
Logged In: YES 
user_id=7733

This bug seems to be a side effect of revision 38290 on
Modules/_csv.c, which was prompted by bug 967934
(http://www.python.org/sf/967934).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465014&group_id=5470

From noreply at sourceforge.net  Wed May  3 03:45:52 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 02 May 2006 18:45:52 -0700
Subject: [ python-Bugs-1478529 ] size limit exceeded for read() from network
	drive
Message-ID: <E1Fb6R6-0002aQ-OI@sc8-sf-web2.sourceforge.net>

Bugs item #1478529, was opened at 2006-04-28 12:46
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1478529&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: Windows
>Group: 3rd Party
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Mark Sheppard (markshep)
Assigned to: Nobody/Anonymous (nobody)
Summary: size limit exceeded for read() from network drive

Initial Comment:
If you've got a network share mounted as a local drive
then Windows has a limit of 67,076,095 (0x03ff7fff)
bytes for a read from an open file on that drive.

Running the python read() method on an open file larger
than this size throws an "IOError: [Errno 22] Invalid
argument" exception.

A fix would be for python to internally use multiple
reads so as to not exceed this limit.


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2006-05-02 21:45

Message:
Logged In: YES 
user_id=31435

Sorry, I'm closing this as "3rd Party, Won't Fix".  It's
certainly not Python's doing that Microsoft's stdio
implementation has peculiar undocumented warts (Python just
calls the platform C's fread() here), so at best this is a
request for enhancement rather than a Python bug.

If there is a bug here, it's Microsoft's bug, and then the
proper source for a fix is also Microsoft.  This is
especially true since the two people who have tried this
here don't see the same behavior -- we don't even know what
"the bug" is.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-05-02 15:00

Message:
Logged In: YES 
user_id=21627

I could reproduce the write problem on XPSP2; I get the
Win32 error ERROR_NO_SYSTEM_RESOURCES after fwrite returns
(from GetLastError).

I can't reproduce the fread problem, though: in Python,
f.read(90*2**20) just returns with a 90MiB string. So it
could be a limitation of your machine (e.g. it might not
have enough memory), or of the server machine. I'm hesitant
to add a work-around for that into Python if this isn't a
system limitation. Performing multiple reads is also bad:
what happens if the first read succeeds, and the second one
fails? It might be that the system *really* is out of resources.

----------------------------------------------------------------------

Comment By: Mark Sheppard (markshep)
Date: 2006-05-02 06:48

Message:
Logged In: YES 
user_id=1512331

I'm running Windows XP.  I've been unable to find any
documentation about this exact problem - only that fwrite
thing.  But my testing shows that it works if I do
file.read(67076095), but throws an exception with
file.read(67076096).

I'm not suggesting limiting all reads from Python.  All I'm
suggesting is that under the hood the Windows implementation
of Python's read() call actually uses multiple fread() (or
whatever) calls if more than 67076095 bytes need to be read.
 That's all.  No interface changes.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-04-30 12:23

Message:
Logged In: YES 
user_id=31435

Martin, here's an MS article seemingly related to this:

http://support.microsoft.com/default.aspx?scid=kb;en-us;899149

However, it's about writing to a file on a network drive,
not reading from it.  It says that opening the file in 'w+b'
mode, instead of 'wb' mode, is a workaround.

I couldn't find anything documenting the same kind of
problem for reading.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-30 06:10

Message:
Logged In: YES 
user_id=21627

What version of Windows are you using? Do you know of any
documentation of this limit? (without actually testing, I
find it hard to believe that this limit exists in Windows)

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-04-29 09:23

Message:
Logged In: YES 
user_id=849994

How can it be determined whether exactly this restriction
caused the "invalid argument" error? If it can't, there's
nothing that can be done -- restricting all reads just
because of a Windows limitation doesn't seem right.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1478529&group_id=5470

From noreply at sourceforge.net  Wed May  3 04:14:42 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 02 May 2006 19:14:42 -0700
Subject: [ python-Bugs-616013 ] cPickle documentation incomplete
Message-ID: <E1Fb6t0-0005Rt-SZ@sc8-sf-web6.sourceforge.net>

Bugs item #616013, was opened at 2002-09-28 21:21
Message generated for change (Comment added) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=616013&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: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Guido van Rossum (gvanrossum)
>Assigned to: Nobody/Anonymous (nobody)
Summary: cPickle documentation incomplete

Initial Comment:
Many of the differences between the cPickle module and
the pickle module appear undocumented, despite a claim
in the cPickle module that the pickle docs explain the
differences.

For example, I just found that cPickle.Pickler() can be
called without a file argument, which makes it use an
internal list to store the pickled data; and that in
that case it has a method getvalue() that returns the
contents of that list as a string; and that its dump()
method takes a second argument which, if true, calls
the getvalue() method.  Who knows what else it supports.

Someone should go over the cPickle source and compare
the API *carefully* with the documented pickle API.

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-05-02 22:14

Message:
Logged In: YES 
user_id=3066

Unassigning myself; clearly, I've not had time for this.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=616013&group_id=5470

From noreply at sourceforge.net  Wed May  3 04:59:24 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 02 May 2006 19:59:24 -0700
Subject: [ python-Bugs-1471407 ] setup.py --help-commands exception
Message-ID: <E1Fb7aG-0002bW-OW@sc8-sf-web1.sourceforge.net>

Bugs item #1471407, was opened at 2006-04-16 12:23
Message generated for change (Comment added) made by jwpye
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1471407&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Distutils
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: James William Pye (jwpye)
Assigned to: Nobody/Anonymous (nobody)
Summary: setup.py --help-commands exception

Initial Comment:
>From a recent trunk build(2.5a1) on FreeBSD 6.1:

jwp at lit:/src/org/pgfoundry/python/fe/local %
/usr/dev/bin/python ./setup.py --help-commands
Standard commands:
  build            build everything needed to install
  build_py         "build" pure Python modules (copy to
build directory)
  build_ext        build C/C++ extensions (compile/link
to build directory)
  build_clib       build C/C++ libraries used by Python
extensions
  build_scripts    "build" scripts (copy and fixup #! line)
  clean            clean up temporary files from
'build' command
  install          install everything from build directory
  install_lib      install all Python modules
(extensions and pure Python)
  install_headers  install C/C++ header files
  install_scripts  install scripts (Python or otherwise)
  install_data     install data files
  sdist            create a source distribution
(tarball, zip file, etc.)
Traceback (most recent call last):
  File "./setup.py", line 52, in <module>
    setup(defaults)
  File "./setup.py", line 46, in setup
    d = distutils.core.setup(**kw)
  File "/usr/dev/lib/python2.5/distutils/core.py", line
137, in setup
    ok = dist.parse_command_line()
  File "/usr/dev/lib/python2.5/distutils/dist.py", line
455, in parse_command_line
    if self.handle_display_options(option_order):
  File "/usr/dev/lib/python2.5/distutils/dist.py", line
680, in handle_display_options
    self.print_commands()
  File "/usr/dev/lib/python2.5/distutils/dist.py", line
758, in print_commands
    max_length)
  File "/usr/dev/lib/python2.5/distutils/dist.py", line
720, in print_command_list
    klass = self.get_command_class(cmd)
  File "/usr/dev/lib/python2.5/distutils/dist.py", line
851, in get_command_class
    raise DistutilsModuleError("invalid command '%s'" %
command)
distutils.errors.DistutilsModuleError: invalid command
'register'

----------------------------------------------------------------------

>Comment By: James William Pye (jwpye)
Date: 2006-05-02 19:59

Message:
Logged In: YES 
user_id=1044177

k, svn update'd and it looks good.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-05-01 13:25

Message:
Logged In: YES 
user_id=849994

It looks like the "distutils.command.register" module is not
importable. Can you retry with alpha2 and see if the problem
persists?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1471407&group_id=5470

From noreply at sourceforge.net  Wed May  3 07:21:21 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 02 May 2006 22:21:21 -0700
Subject: [ python-Bugs-1480678 ] mmap tries to truncate special files
Message-ID: <E1Fb9nd-0002gw-Ih@sc8-sf-web6.sourceforge.net>

Bugs item #1480678, was opened at 2006-05-02 13:56
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1480678&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: Carl Banks (aerojockey)
Assigned to: Nobody/Anonymous (nobody)
Summary: mmap tries to truncate special files

Initial Comment:
One Unix, the resize() method of an mmap object calls
ftruncate to also resize the associated file.  Problem
is, ftruncate fails if the fd refers to a special file.
 This is a problem for someone trying to resize an
anonymous memory map using /dev/zero.

Apparently hasn't been fixed in 2.5 (based on SVN and
changelogs) but I haven't tested it.

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-05-02 22:21

Message:
Logged In: YES 
user_id=33168

I don't understand what the problem is.  ISTM if you resize
a special file an exception will be raised.  Is that not the
case?  What do you expect to happen?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1480678&group_id=5470

From noreply at sourceforge.net  Wed May  3 07:33:18 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 02 May 2006 22:33:18 -0700
Subject: [ python-Bugs-680577 ] urllib2 authentication problem
Message-ID: <E1Fb9zC-0000ia-7c@sc8-sf-web1.sourceforge.net>

Bugs item #680577, was opened at 2003-02-05 00:22
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=680577&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: Closed
>Resolution: Fixed
Priority: 5
Submitted By: GaryD (gazzadee)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2 authentication problem

Initial Comment:
I've found a problem using the authentication in urllib2.

When matching up host-names in order to find a
password, then putting the protocol in the address
makes it seem like a different address. eg...

I create a HTTPBasicAuthHandler with a
HTTPPasswordMgrWithDefaultRealm, and add the tuple
(None, &quot;http://proxy.blah.com:17828&quot;, &quot;foo&quot;, &quot;bar&quot;) to it.

I then setup the proxy to use
http://proxy.blah.com:17828 (which requires
authentication).

When I connect, the password lookup fails, because it
is trying to find a match for &quot;proxy.blah.com:17828&quot;
rather than &quot;http://proxy.blah.com:17828&quot;

This problem doesn't exist if I pass
&quot;proxy.blah.com:17828&quot; to the password manager.

There seems to be some stuff in HTTPPasswordMgr to deal
with variations on site names, but I guess it's not
working in this case (unless this is intentional).

Version Info:
Python 2.2 (#1, Feb 24 2002, 16:21:58)
[GCC 2.96 20000731 (Mandrake Linux 8.2 2.96-0.76mdk)]
on linux-i386


----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-05-03 05:33

Message:
Logged In: YES 
user_id=849994

Closing accordingly.

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2006-04-15 18:45

Message:
Logged In: YES 
user_id=261020

This issue is fixed by patch 1470846.


----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2003-12-16 12:49

Message:
Logged In: YES 
user_id=261020

Thanks! 
 
It seems .reduce_uri() tries to cope with hostnames as well as 
absoluteURIs.  I don't understand why it wants to do that, but it 
fails, because it doesn't anticipate what urlparse does when a 
port is present: 
 
&gt;&gt;&gt; urlparse.urlparse(&quot;foo.bar.com&quot;) 
('', '', 'foo.bar.com', '', '', '') 
&gt;&gt;&gt; urlparse.urlparse(&quot;foo.bar.com:80&quot;) 
('foo.bar.com', '', '80', '', '', '') 
 
I haven't checked, but I assume it's just incorrect use of 
urlparse to pass it a hostname. 
 
Of course, if it's &quot;fixed&quot; to only accept absoluteURIs, it will 
break existing code, so I guess it must be fixed for 
hostnames. :-(( 
 
Also, I think .is_suburi(&quot;/foo/spam&quot;, &quot;/foo/eggs&quot;) should return 
False, but returns True, and .http_error_40x() use 
req.get_host() when they should be using req.get_full_url() 
(from a quick look at RFC 2617). 

----------------------------------------------------------------------

Comment By: GaryD (gazzadee)
Date: 2003-12-16 03:10

Message:
Logged In: YES 
user_id=693152

Okay, I have attached a file that replicates this problem.

If you run it as is (replacing the proxy name and address
with something suitable), then it will fail (requiring proxy
authentication).

If you uncomment line 23 (which specifies the password
without the scheme), then it will work successfully.

Technical Info:
 * For a proxy, I am using Squid Cache version 2.4.STABLE7
for i586-mandrake-linux-gnu...
 * I have replicated the problem with Python 2.2.2 on Linux,
and Python 2.3.2 on Windows XP.

----------------------------------------------------------------------

Comment By: GaryD (gazzadee)
Date: 2003-12-16 02:08

Message:
Logged In: YES 
user_id=693152

This was a while ago, and my memory has faded. I'll try to
respond intelligently.

I think the question was with the way the password manager
looks up passwords, rather than anything else.

I am pretty sure that the problem is not to do with the URI
passed to urlopen(). In the code shown below, the problem
was solely dependent on whether I added the line:
    (None, &quot;blah.com:17828&quot;, &quot;foo&quot;, &quot;bar&quot;)
...to the HTTPPasswordMgrWithDefaultRealm object.

If that password set was added, then the password lookup for
the proxy was successful, and urlopen() worked. If that
password set was not included, then the password lookup for
the proxy was unsuccessful (despite the inclusion of the
other 2, similar, password sets - &quot;http://blah.com:17828&quot;
and &quot;blah.com&quot;), and urlopen() would fail. Hence my
suspicion that the password manager did not fully remove the
scheme, despite attempts to do so.

I'll see if I can set it up on the latest python and get it
to happen again.

Just as an explanation, the situation was that I was running
an authenticating proxy on a non-standard port (in order to
avoid clashing with the normal proxy), in order to test out
how my download code would work through an authenticating proxy.

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2003-12-01 00:14

Message:
Logged In: YES 
user_id=261020

The problem seems to be with the port (:17828), not the URL 
scheme (http:), because HTTPPasswordMgr.reduce_uri() 
removes the scheme. 
 
RFC 2617 (top of page 3) says nothing about removing the 
port from the URI.  urllib2 does not remove the port, so this 
doesn't appear to be a bug. 
 
I guess gazzadee was doing a urlopen with a different 
canonical root URI (RFC 2617, top of page 3 again) to the one 
he gave in add_password (ie. the URL he passed to urlopen() 
had no explicit port number). 

----------------------------------------------------------------------

Comment By: GaryD (gazzadee)
Date: 2003-02-09 23:17

Message:
Logged In: YES 
user_id=693152

Okay, the same problem crops up in Python 2.2.2 running
under cygwin on Win XP

Version Info:
Python 2.2.2 (#1, Dec 31 2002, 12:24:34) 
[GCC 3.2 20020927 (prerelease)] on cygwin

Here's the pertinent section of my test file (passwords and
URL changed to protect the innocent):


    # Setup proxy
    proxy_handler = ProxyHandler({&quot;http&quot; :
&quot;http://blah.com:17828&quot;})
    
    # Setup authentication
    pass_mgr = HTTPPasswordMgrWithDefaultRealm()
    for passwd in [ \
                   (None, &quot;http://blah.com:17828&quot;, &quot;foo&quot;,
&quot;bar&quot;), \
#                   (None, &quot;blah.com:17828&quot;, &quot;foo&quot;,
&quot;bar&quot;), \	# Works if this line is uncommented
                   (None, &quot;blah.com&quot;, &quot;foo&quot;, &quot;bar&quot;), \
                  ]:
        print(&quot;Adding password set (%s, %s, %s, %s)&quot; % passwd)
        pass_mgr.add_password(*passwd)
    auth_handler = HTTPBasicAuthHandler(pass_mgr)
    proxy_auth_handler = ProxyBasicAuthHandler(pass_mgr)
    
    # Now build a new URL opener and install it
    opener = build_opener(proxy_handler, proxy_auth_handler,
auth_handler, HTTPHandler)
    install_opener(opener)
    
    # Now try to open a file and see what happens
    request = Request(&quot;http://www.google.com&quot;)
    try:
        remotefile = urlopen(request)
    except HTTPError, ex:
        print(&quot;Unable to download file due to HTTP Error %d
(%s).&quot; % (ex.code, ex.msg))
        return



----------------------------------------------------------------------

Comment By: Gerhard H?ring (ghaering)
Date: 2003-02-07 23:21

Message:
Logged In: YES 
user_id=163326

Can you please retry with Python 2.2.2?

It seems that a related bug was fixed for 2.2.2:
http://python.org/2.2.2/NEWS.txt has an entry:

&quot;&quot;&quot;
- In urllib2.py: fix proxy config with user+pass
authentication.  [SF
  patch 527518]
&quot;&quot;&quot;

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=680577&group_id=5470

From noreply at sourceforge.net  Wed May  3 07:34:00 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 02 May 2006 22:34:00 -0700
Subject: [ python-Feature Requests-1448934 ] urllib2+https+proxy not working
Message-ID: <E1Fb9zs-00014g-0B@sc8-sf-web1.sourceforge.net>

Feature Requests item #1448934, was opened at 2006-03-13 15:55
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1448934&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: Rui Martins (ruibmartins)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2+https+proxy not working

Initial Comment:
Using urllib2 to access an https site using a proxy 
doesn't work. It always returns "<HTML> </HTML>"

I've been looking around for bug reports on this and 
code samples, but all that I've got were emails/forum 
posts dating back to 2003 warning that the HTTPS over 
Proxy in urllib2 isn't implemented in Python!

Is this true?

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-05-03 05:33

Message:
Logged In: YES 
user_id=849994

Moving to Feature Requests.

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2006-04-15 17:27

Message:
Logged In: YES 
user_id=261020

Yes, there is no special support for using https proxies
(via the CONNECT method) in httplib or urllib2.

http://python.org/sf/515003 shows how to do it, but the
patch is not good enough to be added to the standard
library.  Feel free to write a better patch!

Please close this, since it's really a feature request, not
a bug.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1448934&group_id=5470

From noreply at sourceforge.net  Wed May  3 07:35:54 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 02 May 2006 22:35:54 -0700
Subject: [ python-Bugs-1436428 ] urllib has trouble with Windows filenames
Message-ID: <E1FbA1i-000269-66@sc8-sf-web1.sourceforge.net>

Bugs item #1436428, was opened at 2006-02-22 06:03
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1436428&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: Wont Fix
Priority: 5
Submitted By: Donovan Eastman (dpeastman)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib has trouble with Windows filenames

Initial Comment:
When you pass urllib the name of a local file including
a Windows drive letter (e.g. 'C:\dir\My File.txt')
URLopener.open() incorrectly interprets the drive
letter as the scheme of a URL.  Of course, given that
there is no scheme 'C', this fails.

I have solved this in my own code by putting the
following test before calling urllib.urlopen():

if url[1] == ':' and url[0].isalpha():
    url = 'file:' + url

Although this works fine in my particular case, it
seems like urllib should just simply "do the right
thing" without having to worry about it.  Therefore I
propose that urllib should automatically assume that
any URL that begins with a single alpha followed by a
colon is a local file.

The only potential downside would be that it would
preclude the use of single letter scheme names.  I did
a little research on this.  RFC 3986 suggests, but does
not explicitly state that scheme names must be more
than one character.
(http://www.gbiv.com/protocols/uri/rfc/rfc3986.html#scheme)
.  That said, there are no currently recognized single
letter scheme names
(http://www.iana.org/assignments/uri-schemes.html) and
it seems very unlikely that there every would be.

I would gladly write the code for this myself -- but I
suspect that it would take someone longer to review and
integrate my changes than it would to just write the code.

Thanks,
Donovan


----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-05-03 05:35

Message:
Logged In: YES 
user_id=849994

I agree with zseil.

----------------------------------------------------------------------

Comment By: ?iga Seilnacht (zseil)
Date: 2006-04-13 00:12

Message:
Logged In: YES 
user_id=1326842

There are already two platform specific functions
in urllib module just for this purpose: pathname2url
and url2pathname. See
http://docs.python.org/lib/module-urllib.html#l2h-3193.
I agree that this should be closed as invalid.

----------------------------------------------------------------------

Comment By: Andrew Clover (bobince)
Date: 2006-03-20 17:41

Message:
Logged In: YES 
user_id=311085

Filepaths aren't URIs and attempting to hide the difference
in the backend is doomed to fail (as it did for SAX).

Throw filenames with colons in, network paths, Mac paths and
RISC OS paths into the mix, and you've got a situation where
it is all but impossible to handle correctly.

In any case, the docs *don't* say you can pass in a filepath:

  If the URL does not have a scheme identifier, or if
  it has file: as its scheme identifier, this opens a
  local file

This means the string you pass in is unequivocally a URL
*not* a pathname... just that you can leave the scheme
prefix off for file: URLs. Effectively this is a relative URL.

r'C:\spam' is *not* a valid way to refer to a local file
using a relative URL. Pass it through pathname2url and
you'll get '///C|/spam', which is okay; 'C|/spam' and
'/C|span' will also work.

Even on Unix, a filepath won't always work when passed to
urlopen. Filenames can have percent signs in, which have to
be encoded in URLs, for example. Always use pathname2url or
you're going to trip up.

(Suggest setting status INVALID, possible clarification to
docs to warn against passing a filepath to urlopen?)


----------------------------------------------------------------------

Comment By: Donovan Eastman (dpeastman)
Date: 2006-03-14 02:32

Message:
Logged In: YES 
user_id=757799

OK - Here's my suggested fix:
This can be fixed with a single if statement (and a comment
to explain it to confused unix programmers).

In splittype(), right after the line that reads: 
scheme = match.group(1)
add the following:
#ignore single char schemes to avoid confusion with win32
drive letters
if len(scheme) > 1:

...and indent the next line.

Alternatively, the if statement could read:
if len(scheme) > 1 or sys.platform != 'win32':
...which would allow single letter scheme names on
non-Windows systems.  I would argue that it is better to be
consistent and have it work the same way on all OS's.

----------------------------------------------------------------------

Comment By: Donovan Eastman (dpeastman)
Date: 2006-03-14 01:56

Message:
Logged In: YES 
user_id=757799

Reasons why urllib should open local files:
1) This allows you to write code that handles local files
and Internet files equally well -- without having to do any
special magic of your own.
2) The docs all say that it should.

I believe this would work just fine under Unix. In
URLopener.open() it looks for the protocol prefix and if it
can't find one, it assumes that it is a local file.

The problem on Windows is that you have these pesky drive
letters.  The form 'C:\location' ends up looking a lot like
the form 'http://location'.  Therefore it looks for a
protocol called 'c' -- which obviously isn't going to work.

----------------------------------------------------------------------

Comment By: Koen van de Sande (shadowmorpher)
Date: 2006-03-13 19:19

Message:
Logged In: YES 
user_id=270334

Why should the URL lib module support opening of local 
files? It already does so through the file: protocol prefix, 
and do not see why it should support automatic detection of 
Windows filenames. AFAIK it does not do automatic detection 
of Unix filenames (one could recognize it from /home/
something), so why would Windows work differently?

I'm not an expert or anything, so I might be wrong.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1436428&group_id=5470

From noreply at sourceforge.net  Wed May  3 08:13:05 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 02 May 2006 23:13:05 -0700
Subject: [ python-Bugs-1480678 ] mmap tries to truncate special files
Message-ID: <E1FbAbh-0004GE-KW@sc8-sf-web6.sourceforge.net>

Bugs item #1480678, was opened at 2006-05-02 16:56
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1480678&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: Carl Banks (aerojockey)
Assigned to: Nobody/Anonymous (nobody)
Summary: mmap tries to truncate special files

Initial Comment:
One Unix, the resize() method of an mmap object calls
ftruncate to also resize the associated file.  Problem
is, ftruncate fails if the fd refers to a special file.
 This is a problem for someone trying to resize an
anonymous memory map using /dev/zero.

Apparently hasn't been fixed in 2.5 (based on SVN and
changelogs) but I haven't tested it.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2006-05-03 02:13

Message:
Logged In: YES 
user_id=31435

Ya, this isn't a bug:  resize() is documented as changing
the size of _both_ the map and the file.  If the size of the
file can't be changed, then of course resize() will fail.

aerojockey:  can't you simply close your current map and
create a new map with the size you want?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-05-03 01:21

Message:
Logged In: YES 
user_id=33168

I don't understand what the problem is.  ISTM if you resize
a special file an exception will be raised.  Is that not the
case?  What do you expect to happen?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1480678&group_id=5470

From noreply at sourceforge.net  Wed May  3 11:26:20 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 03 May 2006 02:26:20 -0700
Subject: [ python-Feature Requests-1476166 ] Add SeaMonkey to webbrowser.py
Message-ID: <E1FbDci-0003iE-V6@sc8-sf-web6.sourceforge.net>

Feature Requests item #1476166, was opened at 2006-04-25 18:32
Message generated for change (Comment added) made by phd
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1476166&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: Accepted
Priority: 5
Submitted By: Oleg Broytmann (phd)
>Assigned to: Georg Brandl (gbrandl)
Summary: Add SeaMonkey to webbrowser.py

Initial Comment:
Add SeaMonkey to webbrowser.py as yet another Mozilla
family browser. Just prepend "seamonkey" to the list
("mozilla-firefox", "firefox",                        
                                    "mozilla-firebird",
"firebird",                                           
        "mozilla", "netscape") in the
register_X_browsers().

----------------------------------------------------------------------

>Comment By: Oleg Broytmann (phd)
Date: 2006-05-03 13:26

Message:
Logged In: YES 
user_id=4799

Sorry, I should check webbrowser.py more careful. Please add
"seamonkey" after

if sys.platform[:3] == "win":
    ...

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-04-28 20:31

Message:
Logged In: YES 
user_id=849994

Added in rev. 45780.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1476166&group_id=5470

From noreply at sourceforge.net  Wed May  3 12:38:20 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 03 May 2006 03:38:20 -0700
Subject: [ python-Bugs-1478529 ] size limit exceeded for read() from network
	drive
Message-ID: <E1FbEkO-0001i8-N1@sc8-sf-web5.sourceforge.net>

Bugs item #1478529, was opened at 2006-04-28 17:46
Message generated for change (Comment added) made by markshep
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1478529&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: Windows
Group: 3rd Party
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: Mark Sheppard (markshep)
Assigned to: Nobody/Anonymous (nobody)
Summary: size limit exceeded for read() from network drive

Initial Comment:
If you've got a network share mounted as a local drive
then Windows has a limit of 67,076,095 (0x03ff7fff)
bytes for a read from an open file on that drive.

Running the python read() method on an open file larger
than this size throws an "IOError: [Errno 22] Invalid
argument" exception.

A fix would be for python to internally use multiple
reads so as to not exceed this limit.


----------------------------------------------------------------------

>Comment By: Mark Sheppard (markshep)
Date: 2006-05-03 11:38

Message:
Logged In: YES 
user_id=1512331

Thanks for closing this bug without giving me a chance to
follow up!

The problem isn't caused by a limitation of my machine -
it's got 3 GiB of RAM.

I've done some more testing on this and the problem only
appears when connected to a server running certain SMB
implementations:

  The local Windows XP machine
  A remote Windows XP machine
  Samba 3.0.22 on Linux

When connected to servers running the following SMB
implementations the problem isn't present:

  Windows NT 4.0 Server
  Windows Server 2000
  Windows Server 2003 Standard Edition

As this error is being returned by the underlying fread()
call the proper place for it to be fixed is there, but the
chances of Microsoft doing so for Windows XP are negligible.

As you're trying to provide a cross-platform language then
having to put up with OS's undocumented warts is just part
of the job.  As it's entirely possible for you to implement
a work-around for this problem Python I think you should. 
One of reasons for using a high level language like Python
is to be insulated from system quirks likes this.  If you're
refusing to smooth over these quirks where possible then
you're undermining that reason.

The documentation for Python's read() method on a file
handle already says "Note that this method may call the
underlying C function fread() more than once", so this
possibility is already catered for in the documentation.

As this problem only affects remotely mounted filesystems
the workaround need only be used for such filesystems.  You
can determine whether or not a drive is a network one by
using the GetDriveType() Windows call.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-05-03 02:45

Message:
Logged In: YES 
user_id=31435

Sorry, I'm closing this as "3rd Party, Won't Fix".  It's
certainly not Python's doing that Microsoft's stdio
implementation has peculiar undocumented warts (Python just
calls the platform C's fread() here), so at best this is a
request for enhancement rather than a Python bug.

If there is a bug here, it's Microsoft's bug, and then the
proper source for a fix is also Microsoft.  This is
especially true since the two people who have tried this
here don't see the same behavior -- we don't even know what
"the bug" is.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-05-02 20:00

Message:
Logged In: YES 
user_id=21627

I could reproduce the write problem on XPSP2; I get the
Win32 error ERROR_NO_SYSTEM_RESOURCES after fwrite returns
(from GetLastError).

I can't reproduce the fread problem, though: in Python,
f.read(90*2**20) just returns with a 90MiB string. So it
could be a limitation of your machine (e.g. it might not
have enough memory), or of the server machine. I'm hesitant
to add a work-around for that into Python if this isn't a
system limitation. Performing multiple reads is also bad:
what happens if the first read succeeds, and the second one
fails? It might be that the system *really* is out of resources.

----------------------------------------------------------------------

Comment By: Mark Sheppard (markshep)
Date: 2006-05-02 11:48

Message:
Logged In: YES 
user_id=1512331

I'm running Windows XP.  I've been unable to find any
documentation about this exact problem - only that fwrite
thing.  But my testing shows that it works if I do
file.read(67076095), but throws an exception with
file.read(67076096).

I'm not suggesting limiting all reads from Python.  All I'm
suggesting is that under the hood the Windows implementation
of Python's read() call actually uses multiple fread() (or
whatever) calls if more than 67076095 bytes need to be read.
 That's all.  No interface changes.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-04-30 17:23

Message:
Logged In: YES 
user_id=31435

Martin, here's an MS article seemingly related to this:

http://support.microsoft.com/default.aspx?scid=kb;en-us;899149

However, it's about writing to a file on a network drive,
not reading from it.  It says that opening the file in 'w+b'
mode, instead of 'wb' mode, is a workaround.

I couldn't find anything documenting the same kind of
problem for reading.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-30 11:10

Message:
Logged In: YES 
user_id=21627

What version of Windows are you using? Do you know of any
documentation of this limit? (without actually testing, I
find it hard to believe that this limit exists in Windows)

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-04-29 14:23

Message:
Logged In: YES 
user_id=849994

How can it be determined whether exactly this restriction
caused the "invalid argument" error? If it can't, there's
nothing that can be done -- restricting all reads just
because of a Windows limitation doesn't seem right.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1478529&group_id=5470

From noreply at sourceforge.net  Wed May  3 14:04:11 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 03 May 2006 05:04:11 -0700
Subject: [ python-Feature Requests-1481036 ] IOBaseError
Message-ID: <E1FbG5T-0003x3-1j@sc8-sf-web1.sourceforge.net>

Feature Requests item #1481036, was opened at 2006-05-03 14:04
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1481036&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: kxroberto (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: IOBaseError

Initial Comment:
Maybe there should be a common base Exception class
"IOBaseError" for :   EnvironmentError(IOError,
OSError),  EOFError, socket.error, socket.sslerror,
ftplib.all_errors, etc.  

Nice as it and not all IO sublibs have to be imported
to catch such errors.

See a recent need in patch #1481032 . I have this need
very often in mixed IO apps and am forced to except
naked (and being exposed to pythonic AttribError's etc. )

-robert

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1481036&group_id=5470

From noreply at sourceforge.net  Wed May  3 19:32:13 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 03 May 2006 10:32:13 -0700
Subject: [ python-Bugs-1417699 ] float/atof have become locale aware
Message-ID: <E1FbLCv-0000WH-6y@sc8-sf-web5.sourceforge.net>

Bugs item #1417699, was opened at 2006-01-29 01:04
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1417699&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: 7
Submitted By: Bernhard Herzog (bernhard)
Assigned to: Martin v. L??wis (loewis)
Summary: float/atof have become locale aware

Initial Comment:
The builtin float and the function string.atof have
become locale aware in Python 2.4:

Python 2.4.2 (#1, Nov 29 2005, 16:07:55) 
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import locale
>>> import string
>>> locale.setlocale(locale.LC_ALL, "de_DE")
'de_DE'
>>> float("1,5")
1.5
>>> string.atof("1,5")
1.5


This doesn't match what's specified in pep 331:

        - float() and str() stay locale-unaware.

It also doesn't match the documentation for atof:

  Convert a string to a floating point number.
  The string must have the standard syntax for a
  floating point literal in Python, optionally
  preceded by a sign ("+" or "-"). Note that this
  behaves identical to the built-in function float()
  when passed a string.

The documentation for float() doesn't state which
format is accepted by float(), though.

The reason for this behavior is ultimately, that
PyOS_ascii_strtod accepts the locale specific
convention in addition to the "C"-locale/python
convention, even though the comment in the code
preceding its definition states:

  This function behaves like the standard strtod() 
  function does in the C locale.




----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-17 12:19

Message:
Logged In: YES 
user_id=1188172

Martin, you checked in the patch which is mentioned in PEP
331. Is this correct behavior?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1417699&group_id=5470

From noreply at sourceforge.net  Wed May  3 19:39:50 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 03 May 2006 10:39:50 -0700
Subject: [ python-Bugs-1448042 ] Defining a class with __dict__ brakes
	attributes assignment
Message-ID: <E1FbLKI-0001Vd-7F@sc8-sf-web4-b.sourceforge.net>

Bugs item #1448042, was opened at 2006-03-11 22:49
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448042&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: Closed
>Resolution: Wont Fix
Priority: 6
Submitted By: Michal Kwiatkowski (rubyjoker)
Assigned to: Nobody/Anonymous (nobody)
Summary: Defining a class with __dict__ brakes attributes assignment

Initial Comment:
When defining a class with __dict__ attribute, its 
instances can't rebind their __dict__ attributes.

--------------------------------------------------

class C(object): __dict__ = {}

obj = C()
obj.a = object()

import gc
gc.get_referrers(obj.a) # => [{'a': <object object at 
0x811d5b0>}]

obj.__dict__ = {} # doesn't really bind new __dict__

vars(obj) # => {}
object.__getattribute__(obj, '__dict__') # => {}
object.__getattribute__(C, '__dict__') # => {..., but 
without "a"}
obj.a  # => <object object at 0x811d5b0> (no exception
!)

gc.get_referrers(obj.a) # => [{'a': <object object at 
0x811d5b0>, '__dict__': {}}]

--------------------------------------------------

Although neither class nor object has an attribute "a", 
it's still accessible. It's also not possible to rebind 
__dict__ in that object, as it gets inside real object 
attributes dictionary.

This behaviour has been tested on Python 2.2, 2.3 and 
2.4, but may as well affect earlier versions.

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-05-03 17:39

Message:
Logged In: YES 
user_id=849994

Okay, Armin Rigo and zseil convinced me that this is not a bug.

----------------------------------------------------------------------

Comment By: ?iga Seilnacht (zseil)
Date: 2006-03-19 13:50

Message:
Logged In: YES 
user_id=1326842

Maybe this shows that it is actually a feature?

>>> class C(object):
...     pass
...

'__dict__' is not a normal attribute, it's a descriptor
(a "getset_descriptor") generated by object's type.
You can get to this object if you try hard enough:

>>> C_dict_descriptor = C.__dict__['__dict__']
>>> type(C_dict_descriptor).__name__
'getset_descriptor'

This descriptor is automatically created for most of the
python classes (except for those, that have __slots__
without __dict__) by 'type' object.

Since 'type' is an instance of itself, it also has it:

>>> type_dict_descriptor = type.__dict__['__dict__']

And we can see, that it is responsible for creating
the C's __dict__ attribute:

>>> C.__dict__ == type_dict_descriptor.__get__(C, type)
True

As is normal for most of the special named attributes,
this one is looked up in object's type, not in its dict,
and it isn't a normal dict, but a dictproxy:

>>> type(C.__dict__).__name__
'dictproxy'

Now in your case, you create a class attribute '__dict__':

>>> class D(C):
...     __dict__ = {'a': 1}
...

Which basically does something like:

>>> name = 'E'
>>> bases = (C,)
>>> E_namespace = {
...     '__dict__': {'a': 1},
...     '__doc__': "set to None by type if not provided",
...     '__module__': "globals()['__name__'] if missing",
...     '__weakref__': "another descriptor",
... }
>>> E = type(name, bases, E_namespace)

The '__dict__' attribute of this class is still provided by
its type (type 'type'), and is basicaly just a dictproxy of
the E_namespace:

>>> type(E.__dict__).__name__
'dictproxy'
>>> E.__dict__ == E_namespace
True

What your class definition actually did, is it has
overwritten the __dict__ descriptor that would be
normaly created by type; compare:

>>> C.__dict__['__dict__']
<attribute '__dict__' of 'C' objects>
>>> E.__dict__['__dict__']
{'a': 1}

Now watch what happens if you create an instance of E class:
>>> e = E()
>>> e.__dict__
{'a': 1}
>>> e.a = 2
>>> e.__dict__
{'a': 1}

Basically, now the '__dict__' attribute is a normal
attribute, that behaves just as any other attribute,
while you have lost acces to the instance's inner dict:

>>> e.__dict__ = {}
>>> e.__dict__
{}
>>> e.a
2

If you inherit directly from object, which doesn't have
this descriptor:

>>> object.__dict__['__dict__']
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
KeyError: '__dict__'

there would be no way of accesing instance's dictinary.
But since we inherited from class C, we can stil acces it:

>>> C_dict_descriptor.__get__(e)
{'a': 2, '__dict__': {}}


----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-03-18 17:57

Message:
Logged In: YES 
user_id=849994

Reopening. This is a bug, confirmed by Alex Martelli.

----------------------------------------------------------------------

Comment By: Michal Kwiatkowski (rubyjoker)
Date: 2006-03-18 13:01

Message:
Logged In: YES 
user_id=1310227

To see an example of rebinding __dict__ usage, go to:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/
66531
It's Alex Martelli implementation of Borg design pattern.

If rebinding __dict__ is forbidden, it should be clearly 
noted in the documetation. Either way, it's a bug.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-03-18 08:29

Message:
Logged In: YES 
user_id=849994

Agreed with Terry.

----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2006-03-18 03:21

Message:
Logged In: YES 
user_id=593130

To me, this falls under the category of 'don't do that'.

http://docs.python.org/ref/id-classes.html
2.3.2 Reserved classes of identifiers 
__*__ 
System-defined names. These names are defined by the 
interpreter and its implementation ...

To me, this means to use them in the manner specified or 
you get what you get. 

http://docs.python.org/ref/types.html#l2h-120
defines the internal usage of '__dict__'.  There is, as 
far as I know, no specified usage for rebinding '__dict__'.

So unless someone has a better idea that won't slow down 
proper usage, I would close this as 'invalid' or 'wont 
fix'.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448042&group_id=5470

From noreply at sourceforge.net  Wed May  3 19:46:30 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 03 May 2006 10:46:30 -0700
Subject: [ python-Feature Requests-1476166 ] Add SeaMonkey to webbrowser.py
Message-ID: <E1FbLQk-0004bA-M9@sc8-sf-web6.sourceforge.net>

Feature Requests item #1476166, was opened at 2006-04-25 14:32
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1476166&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: Closed
Resolution: Accepted
Priority: 5
Submitted By: Oleg Broytmann (phd)
Assigned to: Georg Brandl (gbrandl)
Summary: Add SeaMonkey to webbrowser.py

Initial Comment:
Add SeaMonkey to webbrowser.py as yet another Mozilla
family browser. Just prepend "seamonkey" to the list
("mozilla-firefox", "firefox",                        
                                    "mozilla-firebird",
"firebird",                                           
        "mozilla", "netscape") in the
register_X_browsers().

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-05-03 17:46

Message:
Logged In: YES 
user_id=849994

Done in  r45889.

----------------------------------------------------------------------

Comment By: Oleg Broytmann (phd)
Date: 2006-05-03 09:26

Message:
Logged In: YES 
user_id=4799

Sorry, I should check webbrowser.py more careful. Please add
"seamonkey" after

if sys.platform[:3] == "win":
    ...

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-04-28 16:31

Message:
Logged In: YES 
user_id=849994

Added in rev. 45780.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1476166&group_id=5470

From noreply at sourceforge.net  Wed May  3 20:03:41 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 03 May 2006 11:03:41 -0700
Subject: [ python-Feature Requests-1472176 ] "idna" encoding (drawing
	unicodedata) necessary in httplib?
Message-ID: <E1FbLhN-0002CG-GB@sc8-sf-web3.sourceforge.net>

Feature Requests item #1472176, was opened at 2006-04-18 09:28
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1472176&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: Closed
>Resolution: Accepted
Priority: 5
Submitted By: kxroberto (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: "idna" encoding (drawing unicodedata) necessary in httplib?

Initial Comment:
httplib employs the "idna" encoding. that leads to
errors in py2exe/cxfreeze. And if forced into the
installer, it draws the 400kB+ unicodedata.pyd (on Win)
in innocent small apps. Otherwise no normal technical
modules draw the unicodedata.

Is that really necessary?



----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-05-03 18:03

Message:
Logged In: YES 
user_id=849994

Slightly reformatted version of patch applied in rev. 45890.

----------------------------------------------------------------------

Comment By: kxroberto (kxroberto)
Date: 2006-04-19 09:41

Message:
Logged In: YES 
user_id=972995

a patch attached

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2006-04-18 09:59

Message:
Logged In: YES 
user_id=38388

I agree - in most cases, ASCII will be used for hostnames
(where the idna encoding is being used in httplib). 

A little helper function to first try .encode('ascii') and
then revert to .encode('idna') would do wonders.

Patches are welcome !

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1472176&group_id=5470

From noreply at sourceforge.net  Wed May  3 20:13:24 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 03 May 2006 11:13:24 -0700
Subject: [ python-Bugs-1472191 ] pdb 'clear' command doesn't clear selected
	bp's
Message-ID: <E1FbLqm-0008M4-92@sc8-sf-web6.sourceforge.net>

Bugs item #1472191, was opened at 2006-04-18 09:49
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472191&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 6
Submitted By: Kuba Ko??czyk (jakamkon)
Assigned to: Nobody/Anonymous (nobody)
Summary: pdb 'clear' command doesn't clear selected bp's

Initial Comment:
 Pdb 'clear x' command doesn't clear selected breakpoints
that are already set:

$ ./python -m pdb ../test.py
> /home/xyz/python/test.py(3)<module>()
-> def t(x):
(Pdb) break 5
Breakpoint 1 at /home/xyz/python/test.py:5
(Pdb) break
Num Type Disp Enb Where
1 breakpoint keep yes at /home/xyz/python/test.py:5
(Pdb) clear 1
No breakpoint numbered 1
(Pdb)
...
for i in numberlist:
* if not (0 <= i < len(bdb.Breakpoint.bpbynumber)):
print 'No breakpoint numbered', i
...

Each i is a string and it's compared to 0 and len(...),
so condition * is always True.
The fix is trivial:
* if not (0 <= int(i) < len(bdb.Breakpoint.bpbynumber)):
Fix is in #1472184

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-05-03 18:13

Message:
Logged In: YES 
user_id=849994

Thanks for the report. This is fixed in rev. 45891, 45892(2.4).

Additionally, for such small changes please do not file a
bug and a patch report. Opening just one bug and attaching
the patch is fine.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472191&group_id=5470

From noreply at sourceforge.net  Wed May  3 20:19:34 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 03 May 2006 11:19:34 -0700
Subject: [ python-Bugs-1385040 ] compiler module does not detect a syntax error
Message-ID: <E1FbLwk-0002lY-J0@sc8-sf-web6.sourceforge.net>

Bugs item #1385040, was opened at 2005-12-19 09:58
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1385040&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Harri Pasanen (harripasanen)
Assigned to: Jeremy Hylton (jhylton)
Summary: compiler module does not detect a syntax error

Initial Comment:
import compiler 
compiler.parse("def foo(a=1,b): pass") 
 
Gives: 
 
Module(None, Stmt([Function(None, 'foo', ['a', 'b'], 
[Const(1)], 0, None, Stmt([Pass()]))])) 
 
However, the python interpreter itself barks for the 
same code: 
 
SyntaxError: non-default argument follows default 
argument 
 
 
-Harri 
 
 

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-05-03 18:19

Message:
Logged In: YES 
user_id=849994

Thanks for spotting the quirk.

Applied as rev. 45893. test_compiler passes fine here.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-05-01 07:21

Message:
Logged In: YES 
user_id=33168

Any reason you do:
  not i >= len(nodelist) 

instead of:
  i < len(nodelist)

?

The patch seems fine if everything passes with -u compiler
test_compiler.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-04-30 20:20

Message:
Logged In: YES 
user_id=849994

Attaching patch. Please review.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-02-25 21:59

Message:
Logged In: YES 
user_id=33168

FYI.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1385040&group_id=5470

From noreply at sourceforge.net  Wed May  3 20:19:49 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 03 May 2006 11:19:49 -0700
Subject: [ python-Bugs-1480678 ] mmap tries to truncate special files
Message-ID: <E1FbLwz-0001u2-DD@sc8-sf-web4-b.sourceforge.net>

Bugs item #1480678, was opened at 2006-05-02 16:56
Message generated for change (Comment added) made by aerojockey
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1480678&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: Carl Banks (aerojockey)
Assigned to: Nobody/Anonymous (nobody)
Summary: mmap tries to truncate special files

Initial Comment:
One Unix, the resize() method of an mmap object calls
ftruncate to also resize the associated file.  Problem
is, ftruncate fails if the fd refers to a special file.
 This is a problem for someone trying to resize an
anonymous memory map using /dev/zero.

Apparently hasn't been fixed in 2.5 (based on SVN and
changelogs) but I haven't tested it.

----------------------------------------------------------------------

>Comment By: Carl Banks (aerojockey)
Date: 2006-05-03 14:19

Message:
Logged In: YES 
user_id=1515186

Well, since resizing an anonymous array seems a reasonable
thing to do, and because it worked in Python 2.3, I presumed
that the error was an oversight, and not intended behavior.

If it is, in fact, intended behavior, then ok, though I
don't agree with it.  (It's not as if /dev/zero has fixed
size that doesn't change; it's inherently sizeless.)

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-05-03 02:13

Message:
Logged In: YES 
user_id=31435

Ya, this isn't a bug:  resize() is documented as changing
the size of _both_ the map and the file.  If the size of the
file can't be changed, then of course resize() will fail.

aerojockey:  can't you simply close your current map and
create a new map with the size you want?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-05-03 01:21

Message:
Logged In: YES 
user_id=33168

I don't understand what the problem is.  ISTM if you resize
a special file an exception will be raised.  Is that not the
case?  What do you expect to happen?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1480678&group_id=5470

From noreply at sourceforge.net  Wed May  3 20:39:08 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 03 May 2006 11:39:08 -0700
Subject: [ python-Bugs-1481296 ] long(float('nan'))!=0L
Message-ID: <E1FbMFg-0002oD-CJ@sc8-sf-web2.sourceforge.net>

Bugs item #1481296, was opened at 2006-05-03 13:39
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=1481296&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.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Erik Dahl (edahl)
Assigned to: Nobody/Anonymous (nobody)
Summary: long(float('nan'))!=0L

Initial Comment:
on all platforms I can test long(float('nan'))=0L

But on maxos X intel long(float('nan'))!=0L

it returns:

000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000L

This is a problem because:

>>> 344 - long(float('nan'))    
Objects/longobject.c:1645: failed assertion `borrow == 0'
Abort trap




----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1481296&group_id=5470

From noreply at sourceforge.net  Wed May  3 21:02:45 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 03 May 2006 12:02:45 -0700
Subject: [ python-Bugs-1480678 ] mmap tries to truncate special files
Message-ID: <E1FbMcX-0004o6-B2@sc8-sf-web2.sourceforge.net>

Bugs item #1480678, was opened at 2006-05-02 16:56
Message generated for change (Settings changed) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1480678&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: Not a Bug
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Carl Banks (aerojockey)
Assigned to: Nobody/Anonymous (nobody)
Summary: mmap tries to truncate special files

Initial Comment:
One Unix, the resize() method of an mmap object calls
ftruncate to also resize the associated file.  Problem
is, ftruncate fails if the fd refers to a special file.
 This is a problem for someone trying to resize an
anonymous memory map using /dev/zero.

Apparently hasn't been fixed in 2.5 (based on SVN and
changelogs) but I haven't tested it.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2006-05-03 15:02

Message:
Logged In: YES 
user_id=31435

I have to confess I don't know _why_ resize() changes the
size of the file too, and think that's a debatable design
decision.  But when code is working as intended and as
documented, by definition that's not "a bug".

The reason "it worked" in Python 2.3 is explained in bug 728515:

http://www.python.org/sf/728515

As it says there, it was a bug that resize() resized the
file on Windows, but neglected to do so on Unixish boxes at
the time.  That bug was fixed by making it resize the file
on Unixish boxes too.

Since the intent here is clear (albeit questionable) and
documented, I'm closing this as not-a-bug.

----------------------------------------------------------------------

Comment By: Carl Banks (aerojockey)
Date: 2006-05-03 14:19

Message:
Logged In: YES 
user_id=1515186

Well, since resizing an anonymous array seems a reasonable
thing to do, and because it worked in Python 2.3, I presumed
that the error was an oversight, and not intended behavior.

If it is, in fact, intended behavior, then ok, though I
don't agree with it.  (It's not as if /dev/zero has fixed
size that doesn't change; it's inherently sizeless.)

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-05-03 02:13

Message:
Logged In: YES 
user_id=31435

Ya, this isn't a bug:  resize() is documented as changing
the size of _both_ the map and the file.  If the size of the
file can't be changed, then of course resize() will fail.

aerojockey:  can't you simply close your current map and
create a new map with the size you want?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-05-03 01:21

Message:
Logged In: YES 
user_id=33168

I don't understand what the problem is.  ISTM if you resize
a special file an exception will be raised.  Is that not the
case?  What do you expect to happen?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1480678&group_id=5470

From noreply at sourceforge.net  Wed May  3 21:09:29 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 03 May 2006 12:09:29 -0700
Subject: [ python-Bugs-1481296 ] long(float('nan'))!=0L
Message-ID: <E1FbMj3-0005R6-4x@sc8-sf-web2.sourceforge.net>

Bugs item #1481296, was opened at 2006-05-03 14: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=1481296&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.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Erik Dahl (edahl)
Assigned to: Nobody/Anonymous (nobody)
Summary: long(float('nan'))!=0L

Initial Comment:
on all platforms I can test long(float('nan'))=0L

But on maxos X intel long(float('nan'))!=0L

it returns:

000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000L

This is a problem because:

>>> 344 - long(float('nan'))    
Objects/longobject.c:1645: failed assertion `borrow == 0'
Abort trap




----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2006-05-03 15:09

Message:
Logged In: YES 
user_id=31435

Try it on Windows and you'll get:

>>> long(float('nan'))
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ValueError: invalid literal for float(): nan

Nothing about the behavior of NaNs, infinities, or signed
zeroes is defined or guaranteed by Python.  You use them at
your own risk, and their behavior does vary wildly in
practice (according to the HW, OS, C compiler, C library,
and even the C compiler flags specified when compiling Python).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1481296&group_id=5470

From noreply at sourceforge.net  Wed May  3 22:16:33 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 03 May 2006 13:16:33 -0700
Subject: [ python-Bugs-1481347 ] parse_makefile doesn't handle $$  correctly
Message-ID: <E1FbNlx-0002mc-Vv@sc8-sf-web2.sourceforge.net>

Bugs item #1481347, was opened at 2006-05-03 21:16
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1481347&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: Han-Wen Nienhuys (hanwen)
Assigned to: Nobody/Anonymous (nobody)
Summary: parse_makefile doesn't handle $$  correctly

Initial Comment:
In Makefiles, a $$ should expand into a literal $ 
distutils.sysconfig doesn't deal with this.

>>> print open('a.make').read ()

FOO	= $${bar} bla bla

>>> sysconfig.parse_makefile ('a.make')
{'FOO': '$ bla bla', 'bar': ''}




----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1481347&group_id=5470

From noreply at sourceforge.net  Thu May  4 06:42:32 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 03 May 2006 21:42:32 -0700
Subject: [ python-Bugs-1417699 ] float/atof have become locale aware
Message-ID: <E1FbVfc-0007le-Nd@sc8-sf-web5.sourceforge.net>

Bugs item #1417699, was opened at 2006-01-29 02:04
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1417699&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: 7
Submitted By: Bernhard Herzog (bernhard)
Assigned to: Martin v. L??wis (loewis)
Summary: float/atof have become locale aware

Initial Comment:
The builtin float and the function string.atof have
become locale aware in Python 2.4:

Python 2.4.2 (#1, Nov 29 2005, 16:07:55) 
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import locale
>>> import string
>>> locale.setlocale(locale.LC_ALL, "de_DE")
'de_DE'
>>> float("1,5")
1.5
>>> string.atof("1,5")
1.5


This doesn't match what's specified in pep 331:

        - float() and str() stay locale-unaware.

It also doesn't match the documentation for atof:

  Convert a string to a floating point number.
  The string must have the standard syntax for a
  floating point literal in Python, optionally
  preceded by a sign ("+" or "-"). Note that this
  behaves identical to the built-in function float()
  when passed a string.

The documentation for float() doesn't state which
format is accepted by float(), though.

The reason for this behavior is ultimately, that
PyOS_ascii_strtod accepts the locale specific
convention in addition to the "C"-locale/python
convention, even though the comment in the code
preceding its definition states:

  This function behaves like the standard strtod() 
  function does in the C locale.




----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-05-04 06:42

Message:
Logged In: YES 
user_id=21627

It's a bug. As bernhard says, it originates from
PyOS_ascii_strtod accepting both forms, which in turn
happens because it just leaves the locale-specific decimal
point in the string, only replacing the . with the
locale-specific point. Then, the platform's strtod will
happily accept the locale-specific version. 

I'd like Gustavo Carneiro to comment.

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-17 13:19

Message:
Logged In: YES 
user_id=1188172

Martin, you checked in the patch which is mentioned in PEP
331. Is this correct behavior?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1417699&group_id=5470

From noreply at sourceforge.net  Thu May  4 08:18:14 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 03 May 2006 23:18:14 -0700
Subject: [ python-Bugs-1478529 ] size limit exceeded for read() from network
	drive
Message-ID: <E1FbXAE-00043d-CX@sc8-sf-web1.sourceforge.net>

Bugs item #1478529, was opened at 2006-04-28 12:46
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1478529&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: Windows
Group: 3rd Party
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: Mark Sheppard (markshep)
Assigned to: Nobody/Anonymous (nobody)
Summary: size limit exceeded for read() from network drive

Initial Comment:
If you've got a network share mounted as a local drive
then Windows has a limit of 67,076,095 (0x03ff7fff)
bytes for a read from an open file on that drive.

Running the python read() method on an open file larger
than this size throws an "IOError: [Errno 22] Invalid
argument" exception.

A fix would be for python to internally use multiple
reads so as to not exceed this limit.


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2006-05-04 02:18

Message:
Logged In: YES 
user_id=31435

markshep:  As you discovered, closing the report doesn't
stop you from following up.  It just reflects the reality
that I don't consider this to be a Python bug, and am
opposed to trying to worm around it inside Python.

Like many people who have just been burned by a platform
quirk, I think you're over-selling the severity of the
problem while ignoring the costs of worming around it. 
Adding piles of Windows-specific code to what's _currently_
a simple and uniform implementation is an ongoing
maintenance headache, not least because that code will stick
around long after the next version of Windows has removed
the cause for it.  In the meantime it complicates the code
with obscure platform-specific hacks, reducing the
reliability of the code because it also reduces the code's
clarity.  The code can't be sanely tested by Python's
standard test suite either (it apparently requires a Windows
network to provoke, and the test suite assumes no such
thing), and untested hack-code is a horrible idea over time.

While it's true that the docs allow for multiple reads under
the covers, it's talking about cases like file objects
returned by a popen() call or a socket makefile() call when
read() is passed a `size` argument, or when read() is called
with no `size` argument (so it's impossible to know in
advance how large a buffer may be needed to reach EOF).  The
entire reading code for an explicitly-sized read on a
genuine file is a single

    return fread(buf, 1, n, stream);

call today, and on all platforms.

It doesn't look like this can end with reading either:  MS
documents a similar problem with writing, and I expect you
want to see that hacked around too (or, if not, you're
pretty selective ;-)).  Pain spreads.

In return, what's the benefit?  The fact that it _is_ so
hard to find anything via Google about this strongly
suggests to me that trying to read more than 64MB in one
gulp across a vulnerable Windows combo is mighty rare.  If
it happens, the failure isn't silent, an explicit exception
is raised letting the programmer know it didn't work.  While
I appreciate that's irritating, it's not a disaster, and a
programmer who cares can worm around it on their own ("so
don't do that -- read < 64MB per gulp yourself").

Obviously, I'm not going to pursue this.  Since I'm one of
the few people who "does" Windows code for the core, that
does cut the chance that anyone will.  If you want to pursue
it, the best chance is to supply a patch implementing it,
and get someone else to review it.  A stronger case could be
made if, e.g., there was evidence that Perl or PHP or Ruby
or VB or C# or ... intend to worm (or have wormed) around it.

----------------------------------------------------------------------

Comment By: Mark Sheppard (markshep)
Date: 2006-05-03 06:38

Message:
Logged In: YES 
user_id=1512331

Thanks for closing this bug without giving me a chance to
follow up!

The problem isn't caused by a limitation of my machine -
it's got 3 GiB of RAM.

I've done some more testing on this and the problem only
appears when connected to a server running certain SMB
implementations:

  The local Windows XP machine
  A remote Windows XP machine
  Samba 3.0.22 on Linux

When connected to servers running the following SMB
implementations the problem isn't present:

  Windows NT 4.0 Server
  Windows Server 2000
  Windows Server 2003 Standard Edition

As this error is being returned by the underlying fread()
call the proper place for it to be fixed is there, but the
chances of Microsoft doing so for Windows XP are negligible.

As you're trying to provide a cross-platform language then
having to put up with OS's undocumented warts is just part
of the job.  As it's entirely possible for you to implement
a work-around for this problem Python I think you should. 
One of reasons for using a high level language like Python
is to be insulated from system quirks likes this.  If you're
refusing to smooth over these quirks where possible then
you're undermining that reason.

The documentation for Python's read() method on a file
handle already says "Note that this method may call the
underlying C function fread() more than once", so this
possibility is already catered for in the documentation.

As this problem only affects remotely mounted filesystems
the workaround need only be used for such filesystems.  You
can determine whether or not a drive is a network one by
using the GetDriveType() Windows call.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-05-02 21:45

Message:
Logged In: YES 
user_id=31435

Sorry, I'm closing this as "3rd Party, Won't Fix".  It's
certainly not Python's doing that Microsoft's stdio
implementation has peculiar undocumented warts (Python just
calls the platform C's fread() here), so at best this is a
request for enhancement rather than a Python bug.

If there is a bug here, it's Microsoft's bug, and then the
proper source for a fix is also Microsoft.  This is
especially true since the two people who have tried this
here don't see the same behavior -- we don't even know what
"the bug" is.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-05-02 15:00

Message:
Logged In: YES 
user_id=21627

I could reproduce the write problem on XPSP2; I get the
Win32 error ERROR_NO_SYSTEM_RESOURCES after fwrite returns
(from GetLastError).

I can't reproduce the fread problem, though: in Python,
f.read(90*2**20) just returns with a 90MiB string. So it
could be a limitation of your machine (e.g. it might not
have enough memory), or of the server machine. I'm hesitant
to add a work-around for that into Python if this isn't a
system limitation. Performing multiple reads is also bad:
what happens if the first read succeeds, and the second one
fails? It might be that the system *really* is out of resources.

----------------------------------------------------------------------

Comment By: Mark Sheppard (markshep)
Date: 2006-05-02 06:48

Message:
Logged In: YES 
user_id=1512331

I'm running Windows XP.  I've been unable to find any
documentation about this exact problem - only that fwrite
thing.  But my testing shows that it works if I do
file.read(67076095), but throws an exception with
file.read(67076096).

I'm not suggesting limiting all reads from Python.  All I'm
suggesting is that under the hood the Windows implementation
of Python's read() call actually uses multiple fread() (or
whatever) calls if more than 67076095 bytes need to be read.
 That's all.  No interface changes.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-04-30 12:23

Message:
Logged In: YES 
user_id=31435

Martin, here's an MS article seemingly related to this:

http://support.microsoft.com/default.aspx?scid=kb;en-us;899149

However, it's about writing to a file on a network drive,
not reading from it.  It says that opening the file in 'w+b'
mode, instead of 'wb' mode, is a workaround.

I couldn't find anything documenting the same kind of
problem for reading.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-30 06:10

Message:
Logged In: YES 
user_id=21627

What version of Windows are you using? Do you know of any
documentation of this limit? (without actually testing, I
find it hard to believe that this limit exists in Windows)

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-04-29 09:23

Message:
Logged In: YES 
user_id=849994

How can it be determined whether exactly this restriction
caused the "invalid argument" error? If it can't, there's
nothing that can be done -- restricting all reads just
because of a Windows limitation doesn't seem right.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1478529&group_id=5470

From noreply at sourceforge.net  Thu May  4 09:24:25 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 04 May 2006 00:24:25 -0700
Subject: [ python-Bugs-1481650 ] Docs on import of email.MIMExxx classes wrong
Message-ID: <E1FbYCH-0001bk-T4@sc8-sf-web5.sourceforge.net>

Bugs item #1481650, was opened at 2006-05-04 07:24
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=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: Open
Resolution: None
Priority: 5
Submitted By: Hugh Gibson (hgibson50)
Assigned to: Nobody/Anonymous (nobody)
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.

<snip>
    
IDLE 1.1.3      
>>> import email.MIMEImage.MIMEImage

Traceback (most recent call last):
  File "<pyshell#0>", 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

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1481650&group_id=5470

From noreply at sourceforge.net  Thu May  4 11:47:58 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 04 May 2006 02:47:58 -0700
Subject: [ python-Bugs-1417699 ] float/atof have become locale aware
Message-ID: <E1FbaRC-0003XA-ND@sc8-sf-web3.sourceforge.net>

Bugs item #1417699, was opened at 2006-01-29 01:04
Message generated for change (Comment added) made by gustavo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1417699&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: 7
Submitted By: Bernhard Herzog (bernhard)
Assigned to: Martin v. L??wis (loewis)
Summary: float/atof have become locale aware

Initial Comment:
The builtin float and the function string.atof have
become locale aware in Python 2.4:

Python 2.4.2 (#1, Nov 29 2005, 16:07:55) 
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import locale
>>> import string
>>> locale.setlocale(locale.LC_ALL, "de_DE")
'de_DE'
>>> float("1,5")
1.5
>>> string.atof("1,5")
1.5


This doesn't match what's specified in pep 331:

        - float() and str() stay locale-unaware.

It also doesn't match the documentation for atof:

  Convert a string to a floating point number.
  The string must have the standard syntax for a
  floating point literal in Python, optionally
  preceded by a sign ("+" or "-"). Note that this
  behaves identical to the built-in function float()
  when passed a string.

The documentation for float() doesn't state which
format is accepted by float(), though.

The reason for this behavior is ultimately, that
PyOS_ascii_strtod accepts the locale specific
convention in addition to the "C"-locale/python
convention, even though the comment in the code
preceding its definition states:

  This function behaves like the standard strtod() 
  function does in the C locale.




----------------------------------------------------------------------

Comment By: Gustavo J. A. M. Carneiro (gustavo)
Date: 2006-05-04 10:47

Message:
Logged In: YES 
user_id=908

My comment is, is "PyOS_ascii_strtod accepting both forms"
something that is harmful and should be fixed?

I didn't exactly write the PyOS_ascii_strtod code; I only
integrated it with Python.  But if we really need to fix
this, I'll try to figure out how to make it not accept
floating points in locale aware format; if necessary I'll
ask help from  the original author of the code, Alexander
Larsson.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-05-04 05:42

Message:
Logged In: YES 
user_id=21627

It's a bug. As bernhard says, it originates from
PyOS_ascii_strtod accepting both forms, which in turn
happens because it just leaves the locale-specific decimal
point in the string, only replacing the . with the
locale-specific point. Then, the platform's strtod will
happily accept the locale-specific version. 

I'd like Gustavo Carneiro to comment.

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-17 12:19

Message:
Logged In: YES 
user_id=1188172

Martin, you checked in the patch which is mentioned in PEP
331. Is this correct behavior?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1417699&group_id=5470

From noreply at sourceforge.net  Thu May  4 13:28:12 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 04 May 2006 04:28:12 -0700
Subject: [ python-Bugs-1481650 ] Docs on import of email.MIMExxx classes wrong
Message-ID: <E1Fbc0C-0006wR-LI@sc8-sf-web4-b.sourceforge.net>

Bugs item #1481650, was opened at 2006-05-04 03:24
Message generated for change (Settings changed) 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: Open
Resolution: None
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.

<snip>
    
IDLE 1.1.3      
>>> import email.MIMEImage.MIMEImage

Traceback (most recent call last):
  File "<pyshell#0>", 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

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1481650&group_id=5470

From noreply at sourceforge.net  Thu May  4 13:43:43 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 04 May 2006 04:43:43 -0700
Subject: [ python-Bugs-1481770 ] hpux ia64 shared lib ext should be ".so"
Message-ID: <E1FbcFD-0004ti-Dw@sc8-sf-web4-b.sourceforge.net>

Bugs item #1481770, was opened at 2006-05-04 05:43
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=1481770&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: David Everly (deckrider)
Assigned to: Nobody/Anonymous (nobody)
Summary: hpux ia64 shared lib ext should be ".so"

Initial Comment:
On hpux ia64, the shared library extension should be
".so".  This is currently problematic in that other
add-on python modules (such as those for subversion)
correctly detect the host_os/host_cpu and build
_module.so, which is not seen by python built using ".sl".

According to
http://devresource.hp.com/drc/resources/portguideipf/index.jsp#dynlinkfac


"Shared library names

Since dynamic linking APIs operate on shared libraries,
it is also important to note that the shared library
naming scheme on Linux is lib*.so; whereas, on HP-UX
11i Version 1.5 the naming scheme is lib*.sl for PA and
lib*.so on IPF. Also APIs may reside in different
libraries files on Linux and HP-UX, so you may need to
dynamically load a different shared library name on
HP-UX and Linux."

To translate this quote, PA=hppa and IPF=ia64.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1481770&group_id=5470

From noreply at sourceforge.net  Thu May  4 17:19:20 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 04 May 2006 08:19:20 -0700
Subject: [ python-Feature Requests-1110010 ] 'attrmap' function,
	attrmap(x)['attname'] == x.attname
Message-ID: <E1Fbfbs-0003bO-Cv@sc8-sf-web2.sourceforge.net>

Feature Requests item #1110010, was opened at 2005-01-26 11:28
Message generated for change (Comment added) made by gregsmith
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1110010&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: Gregory Smith (gregsmith)
Assigned to: Nobody/Anonymous (nobody)
Summary: 'attrmap' function, attrmap(x)['attname'] == x.attname

Initial Comment:
One of the side effects of the new-style classes is that
objects don't necessarily have __dict__ attached to them.
It used to be possible to write things like

   def __str__(self):
          return "Node %(name)s, %(nlinks)d links,
active: %(active)s" % self.__dict__


... but this doesn't work if the class doesn't have a
__dict__. Even if does, I'm not sure it will always get
members from base classes.

There is a 'vars' function; you could put 'vars(self)'
in the above instead of self.__dict__, but it still
doesn't work if
the class doesn't have a __dict__.

I can see different solutions for this:

(1) change the 'string %' operator so that it allows
 %(.name)s, leading to a getattr() on the right-side
argument
  rather than a getitem. 

          return "Node %(.name)s, %(.nlinks)d links,
active: %(.active)s" % self

(2) Make a builtin like vars, but which works when the
object doesn't have a __dict__ I.e. attrmap(x) would
return a mapping which is bound to x, and reading
attrmap(x)['attname'] is the same as
getattr(x,'attname'). Thus

          return "Node %(name)s, %(nlinks)d links,
active: %(active)s" % attrmap(self)


This attrmap() function can be implemented in pure
python, of course.

I originally thought (1) made a lot of sense, but (2) seems
to work just as well and doesn't require changing much.
Also, (1) allows  cases like "%(name)s %(.name2)s",
which are not very useful, but are very likely to be
created by
accident; whereas in (2) you are deciding on the right
of the '%' whether you are naming attributes or
providing mapping keys. 

I'm not sure it's a good idea change 'vars' to have
this behaviour, since vars(x).keys() currently works in
a predictable way when vars(x) works; whereas
attrmap(x).keys() may not be complete, or possible, 
even when attrmap(x) is useful. I.e. when x has a
__getattr__ defined.
On the other hand, vars(x) doesn't currently do much at
all, so maybe it's possible to enhance it like this
without breaking anything.

The motivation for this came from the "%(name)s" issue,
but the attrmap() function would be useful in other
places e.g.

processdata( infile,  outfile, **attrmap(options))

... where options might be obtained from optparse, e.g.
  
Or, an attrmap can be used with the new Templates:
string.Template('Node $name').substitute( attrmap(node))

Both of these examples will work with vars(), but only
when the object actually has __dict__. This is why
I'm thinking it may make sense to enhance vars: some
code may be broken by the change; but other code,
broken by new-style classes, may be unbroken by this
change.

The proxy could be writable, so that
    attrmap(x)['a'] = y
is the same as
     x.a = y
.. which could have more uses.

A possible useful (possibly weird) variation: attrmap
accepts 1 or more parameters, and the resulting
proxy is bound to all of them. when attrmap(x,y,z)['a']
is done, the proxy will try x.a, y.a, z.a until one of
them doesn't raise AttributeError. So it's equivalent
to merging dictionaries. This would be useful
in the %(name)s or Template cases, where you want
information from several objects.





----------------------------------------------------------------------

>Comment By: Gregory Smith (gregsmith)
Date: 2006-05-04 11:19

Message:
Logged In: YES 
user_id=292741

Josiah, I'm well aware of that, but as I said 10/26 I don't
want to add attribute mapping to a whole set of classes just
so they will all work a certain way in one specific
situation; I want a separate adapter so I can have attribute
mapping for ANY object in that specific situation. I can't
mixin a new base class into every class I might encounter,
since most of them are not under my control; but all of them
have an attribute interface and will all work with attrmap.
There's no reason to mess things up like that when
I can implement attrmap already (and have done) -- and you
have shown how short the code is on your 6/26/'05 post --
I'm just suggesting this is simple, elegant, and generally
useful enough to be included as a standard python gizmo.



----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2005-10-27 02:16

Message:
Logged In: YES 
user_id=341410

gregsmith:

class attrmap:
    def __getitem__(self, key):
        return getattr(self, key)

Use that as a mixin with any class you want to offer
attribute mapping support to.  As in...

class foo(..., attrmap):
    ...

Now your class has attribute mapping support.  Amazing!

As for the neatness of __dict__, I have used it before, but
when I need to rely on using __dict__, I make sure my object
has one (generally by not creating or using __slots__).

----------------------------------------------------------------------

Comment By: Gregory Smith (gregsmith)
Date: 2005-10-26 14:14

Message:
Logged In: YES 
user_id=292741


To josiahcarlson: Yes, I can add __getitem__ to any class.
But I don't see why I should make a whole bunch of classes
act like dictionaries,  only so that I can pass them to
single API (like string.Template) which requires a
dictionary. A class should have a dictionary behaviour if it
makes sense for that class; if I have to add it
specifically, and only, to make it work well in one
particular situation, that's a kluge. If I have to add dict
behaviour to a whole bunch of classes to make them all work
in that one situation, that's a serious kluge. And entirely
unintuitive, to borrow a phrase. When you encounter this
situation, IMO, it's clear that a little 'pipe-fitting' like
this is the best solution.

Furthermore, and to underline the above, what if I have a
class which already has a __getitem__ interface for it's own
purposes? Chances are this behaves in a way which makes it
useless for harvesting general attributes from the object;
the object always has  a getattr interface, however.

Since ALL objects have a getattr interface, and  there's a
fair number of APIs that require objects with a read-only,
string-keyed dict interface, why not have this universal
pipe-fitting to tie them together, so as not to have to
modify the objects and/or interfaces.

To rhettinger:
First off, what do you mean by 'use case'? I gave three
examples of the use of the function, with %attrmap(x),
string.Template(...).substitute(attrmap(x));
attrmap(options).
 I can expand these to more detail if you like. I didn't
give use examples for the 'write' case; I haven't
encountered a use for that.

Yes, you have to think a bit before you see what it's for.
That's arguably true for super(), slice() and
operator.attrgetter() as well. Once you've run into the
situation where it's useful, it becomes pretty clear what
it's for.  Given the general problem it solves, it's hard to
imagine a neater and more intuitive solution IMO.

Here's a 2-line sales pitch, which was implied, but not
given, in the original post:


  def __str__(self):
     return "MyObj(name=%(name)s, n=%(n)d, links = %(links)d
)" % attrmap(self)

vs. the harder-to-maintain

     return "MyObj( name=%s, n=%d, links = %d )" %
(self.name, self.n, self.links)

...this requires the programmer to maintain the same list of
symbols twice, a burden which is very common in languages
inferior to Python.

And obviously it's very simple (the base functionality is 5
lines). Like attrgetter, It becomes more useful when it's
always available in the standard lib, and a little faster if
it happens to be in C.

to loewis:
   fair enough, maybe it doesn't qualify for a builtin. But
it might make more sense to do it as operator.attrmap rather
than UserDict.AttrMap; it seems to fit into the same
category as attrgettr and itemgetter. I wasn't aware of
those two when I originally posted.

And am I the only one who thinks the first example I gave
(with __str__ using "..."%self.__dict__) is a pretty neat
trick? And who has noticed it's been broken  with new-style
classes? That by itself, IMO, calls for a fix, and replacing
self.__dict__ with attrmap(self) is a pretty simple fix.




----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-06-27 00:18

Message:
Logged In: YES 
user_id=80475

-1

While potentially useful, the function is entirely unintuitive (it has 
to be studied a bit before being able to see what it is for).  Also, 
the OP is short on use cases (none were presented).  IMO, this 
belongs as a cookbook recipe.

----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2005-06-26 13:47

Message:
Logged In: YES 
user_id=341410

An implementation of the base attrmap functionality (as
suggested by Reinhold in his post in python-dev)...

class attrmap:
    def __init__(self, obj):
        self.obj = obj
    def __getitem__(self, key):
        return getattr(self.obj, key)

To Gregory Smith:  If you merely add the __getitem__ method
with a 'self' as the first argument of getattr, you don't
even need attrmap.

As an aside, when I want dictionary-like behavior from my
classes, I use a dictionary or something that implements a
subset of the mapping protocol.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2005-02-11 19:51

Message:
Logged In: YES 
user_id=21627

I think I would rather not to see this as a builtin, e.g.
putting it into UserDict.AttrMap instead.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1110010&group_id=5470

From noreply at sourceforge.net  Thu May  4 22:48:32 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 04 May 2006 13:48:32 -0700
Subject: [ python-Bugs-1482122 ] Shift+Backspace exhibits odd behavior
Message-ID: <E1FbkkS-00048O-7C@sc8-sf-web1.sourceforge.net>

Bugs item #1482122, was opened at 2006-05-04 13:48
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=1482122&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: None
Status: Open
Resolution: None
Priority: 5
Submitted By: NothingCanFulfill (ncf)
Assigned to: Nobody/Anonymous (nobody)
Summary: Shift+Backspace exhibits odd behavior

Initial Comment:
On Windows, pressing Shift+Backspace while in an editor
window will act just like a regular Backspace will,
however under Linux (Gentoo 2006.0 and
Slackware-current), instead of deleting the caracter
before the cursor, it inserts "^B".

Correct me if I'm wrong, but I don't think it'd be too
hard to fix this little annoyance.

(I would do it myself, but I'm not at all familiar with
IDLE's source layout)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1482122&group_id=5470

From noreply at sourceforge.net  Fri May  5 08:28:03 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 04 May 2006 23:28:03 -0700
Subject: [ python-Feature Requests-1110010 ] 'attrmap' function,
	attrmap(x)['attname'] == x.attname
Message-ID: <E1FbtnH-0005tL-TG@sc8-sf-web2.sourceforge.net>

Feature Requests item #1110010, was opened at 2005-01-26 08:28
Message generated for change (Comment added) made by josiahcarlson
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1110010&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: Gregory Smith (gregsmith)
Assigned to: Nobody/Anonymous (nobody)
Summary: 'attrmap' function, attrmap(x)['attname'] == x.attname

Initial Comment:
One of the side effects of the new-style classes is that
objects don't necessarily have __dict__ attached to them.
It used to be possible to write things like

   def __str__(self):
          return "Node %(name)s, %(nlinks)d links,
active: %(active)s" % self.__dict__


... but this doesn't work if the class doesn't have a
__dict__. Even if does, I'm not sure it will always get
members from base classes.

There is a 'vars' function; you could put 'vars(self)'
in the above instead of self.__dict__, but it still
doesn't work if
the class doesn't have a __dict__.

I can see different solutions for this:

(1) change the 'string %' operator so that it allows
 %(.name)s, leading to a getattr() on the right-side
argument
  rather than a getitem. 

          return "Node %(.name)s, %(.nlinks)d links,
active: %(.active)s" % self

(2) Make a builtin like vars, but which works when the
object doesn't have a __dict__ I.e. attrmap(x) would
return a mapping which is bound to x, and reading
attrmap(x)['attname'] is the same as
getattr(x,'attname'). Thus

          return "Node %(name)s, %(nlinks)d links,
active: %(active)s" % attrmap(self)


This attrmap() function can be implemented in pure
python, of course.

I originally thought (1) made a lot of sense, but (2) seems
to work just as well and doesn't require changing much.
Also, (1) allows  cases like "%(name)s %(.name2)s",
which are not very useful, but are very likely to be
created by
accident; whereas in (2) you are deciding on the right
of the '%' whether you are naming attributes or
providing mapping keys. 

I'm not sure it's a good idea change 'vars' to have
this behaviour, since vars(x).keys() currently works in
a predictable way when vars(x) works; whereas
attrmap(x).keys() may not be complete, or possible, 
even when attrmap(x) is useful. I.e. when x has a
__getattr__ defined.
On the other hand, vars(x) doesn't currently do much at
all, so maybe it's possible to enhance it like this
without breaking anything.

The motivation for this came from the "%(name)s" issue,
but the attrmap() function would be useful in other
places e.g.

processdata( infile,  outfile, **attrmap(options))

... where options might be obtained from optparse, e.g.
  
Or, an attrmap can be used with the new Templates:
string.Template('Node $name').substitute( attrmap(node))

Both of these examples will work with vars(), but only
when the object actually has __dict__. This is why
I'm thinking it may make sense to enhance vars: some
code may be broken by the change; but other code,
broken by new-style classes, may be unbroken by this
change.

The proxy could be writable, so that
    attrmap(x)['a'] = y
is the same as
     x.a = y
.. which could have more uses.

A possible useful (possibly weird) variation: attrmap
accepts 1 or more parameters, and the resulting
proxy is bound to all of them. when attrmap(x,y,z)['a']
is done, the proxy will try x.a, y.a, z.a until one of
them doesn't raise AttributeError. So it's equivalent
to merging dictionaries. This would be useful
in the %(name)s or Template cases, where you want
information from several objects.





----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-05-04 23:28

Message:
Logged In: YES 
user_id=341410

As I and others have expressed perhaps hundreds of times
over the last few years; not all X line functions/classes
should be built into Python.  This particular object doesn't
have enough general usefulness to make it into Python as a
builtin, so you would need to import something anyways.

If you are going to need to import to get at it, you may as
well put this somewhere, and perhaps monkey-patch
__builtins__ yourself so that you can get at it everywhere
without importing it.  Heck, you could even put it into
site.py .

If this were going to make it into Python, I would suggest
it go into the operator module, where a similar feature
already exists in the operator.attrgetter.  If there is also
desire, one may want to offer mapattr class which does
x.attr -> x['attr'] .

All in all, I'm -0; it would be useful, but I believe most
people would just write the 5-liner and call it good.

----------------------------------------------------------------------

Comment By: Gregory Smith (gregsmith)
Date: 2006-05-04 08:19

Message:
Logged In: YES 
user_id=292741

Josiah, I'm well aware of that, but as I said 10/26 I don't
want to add attribute mapping to a whole set of classes just
so they will all work a certain way in one specific
situation; I want a separate adapter so I can have attribute
mapping for ANY object in that specific situation. I can't
mixin a new base class into every class I might encounter,
since most of them are not under my control; but all of them
have an attribute interface and will all work with attrmap.
There's no reason to mess things up like that when
I can implement attrmap already (and have done) -- and you
have shown how short the code is on your 6/26/'05 post --
I'm just suggesting this is simple, elegant, and generally
useful enough to be included as a standard python gizmo.



----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2005-10-26 23:16

Message:
Logged In: YES 
user_id=341410

gregsmith:

class attrmap:
    def __getitem__(self, key):
        return getattr(self, key)

Use that as a mixin with any class you want to offer
attribute mapping support to.  As in...

class foo(..., attrmap):
    ...

Now your class has attribute mapping support.  Amazing!

As for the neatness of __dict__, I have used it before, but
when I need to rely on using __dict__, I make sure my object
has one (generally by not creating or using __slots__).

----------------------------------------------------------------------

Comment By: Gregory Smith (gregsmith)
Date: 2005-10-26 11:14

Message:
Logged In: YES 
user_id=292741


To josiahcarlson: Yes, I can add __getitem__ to any class.
But I don't see why I should make a whole bunch of classes
act like dictionaries,  only so that I can pass them to
single API (like string.Template) which requires a
dictionary. A class should have a dictionary behaviour if it
makes sense for that class; if I have to add it
specifically, and only, to make it work well in one
particular situation, that's a kluge. If I have to add dict
behaviour to a whole bunch of classes to make them all work
in that one situation, that's a serious kluge. And entirely
unintuitive, to borrow a phrase. When you encounter this
situation, IMO, it's clear that a little 'pipe-fitting' like
this is the best solution.

Furthermore, and to underline the above, what if I have a
class which already has a __getitem__ interface for it's own
purposes? Chances are this behaves in a way which makes it
useless for harvesting general attributes from the object;
the object always has  a getattr interface, however.

Since ALL objects have a getattr interface, and  there's a
fair number of APIs that require objects with a read-only,
string-keyed dict interface, why not have this universal
pipe-fitting to tie them together, so as not to have to
modify the objects and/or interfaces.

To rhettinger:
First off, what do you mean by 'use case'? I gave three
examples of the use of the function, with %attrmap(x),
string.Template(...).substitute(attrmap(x));
attrmap(options).
 I can expand these to more detail if you like. I didn't
give use examples for the 'write' case; I haven't
encountered a use for that.

Yes, you have to think a bit before you see what it's for.
That's arguably true for super(), slice() and
operator.attrgetter() as well. Once you've run into the
situation where it's useful, it becomes pretty clear what
it's for.  Given the general problem it solves, it's hard to
imagine a neater and more intuitive solution IMO.

Here's a 2-line sales pitch, which was implied, but not
given, in the original post:


  def __str__(self):
     return "MyObj(name=%(name)s, n=%(n)d, links = %(links)d
)" % attrmap(self)

vs. the harder-to-maintain

     return "MyObj( name=%s, n=%d, links = %d )" %
(self.name, self.n, self.links)

...this requires the programmer to maintain the same list of
symbols twice, a burden which is very common in languages
inferior to Python.

And obviously it's very simple (the base functionality is 5
lines). Like attrgetter, It becomes more useful when it's
always available in the standard lib, and a little faster if
it happens to be in C.

to loewis:
   fair enough, maybe it doesn't qualify for a builtin. But
it might make more sense to do it as operator.attrmap rather
than UserDict.AttrMap; it seems to fit into the same
category as attrgettr and itemgetter. I wasn't aware of
those two when I originally posted.

And am I the only one who thinks the first example I gave
(with __str__ using "..."%self.__dict__) is a pretty neat
trick? And who has noticed it's been broken  with new-style
classes? That by itself, IMO, calls for a fix, and replacing
self.__dict__ with attrmap(self) is a pretty simple fix.




----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-06-26 21:18

Message:
Logged In: YES 
user_id=80475

-1

While potentially useful, the function is entirely unintuitive (it has 
to be studied a bit before being able to see what it is for).  Also, 
the OP is short on use cases (none were presented).  IMO, this 
belongs as a cookbook recipe.

----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2005-06-26 10:47

Message:
Logged In: YES 
user_id=341410

An implementation of the base attrmap functionality (as
suggested by Reinhold in his post in python-dev)...

class attrmap:
    def __init__(self, obj):
        self.obj = obj
    def __getitem__(self, key):
        return getattr(self.obj, key)

To Gregory Smith:  If you merely add the __getitem__ method
with a 'self' as the first argument of getattr, you don't
even need attrmap.

As an aside, when I want dictionary-like behavior from my
classes, I use a dictionary or something that implements a
subset of the mapping protocol.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2005-02-11 16:51

Message:
Logged In: YES 
user_id=21627

I think I would rather not to see this as a builtin, e.g.
putting it into UserDict.AttrMap instead.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1110010&group_id=5470

From noreply at sourceforge.net  Fri May  5 09:02:16 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 05 May 2006 00:02:16 -0700
Subject: [ python-Bugs-1481770 ] hpux ia64 shared lib ext should be ".so"
Message-ID: <E1FbuKO-0002h8-11@sc8-sf-web4-b.sourceforge.net>

Bugs item #1481770, was opened at 2006-05-04 04:43
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1481770&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: David Everly (deckrider)
Assigned to: Nobody/Anonymous (nobody)
Summary: hpux ia64 shared lib ext should be ".so"

Initial Comment:
On hpux ia64, the shared library extension should be
".so".  This is currently problematic in that other
add-on python modules (such as those for subversion)
correctly detect the host_os/host_cpu and build
_module.so, which is not seen by python built using ".sl".

According to
http://devresource.hp.com/drc/resources/portguideipf/index.jsp#dynlinkfac


"Shared library names

Since dynamic linking APIs operate on shared libraries,
it is also important to note that the shared library
naming scheme on Linux is lib*.so; whereas, on HP-UX
11i Version 1.5 the naming scheme is lib*.sl for PA and
lib*.so on IPF. Also APIs may reside in different
libraries files on Linux and HP-UX, so you may need to
dynamically load a different shared library name on
HP-UX and Linux."

To translate this quote, PA=hppa and IPF=ia64.


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-05-05 00:02

Message:
Logged In: YES 
user_id=33168

Do you think you could work on a patch to address this issue?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1481770&group_id=5470

From noreply at sourceforge.net  Fri May  5 09:03:24 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 05 May 2006 00:03:24 -0700
Subject: [ python-Bugs-1482122 ] Shift+Backspace exhibits odd behavior
Message-ID: <E1FbuLU-0005D8-MU@sc8-sf-web2.sourceforge.net>

Bugs item #1482122, was opened at 2006-05-04 13:48
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1482122&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: None
Status: Open
Resolution: None
Priority: 5
Submitted By: NothingCanFulfill (ncf)
>Assigned to: Kurt B. Kaiser (kbk)
Summary: Shift+Backspace exhibits odd behavior

Initial Comment:
On Windows, pressing Shift+Backspace while in an editor
window will act just like a regular Backspace will,
however under Linux (Gentoo 2006.0 and
Slackware-current), instead of deleting the caracter
before the cursor, it inserts "^B".

Correct me if I'm wrong, but I don't think it'd be too
hard to fix this little annoyance.

(I would do it myself, but I'm not at all familiar with
IDLE's source layout)

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-05-05 00:03

Message:
Logged In: YES 
user_id=33168

Right now there aren't a lot of IDLE developers.  It would
be great if you could work on a patch.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1482122&group_id=5470

From noreply at sourceforge.net  Fri May  5 11:22:38 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 05 May 2006 02:22:38 -0700
Subject: [ python-Bugs-1482328 ] socket.getsockopt bug
Message-ID: <E1FbwWE-0000BI-U0@sc8-sf-web3.sourceforge.net>

Bugs item #1482328, was opened at 2006-05-05 12:22
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=1482328&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: ganges master (gangesmaster)
Assigned to: Nobody/Anonymous (nobody)
Summary: socket.getsockopt bug

Initial Comment:
i tested this on windows xp. the installed python
version is the 2.4.3 from the windows MSI.

when doing socket.getsockopt with buffer_size > 0, for
options like SO_LINGER or SO_SNDTIMEO, i get only 4 bytes. 
although the man pages state these options hold 8
bytes. is this a bug in the pythonic version of
getsockopt or winsock?

-tomer

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1482328&group_id=5470

From noreply at sourceforge.net  Fri May  5 13:15:21 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 05 May 2006 04:15:21 -0700
Subject: [ python-Bugs-1482402 ] Forwarding events and Tk.mainloop problem
Message-ID: <E1FbyHJ-0006y1-17@sc8-sf-web5.sourceforge.net>

Bugs item #1482402, was opened at 2006-05-05 11:15
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=1482402&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: Tkinter
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Kievernagel (mkiever)
Assigned to: Martin v. L??wis (loewis)
Summary: Forwarding events and Tk.mainloop problem

Initial Comment:
(Python 2.4.1, tcl/tk 8.4 on Linux)

I try to create a widget class (Frame2 in the example)
containing a Listbox.
This should report an event '<<ElementSelect>>'
when the Listbox produces '<<ListboxSelect>>'
or when the selection changes using the Up/Down keys.
(see example script)

Binding '<<ElementSelect>>' to the Frame2 widget
produces the following traceback when the
event is generated:

------------------
listbox select
event generated
Traceback (most recent call last):
  File "testevent.py", line 98, in ?
    tk.mainloop ()
  File "/usr/local/lib/python2.4/lib-tk/Tkinter.py", 
line 965, in mainloop
    self.tk.mainloop(n)
  File "/usr/local/lib/python2.4/lib-tk/Tkinter.py", 
line 1349, in __call__
    self.widget._report_exception()
  File "/usr/local/lib/python2.4/lib-tk/Tkinter.py", 
line 1112, in _report_exception
    root = self._root()
AttributeError: Tk instance has no __call__ method
-----------------

So Tkinter tries to report an exception
caused by the event, but fails to do so
by a second exception in _report_exception.
(not quite sure I did understand this)
The first exception may be a problem with
my code or tcl/tk but at least the second
is a problem of Tkinter.

If you bind '<<ElementSelect>>' to Tk itself
the example works fine.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1482402&group_id=5470

From noreply at sourceforge.net  Fri May  5 14:07:05 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 05 May 2006 05:07:05 -0700
Subject: [ python-Bugs-1481770 ] hpux ia64 shared lib ext should be ".so"
Message-ID: <E1Fbz5N-0006VC-0Q@sc8-sf-web4-b.sourceforge.net>

Bugs item #1481770, was opened at 2006-05-04 05:43
Message generated for change (Comment added) made by deckrider
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1481770&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: David Everly (deckrider)
Assigned to: Nobody/Anonymous (nobody)
Summary: hpux ia64 shared lib ext should be ".so"

Initial Comment:
On hpux ia64, the shared library extension should be
".so".  This is currently problematic in that other
add-on python modules (such as those for subversion)
correctly detect the host_os/host_cpu and build
_module.so, which is not seen by python built using ".sl".

According to
http://devresource.hp.com/drc/resources/portguideipf/index.jsp#dynlinkfac


"Shared library names

Since dynamic linking APIs operate on shared libraries,
it is also important to note that the shared library
naming scheme on Linux is lib*.so; whereas, on HP-UX
11i Version 1.5 the naming scheme is lib*.sl for PA and
lib*.so on IPF. Also APIs may reside in different
libraries files on Linux and HP-UX, so you may need to
dynamically load a different shared library name on
HP-UX and Linux."

To translate this quote, PA=hppa and IPF=ia64.


----------------------------------------------------------------------

>Comment By: David Everly (deckrider)
Date: 2006-05-05 06:07

Message:
Logged In: YES 
user_id=1113403

The patch I'm using now only works on hppa/ia64 and isn't
anything that can coexist nicely in the source package on
other hardware/os combinations.

I've looked at
http://svn.python.org/projects/python/branches/release24-maint/

I'm accustomed to a system using autoconf/libtool/automake
(recent versions) and never committing the output of those
tools, but only running them at source package generation time.

I say this, only to point out that I'm not understanding the
principles behind what I see in subversion.  I see
configure, and also configure.in.  Which should be patched?
 And if I don't patch configure, what is the process for
regenerating it (and with what versions of automake,
autoconf, and libtool?).

Also, the most recent libtool already correctly determines
shared library extension.

So I could probably provide a patch, but would need to
understand the environment better in order to do so.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-05-05 01:02

Message:
Logged In: YES 
user_id=33168

Do you think you could work on a patch to address this issue?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1481770&group_id=5470

From noreply at sourceforge.net  Fri May  5 15:12:47 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 05 May 2006 06:12:47 -0700
Subject: [ python-Bugs-1482328 ] socket.getsockopt bug
Message-ID: <E1Fc06x-00014m-9O@sc8-sf-web3.sourceforge.net>

Bugs item #1482328, was opened at 2006-05-05 09:22
Message generated for change (Comment added) made by splitscreen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1482328&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: ganges master (gangesmaster)
Assigned to: Nobody/Anonymous (nobody)
Summary: socket.getsockopt bug

Initial Comment:
i tested this on windows xp. the installed python
version is the 2.4.3 from the windows MSI.

when doing socket.getsockopt with buffer_size > 0, for
options like SO_LINGER or SO_SNDTIMEO, i get only 4 bytes. 
although the man pages state these options hold 8
bytes. is this a bug in the pythonic version of
getsockopt or winsock?

-tomer

----------------------------------------------------------------------

Comment By: Matt Fleming (splitscreen)
Date: 2006-05-05 13:12

Message:
Logged In: YES 
user_id=1126061

According to http://www.sockets.com/winsock.htm#GetSockOpt

"The integer pointed to by optlen should originally contain
the size of this buffer; on return, it will be set to the
size of the value returned. For SO_LINGER, this will be the
size of a struct linger; for all other options it will be
the size of an integer." 

The size of a linger struct is 4 bytes. 

I would agree that the Python documentation for
socket.getsockopt is a little confusing.

"Get a socket option.  See the Unix manual for level and
option. If a nonzero buffersize argument is given, the
return value is a string of that length; otherwise it is an
integer."

Perhaps just refer users to the OSes documentation on its
implementation of sockets?

Matt


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1482328&group_id=5470

From noreply at sourceforge.net  Fri May  5 15:43:05 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 05 May 2006 06:43:05 -0700
Subject: [ python-Bugs-1482328 ] socket.getsockopt bug
Message-ID: <E1Fc0aH-0008Ql-OX@sc8-sf-web5.sourceforge.net>

Bugs item #1482328, was opened at 2006-05-05 12:22
Message generated for change (Comment added) made by gangesmaster
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1482328&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: ganges master (gangesmaster)
Assigned to: Nobody/Anonymous (nobody)
Summary: socket.getsockopt bug

Initial Comment:
i tested this on windows xp. the installed python
version is the 2.4.3 from the windows MSI.

when doing socket.getsockopt with buffer_size > 0, for
options like SO_LINGER or SO_SNDTIMEO, i get only 4 bytes. 
although the man pages state these options hold 8
bytes. is this a bug in the pythonic version of
getsockopt or winsock?

-tomer

----------------------------------------------------------------------

>Comment By: ganges master (gangesmaster)
Date: 2006-05-05 16:43

Message:
Logged In: YES 
user_id=1406776

i don't think so:

according to http://www.sockets.com/winsock.htm#GetSockOpt
and
http://www.gnu.org/software/libc/manual/html_node/Socket_002dLevel-Options.html

struct linger is defined this way:

struct linger {
	int	l_onoff;
	int	l_linger;
}

which means 8 bytes, and the same goes for struct timeval:

struct timeval {
        long    tv_sec;
        long    tv_usec;
};

still, the getsockopt returns only 4. i looked at the python
source but i can't find the bug... perhaps its a bug with
how they use winsock?

-tomer

----------------------------------------------------------------------

Comment By: Matt Fleming (splitscreen)
Date: 2006-05-05 16:12

Message:
Logged In: YES 
user_id=1126061

According to http://www.sockets.com/winsock.htm#GetSockOpt

"The integer pointed to by optlen should originally contain
the size of this buffer; on return, it will be set to the
size of the value returned. For SO_LINGER, this will be the
size of a struct linger; for all other options it will be
the size of an integer." 

The size of a linger struct is 4 bytes. 

I would agree that the Python documentation for
socket.getsockopt is a little confusing.

"Get a socket option.  See the Unix manual for level and
option. If a nonzero buffersize argument is given, the
return value is a string of that length; otherwise it is an
integer."

Perhaps just refer users to the OSes documentation on its
implementation of sockets?

Matt


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1482328&group_id=5470

From noreply at sourceforge.net  Fri May  5 15:51:43 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 05 May 2006 06:51:43 -0700
Subject: [ python-Bugs-1482328 ] socket.getsockopt bug
Message-ID: <E1Fc0id-00074P-PL@sc8-sf-web3.sourceforge.net>

Bugs item #1482328, was opened at 2006-05-05 09:22
Message generated for change (Comment added) made by splitscreen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1482328&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: ganges master (gangesmaster)
Assigned to: Nobody/Anonymous (nobody)
Summary: socket.getsockopt bug

Initial Comment:
i tested this on windows xp. the installed python
version is the 2.4.3 from the windows MSI.

when doing socket.getsockopt with buffer_size > 0, for
options like SO_LINGER or SO_SNDTIMEO, i get only 4 bytes. 
although the man pages state these options hold 8
bytes. is this a bug in the pythonic version of
getsockopt or winsock?

-tomer

----------------------------------------------------------------------

Comment By: Matt Fleming (splitscreen)
Date: 2006-05-05 13:51

Message:
Logged In: YES 
user_id=1126061

Visual Studio .NET 2003 comes with WinSock.h and defines the
linger struct as,

struct  linger {
        u_short l_onoff;                /* option on/off */
        u_short l_linger;               /* linger time */
};

However, on my NetBSD machine the linger struct is defined as,

struct  linger {
        int     l_onoff;                /* option on/off */
        int     l_linger;               /* linger time in
seconds */
};


----------------------------------------------------------------------

Comment By: ganges master (gangesmaster)
Date: 2006-05-05 13:43

Message:
Logged In: YES 
user_id=1406776

i don't think so:

according to http://www.sockets.com/winsock.htm#GetSockOpt
and
http://www.gnu.org/software/libc/manual/html_node/Socket_002dLevel-Options.html

struct linger is defined this way:

struct linger {
	int	l_onoff;
	int	l_linger;
}

which means 8 bytes, and the same goes for struct timeval:

struct timeval {
        long    tv_sec;
        long    tv_usec;
};

still, the getsockopt returns only 4. i looked at the python
source but i can't find the bug... perhaps its a bug with
how they use winsock?

-tomer

----------------------------------------------------------------------

Comment By: Matt Fleming (splitscreen)
Date: 2006-05-05 13:12

Message:
Logged In: YES 
user_id=1126061

According to http://www.sockets.com/winsock.htm#GetSockOpt

"The integer pointed to by optlen should originally contain
the size of this buffer; on return, it will be set to the
size of the value returned. For SO_LINGER, this will be the
size of a struct linger; for all other options it will be
the size of an integer." 

The size of a linger struct is 4 bytes. 

I would agree that the Python documentation for
socket.getsockopt is a little confusing.

"Get a socket option.  See the Unix manual for level and
option. If a nonzero buffersize argument is given, the
return value is a string of that length; otherwise it is an
integer."

Perhaps just refer users to the OSes documentation on its
implementation of sockets?

Matt


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1482328&group_id=5470

From noreply at sourceforge.net  Fri May  5 16:26:19 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 05 May 2006 07:26:19 -0700
Subject: [ python-Bugs-1482328 ] socket.getsockopt bug
Message-ID: <E1Fc1G7-000661-TT@sc8-sf-web1.sourceforge.net>

Bugs item #1482328, was opened at 2006-05-05 12:22
Message generated for change (Comment added) made by gangesmaster
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1482328&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: ganges master (gangesmaster)
Assigned to: Nobody/Anonymous (nobody)
Summary: socket.getsockopt bug

Initial Comment:
i tested this on windows xp. the installed python
version is the 2.4.3 from the windows MSI.

when doing socket.getsockopt with buffer_size > 0, for
options like SO_LINGER or SO_SNDTIMEO, i get only 4 bytes. 
although the man pages state these options hold 8
bytes. is this a bug in the pythonic version of
getsockopt or winsock?

-tomer

----------------------------------------------------------------------

>Comment By: ganges master (gangesmaster)
Date: 2006-05-05 17:26

Message:
Logged In: YES 
user_id=1406776

lovely. i hate windows. i guess it's not a bug then -- it's
a feature. arghh.

and i now found that SNDTIMEO doesn't take a timeval, rather
an integer. just great. so i'll close the bug.

-tomer

----------------------------------------------------------------------

Comment By: Matt Fleming (splitscreen)
Date: 2006-05-05 16:51

Message:
Logged In: YES 
user_id=1126061

Visual Studio .NET 2003 comes with WinSock.h and defines the
linger struct as,

struct  linger {
        u_short l_onoff;                /* option on/off */
        u_short l_linger;               /* linger time */
};

However, on my NetBSD machine the linger struct is defined as,

struct  linger {
        int     l_onoff;                /* option on/off */
        int     l_linger;               /* linger time in
seconds */
};


----------------------------------------------------------------------

Comment By: ganges master (gangesmaster)
Date: 2006-05-05 16:43

Message:
Logged In: YES 
user_id=1406776

i don't think so:

according to http://www.sockets.com/winsock.htm#GetSockOpt
and
http://www.gnu.org/software/libc/manual/html_node/Socket_002dLevel-Options.html

struct linger is defined this way:

struct linger {
	int	l_onoff;
	int	l_linger;
}

which means 8 bytes, and the same goes for struct timeval:

struct timeval {
        long    tv_sec;
        long    tv_usec;
};

still, the getsockopt returns only 4. i looked at the python
source but i can't find the bug... perhaps its a bug with
how they use winsock?

-tomer

----------------------------------------------------------------------

Comment By: Matt Fleming (splitscreen)
Date: 2006-05-05 16:12

Message:
Logged In: YES 
user_id=1126061

According to http://www.sockets.com/winsock.htm#GetSockOpt

"The integer pointed to by optlen should originally contain
the size of this buffer; on return, it will be set to the
size of the value returned. For SO_LINGER, this will be the
size of a struct linger; for all other options it will be
the size of an integer." 

The size of a linger struct is 4 bytes. 

I would agree that the Python documentation for
socket.getsockopt is a little confusing.

"Get a socket option.  See the Unix manual for level and
option. If a nonzero buffersize argument is given, the
return value is a string of that length; otherwise it is an
integer."

Perhaps just refer users to the OSes documentation on its
implementation of sockets?

Matt


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1482328&group_id=5470

From noreply at sourceforge.net  Fri May  5 16:27:46 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 05 May 2006 07:27:46 -0700
Subject: [ python-Bugs-1482328 ] socket.getsockopt bug
Message-ID: <E1Fc1HW-0006Bx-LO@sc8-sf-web1.sourceforge.net>

Bugs item #1482328, was opened at 2006-05-05 12:22
Message generated for change (Settings changed) made by gangesmaster
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1482328&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: None
Priority: 5
Submitted By: ganges master (gangesmaster)
Assigned to: Nobody/Anonymous (nobody)
Summary: socket.getsockopt bug

Initial Comment:
i tested this on windows xp. the installed python
version is the 2.4.3 from the windows MSI.

when doing socket.getsockopt with buffer_size > 0, for
options like SO_LINGER or SO_SNDTIMEO, i get only 4 bytes. 
although the man pages state these options hold 8
bytes. is this a bug in the pythonic version of
getsockopt or winsock?

-tomer

----------------------------------------------------------------------

Comment By: ganges master (gangesmaster)
Date: 2006-05-05 17:26

Message:
Logged In: YES 
user_id=1406776

lovely. i hate windows. i guess it's not a bug then -- it's
a feature. arghh.

and i now found that SNDTIMEO doesn't take a timeval, rather
an integer. just great. so i'll close the bug.

-tomer

----------------------------------------------------------------------

Comment By: Matt Fleming (splitscreen)
Date: 2006-05-05 16:51

Message:
Logged In: YES 
user_id=1126061

Visual Studio .NET 2003 comes with WinSock.h and defines the
linger struct as,

struct  linger {
        u_short l_onoff;                /* option on/off */
        u_short l_linger;               /* linger time */
};

However, on my NetBSD machine the linger struct is defined as,

struct  linger {
        int     l_onoff;                /* option on/off */
        int     l_linger;               /* linger time in
seconds */
};


----------------------------------------------------------------------

Comment By: ganges master (gangesmaster)
Date: 2006-05-05 16:43

Message:
Logged In: YES 
user_id=1406776

i don't think so:

according to http://www.sockets.com/winsock.htm#GetSockOpt
and
http://www.gnu.org/software/libc/manual/html_node/Socket_002dLevel-Options.html

struct linger is defined this way:

struct linger {
	int	l_onoff;
	int	l_linger;
}

which means 8 bytes, and the same goes for struct timeval:

struct timeval {
        long    tv_sec;
        long    tv_usec;
};

still, the getsockopt returns only 4. i looked at the python
source but i can't find the bug... perhaps its a bug with
how they use winsock?

-tomer

----------------------------------------------------------------------

Comment By: Matt Fleming (splitscreen)
Date: 2006-05-05 16:12

Message:
Logged In: YES 
user_id=1126061

According to http://www.sockets.com/winsock.htm#GetSockOpt

"The integer pointed to by optlen should originally contain
the size of this buffer; on return, it will be set to the
size of the value returned. For SO_LINGER, this will be the
size of a struct linger; for all other options it will be
the size of an integer." 

The size of a linger struct is 4 bytes. 

I would agree that the Python documentation for
socket.getsockopt is a little confusing.

"Get a socket option.  See the Unix manual for level and
option. If a nonzero buffersize argument is given, the
return value is a string of that length; otherwise it is an
integer."

Perhaps just refer users to the OSes documentation on its
implementation of sockets?

Matt


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1482328&group_id=5470

From noreply at sourceforge.net  Fri May  5 23:08:28 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 05 May 2006 14:08:28 -0700
Subject: [ python-Bugs-1482746 ] asyncore is not listed in test_sundry
Message-ID: <E1Fc7XI-0002P6-15@sc8-sf-web2.sourceforge.net>

Bugs item #1482746, was opened at 2006-05-05 16: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=1482746&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: jackilyn (jackilyn)
Assigned to: Nobody/Anonymous (nobody)
Summary: asyncore is not listed in test_sundry

Initial Comment:
I was adding logging to asyncore and I noticed asyncore
is not listed in test_sundry.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1482746&group_id=5470

From noreply at sourceforge.net  Sat May  6 03:04:18 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 05 May 2006 18:04:18 -0700
Subject: [ python-Bugs-1284316 ] Win32: Security problem with default
	installation directory
Message-ID: <E1FcBDW-0001j5-ME@sc8-sf-web3.sourceforge.net>

Bugs item #1284316, was opened at 2005-09-08 06:34
Message generated for change (Comment added) made by dsmiller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1284316&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: Installation
Group: Platform-specific
Status: Open
Resolution: None
Priority: 7
Submitted By: Mika Eloranta (mel)
Assigned to: Martin v. L??wis (loewis)
Summary: Win32: Security problem with default installation directory

Initial Comment:
(Sorry, this is a bit long since the issue is not
entirely trivial.)

This problem only exists on Windows operating systems
installed on an NTFS file system. Confirmed on several
Windows 2000, XP and Windows 2003 Server systems. All
Python versions (at least 2.x) are affected.

The default installation target directory where Python
is installation on Windows is directly under the system
drive's root directory (e.g. "C:\python24"). The file
and directory permissions inherited by the
python24-directory from the root directory are not
secure enough for keeping application binaries.

Microsoft has, in their infinite wisdom, decided that
the root directory of the system drive should allow
regular (non-admin) users to create directories and
files there. This set of permissions is inherited by
the python directory when it is created in the default
location (i.e. "C:\python24" or whatever).

This "feature" allows a regular (non-admin) user to
perform a priviledge escalation attack for example in
the following manner:

1. Figure out the name of some DLL python (or some
extension .PYD) loads using LoadLibrary() without an
absolute path.

2. Copy a DLL with the same name into the
python-directory (this should not be allowed, but it
is!) containing some code the attacker wants to run
with escalated priviledges.

3. Wait until python is run by an admin in the same
machine or by the LocalSystem account.

How to view the problematic part of the ACL:
1. Right-click the "C:\python24" directory in Windows
Explorer
2. select Properties... -> Security -> Advanced
3. In the "Permissions" tab you will see an entry for
the "Users" group, it says "Special" in the
"Permissions" column
4. Select the above entry and click "Edit..."
5. Well hidden? I think so, too.

The fix:
The proper (default) location where application
binaries should be installed is under the "c:\program
files\" directory. This directory has properly set
permissions by default.

PS. The same problem exists in ActivePerl, Ruby and
many other tools.


----------------------------------------------------------------------

Comment By: D. Scott Miller (dsmiller)
Date: 2006-05-06 10:04

Message:
Logged In: YES 
user_id=1517734

Here's a few possible solutions to the permissions problem
that retain the idea of defaulting to an install path with
no spaces without making too many assumptions about what
permissions the installing admin actually wants:
-----------------
Idea #1

Install by default to %systemroot%\PythonXX. Hey, Java
sticks some stuff in there, right? If the idea is "this is
kind of a part-of-the-OS thing, and MS does it this way for
cscript.exe" then this seems to make sense. (We hope any
admins who're using a %systemroot% with spaces in it know
what they're doing.)

Is the default name for %systemroot% different on any
particular localized versions of Windows? I know it's
"WINDOWS" in Japanese versions, anyway.
-----------------
Idea #2

Have two folder select boxes in the installer, one for where
to install Python and one for a folder from which to copy
ACLs. These would default to %systemdrive%\PythonXX and
%programfiles%, respectively. Have a check box to disable
the ACL copying, but have it checked by default.

This is still bad, as it doesn't solve the problem of being
a special separate directory with its own individual ACL to
maintain, but it's somewhat less bad than it is now for
people who click through the installer trusting it to not
open up their system to new flavors of privilege escalation.
-----------------
Idea #3

Do something goofy with NTFS junctions.
-----------------

Regardless of what's done, given that people expect not to
have to worry about spaces these days, it may be a good idea
to include an explanation/warning about the situation in the
installer text.
-----------------

In regards to Martin L??wis' concern about non-admin users
not being able to cause the generation of .pyc files in the
main Python directory tree: It's already like that on most
OS's, correct? So it would just apply in cases where someone
a) writes an add-on specifically targeting the Python
directory tree, specifically for Windows and b) expects .pyc
generation to be done later rather than scripted as part of
the installation. I have no idea if that's common or not,
but it seems relatively safe to break.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-03-23 05:27

Message:
Logged In: YES 
user_id=31435

A long time ago, Python did install (by default) under
"Program Files".  I changed that, because of the endless
problems created by the frickin' embedded space, and rarer
but subtler problems due to "Program Files" not being a
DOSish 8.3 name.  Overall I still think it was a good change.

Note that, unlike most Windows applications (which are
GUI-based), programming languages are _intended_ to be used
heavily from the command line, invoked by scripts, and so
on.  That's what makes a space in the path endlessly
error-prone.  In WinXP Pro, I noticed that MS was still
careful to put its own command-line/script tools (sort.exe,
ipconfig.exe, cscript.exe, ..., even notepad.exe) under pure
DOSish 8.3 space-free paths ;-)

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-03-23 04:09

Message:
Logged In: YES 
user_id=21627

I completely disagree. It was wrong to give the system
default binary directory a name with a space in it, on a
system that doesn't provide command line argument vectors in
its standard API.

----------------------------------------------------------------------

Comment By: Mika Eloranta (mel)
Date: 2005-11-19 17:46

Message:
Logged In: YES 
user_id=109057

Wow, even easy_install.exe from setuptools fails if python
is installed under "c:\program files":

C:\temp>easy_install
C:\program: can't open file 'files\Python24\python.exe':
[Errno 2] No such file or directory

IMHO the root cause to all these problems is the wrong
default installation directory. If the installation
directory would conform to Windows guidelines, these kind of
problems would have been easily spotted by python library
developers.

    - Mika


----------------------------------------------------------------------

Comment By: Mika Eloranta (mel)
Date: 2005-11-15 20:39

Message:
Logged In: YES 
user_id=109057

Please consider these points as well:

* The "program files" directory has "sensible" ACLs set by
default (the defaults are different in different OS
versions). If you install your application under "program
files", you do not need to worry about the permissions.

* The installation directory can be added to the PATH
environment variable instead of typing it every time from
console...

* The current default installation directory is teaching
python library developers bad habits of not handling Python
installed into a directory that contains spaces properly. It
is actually a miracle to find a third party library that
installs a working script (batch file) to "python/scripts"
if the python directory contains spaces.

* The "program files" directory is the standard location
where applications should be installed in Windows. This is
what Microsoft requires in their guidelines and most
applications obey them. You would not install python to
"/python24" by default in Unix would you?



----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2005-10-08 18:48

Message:
Logged In: YES 
user_id=21627

I disagree that the default location of Python should be
c:\Program Files. The Python interpreter's path name is
often typed into a terminal, batch file, etc., so it needs
to be convenient to type.

I agree that the permissions are problematic; the proper
solution would be to give c:\python24 more restrictive
permissions. You can do this yourself: in the security tab,
edit the permission. In "Advanced", unselect the "Inherit
permission" checkbox, and choose "copy" when asked. Then
edit the permissions to your liking.

I can consider supporting such permission setting during
installation in the future - an invocation of cacls.exe
should do. 

Notice that this is an incompatible change: as currently all
users can create files in the tree, the .pyc files are often
not created during installation, but on first use. If write
permissions are denied, normal users could not cause .pyc
creation anymore, causing increased startup costs unless the
.pyc files are created during installation.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-09-30 15:26

Message:
Logged In: YES 
user_id=33168

Martin, do you know anything about this?  (Sorry, don't know
who else might know.)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1284316&group_id=5470

From noreply at sourceforge.net  Sat May  6 08:28:10 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 05 May 2006 23:28:10 -0700
Subject: [ python-Bugs-1482746 ] asyncore is not listed in test_sundry
Message-ID: <E1FcGGw-0004m7-6J@sc8-sf-web2.sourceforge.net>

Bugs item #1482746, was opened at 2006-05-05 21:08
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1482746&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: Works For Me
Priority: 5
Submitted By: jackilyn (jackilyn)
Assigned to: Nobody/Anonymous (nobody)
Summary: asyncore is not listed in test_sundry

Initial Comment:
I was adding logging to asyncore and I noticed asyncore
is not listed in test_sundry.

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-05-06 06:28

Message:
Logged In: YES 
user_id=849994

asyncore is already imported by test_asynchat.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1482746&group_id=5470

From noreply at sourceforge.net  Sat May  6 14:54:44 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 06 May 2006 05:54:44 -0700
Subject: [ python-Bugs-1482988 ] docs for 'profile' should refer to
	pstats.Stats
Message-ID: <E1FcMJ2-0005Br-Om@sc8-sf-web3.sourceforge.net>

Bugs item #1482988, was opened at 2006-05-06 15:54
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=1482988&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: Ori Peleg (oripel)
Assigned to: Nobody/Anonymous (nobody)
Summary: docs for 'profile' should refer to pstats.Stats

Initial Comment:
The docs for module 'profile' refer to 'profile.Stats',
which look like:

def Stats(*args):
    print 'Report generating functions are in the
"pstats" module\a'

This is true in older Python versions, as well as 2.5a2:

http://docs.python.org/dev/lib/module-profile.html

Suggestion: have the documentation point to
pstats.Stats instead, and possibly remove the
placeholder 'Stats' in module profile, or have it raise
an exception instead of printing an error.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1482988&group_id=5470

From noreply at sourceforge.net  Sat May  6 14:57:59 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 06 May 2006 05:57:59 -0700
Subject: [ python-Bugs-1482988 ] docs for 'profile' should refer to
	pstats.Stats
Message-ID: <E1FcMMB-0004Xr-6X@sc8-sf-web5.sourceforge.net>

Bugs item #1482988, was opened at 2006-05-06 15:54
Message generated for change (Comment added) made by oripel
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1482988&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: Ori Peleg (oripel)
Assigned to: Nobody/Anonymous (nobody)
Summary: docs for 'profile' should refer to pstats.Stats

Initial Comment:
The docs for module 'profile' refer to 'profile.Stats',
which look like:

def Stats(*args):
    print 'Report generating functions are in the
"pstats" module\a'

This is true in older Python versions, as well as 2.5a2:

http://docs.python.org/dev/lib/module-profile.html

Suggestion: have the documentation point to
pstats.Stats instead, and possibly remove the
placeholder 'Stats' in module profile, or have it raise
an exception instead of printing an error.


----------------------------------------------------------------------

>Comment By: Ori Peleg (oripel)
Date: 2006-05-06 15:57

Message:
Logged In: YES 
user_id=1131251

A correction - the docs do refer to the 'this class from the
pstats module', but this easily missed by someone skipping
carefully reading the preamble text (like me :-/ )

You could say this is PEBKAC (problem exists between
keyboard and chair), but I suggest it's a common phenomenon
meaning the pointer to module 'pstats' should be more prominent.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1482988&group_id=5470

From noreply at sourceforge.net  Sat May  6 21:29:35 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 06 May 2006 12:29:35 -0700
Subject: [ python-Bugs-1480678 ] mmap tries to truncate special files
Message-ID: <E1FcST9-0006te-Ku@sc8-sf-web5.sourceforge.net>

Bugs item #1480678, was opened at 2006-05-02 13:56
Message generated for change (Comment added) made by josiahcarlson
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1480678&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: Not a Bug
Status: Closed
Resolution: Rejected
Priority: 5
Submitted By: Carl Banks (aerojockey)
Assigned to: Nobody/Anonymous (nobody)
Summary: mmap tries to truncate special files

Initial Comment:
One Unix, the resize() method of an mmap object calls
ftruncate to also resize the associated file.  Problem
is, ftruncate fails if the fd refers to a special file.
 This is a problem for someone trying to resize an
anonymous memory map using /dev/zero.

Apparently hasn't been fixed in 2.5 (based on SVN and
changelogs) but I haven't tested it.

----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-05-06 12:29

Message:
Logged In: YES 
user_id=341410

The user could also os.tempnam() to come up with a file
name, create a 0-lengthed file, mmap it, unlink it, then
resize.  This method will create an anonymous mmap that is
resizable (according to the docs).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-05-03 12:02

Message:
Logged In: YES 
user_id=31435

I have to confess I don't know _why_ resize() changes the
size of the file too, and think that's a debatable design
decision.  But when code is working as intended and as
documented, by definition that's not "a bug".

The reason "it worked" in Python 2.3 is explained in bug 728515:

http://www.python.org/sf/728515

As it says there, it was a bug that resize() resized the
file on Windows, but neglected to do so on Unixish boxes at
the time.  That bug was fixed by making it resize the file
on Unixish boxes too.

Since the intent here is clear (albeit questionable) and
documented, I'm closing this as not-a-bug.

----------------------------------------------------------------------

Comment By: Carl Banks (aerojockey)
Date: 2006-05-03 11:19

Message:
Logged In: YES 
user_id=1515186

Well, since resizing an anonymous array seems a reasonable
thing to do, and because it worked in Python 2.3, I presumed
that the error was an oversight, and not intended behavior.

If it is, in fact, intended behavior, then ok, though I
don't agree with it.  (It's not as if /dev/zero has fixed
size that doesn't change; it's inherently sizeless.)

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-05-02 23:13

Message:
Logged In: YES 
user_id=31435

Ya, this isn't a bug:  resize() is documented as changing
the size of _both_ the map and the file.  If the size of the
file can't be changed, then of course resize() will fail.

aerojockey:  can't you simply close your current map and
create a new map with the size you want?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-05-02 22:21

Message:
Logged In: YES 
user_id=33168

I don't understand what the problem is.  ISTM if you resize
a special file an exception will be raised.  Is that not the
case?  What do you expect to happen?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1480678&group_id=5470

From noreply at sourceforge.net  Sat May  6 23:09:39 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 06 May 2006 14:09:39 -0700
Subject: [ python-Bugs-1483133 ] Objects/genobject.c:53: gen_iternext:
	Assertion `f->f_back !
Message-ID: <E1FcU1z-0007ip-6s@sc8-sf-web3.sourceforge.net>

Bugs item #1483133, was opened at 2006-05-07 00:09
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=1483133&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: svensoho (svensoho)
Assigned to: Nobody/Anonymous (nobody)
Summary: Objects/genobject.c:53: gen_iternext: Assertion `f->f_back !

Initial Comment:
Seems to be similar bug as http://sourceforge.net/
tracker/index.php?
func=detail&aid=1257960&group_id=5470&atid=105470 
(fixed)

Couldn't trigger with same script but with C 
application. Same source modification helps (at 
Objects/genobject.c:53)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1483133&group_id=5470

From noreply at sourceforge.net  Sun May  7 13:38:24 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 07 May 2006 04:38:24 -0700
Subject: [ python-Bugs-595601 ] file (&amp; socket) I/O are not thread safe
Message-ID: <E1Fchai-0001Zr-Hp@sc8-sf-web3.sourceforge.net>

Bugs item #595601, was opened at 2002-08-15 11:34
Message generated for change (Comment added) made by aegis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595601&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: Jeremy Hylton (jhylton)
Assigned to: Jeremy Hylton (jhylton)
Summary: file (&amp; socket) I/O are not thread safe

Initial Comment:
We recently found an assertion failure in the universal
newline support when running a multithreaded program
where two threads used the same Python file object. 
The assert(stream != NULL) test in 
Py_UniversalNewlineFread() fails once in a blue moon,
where stream is the stdio FILE * that the fileobject
wraps.  Further analysis suggests that there is a race
condition between checking FILE * and using FILE * that
exists in at least Python 2.1 and up.

I'll actually describe the problem as it exists in
Python 2.2, because it is simpler to avoid the
universal newline code.  That code isn't the source of
the problem, although it's assert() uncovers it in a
clear way.

In file_read() (rev 2.141.6.5), the first thing it does
is check if f_fp (the FILE *) is NULL.  If so it raises
an IOError -- operation on closed file object.  Later,
file_read() enters a for loop that calls fread() until
enough bytes have been read.

	for (;;) {
		Py_BEGIN_ALLOW_THREADS
		errno = 0;
		chunksize = fread(BUF(v) + bytesread, 1,
				  buffersize - bytesread, f-&gt;f_fp);
		Py_END_ALLOW_THREADS
		if (chunksize == 0) {
			if (!ferror(f-&gt;f_fp))
				break;
			PyErr_SetFromErrno(PyExc_IOError);
			clearerr(f-&gt;f_fp);
			Py_DECREF(v);
			return NULL;
		}

The problem is that fread() is called after the global
interpreter lock is released.  Since the lock is
released, another Python thread could run and modify
the file object, changing the value of f-&gt;f_fp.  Under
the current interpreter lock scheme, it isn't safe to
use f-&gt;f_fp without holding the interpreter lock.

The current file_read() code can fail in a variety of
ways.  It's possible for a second thread to close the
file, which will set f-&gt;f_fp to NULL.  Who knows what
fread() will do when NULL is passed.

The universal newline code is squirrels the FILE * in a
local variable, which is worse.  If it happens that
another thread closes the file, at best the local
points to a closed FILE *.  But that memory could get
recycled and then there's no way to know what it points to.

socket I/O has a similar problem with unsafe sharing of
the file descriptor.  However, this problem seems less
severe in general, because we'd just be passing a bogus
file descriptor to a system call.  We don't have to
worry about whether stdio will dump core when passed a
bogus pointer.  There is a chance the a socket will be
closed and its file descriptor used for a different
socket.  So a call to recv() with one socket ends up
using a different socket.  That will be a nightmare to
debug, but it won't cause a segfault.  (And, in
general, files and sockets shouldn't be shared between
application threads unless the application is going to
make sure its safe.)

The solution to this problem is to use a
per-file-object lock to guard access to f-&gt;f_fp.  No
thread should read or right f-&gt;f_fp without holding the
lock.  To make sure that other threads get a chance to
run when there is contention for the file, the
file-object lock should never be held when the GIL is held.


----------------------------------------------------------------------

Comment By: Chad Austin (aegis)
Date: 2006-05-07 06:38

Message:
Logged In: YES 
user_id=7212

I'd like to add that this particular problem cost me about a
week of trying to figure out what the heck was going on, a
stack trace thrown from Python is MUCH better than
intermittent last-chance exceptions thrown from our binaries
in the field.  :)

http://aegisknight.livejournal.com/128191.html


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-08-20 15:49

Message:
Logged In: YES 
user_id=31392

Here's a checkpoint of current progress.  The patch applies
cleanly and even compiles.  It works most of the time, but
it causes a bunch of test failures.  I haven't had time to
debug the errors, two likely errors are incorrect
propagation of errors from across the release lock boundary.
 (The error checking goes on inside so that clearerr() can
be called while the file lock is held but
PyErr_SetFromErrno() can be called while the GIL is held.) 
The other source of errors is typos -- like calling LOCK
when you mean UNLOCK.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-20 14:43

Message:
Logged In: YES 
user_id=6380

Wow. This is harder than I thought! :-(

We should be able to solve whatever problem there is with
'print'. The PyFile_AsFile() API may have to become
obsolete, *or* we may have to add a separate call to access
the lock. I'll have to think about it more.

----------------------------------------------------------------------

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2002-08-16 17:43

Message:
Logged In: YES 
user_id=12800

Jack, your last paragraph sounds like a good idea &lt;waiting
for Tim to shoot holes in it&gt;.  Isn't the whole point to
avoid core dumps, not to &quot;make it work right&quot; whatever that
means?  We should take the simplest approach to avoiding
crashes.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2002-08-16 17:21

Message:
Logged In: YES 
user_id=45365

Uhm... Isn't it good enough if you don't hold the GIL while you acquire the file lock? When I looked at it I thought it would be (but then, I didn't look very hard:-).

And there may be another way around this problem too. If you're really only worried about closing (Python at the moment couldn't care less that when two threads write to the same file at the same time the output may be intermingled or other fun things may happen) then don't lock the file, but simply set a flag &quot;keep your hands off the FILE*, I'm using it!&quot; and in that case delay the close. You may want to protect the flag and the delayed close with a lock, I guess.

Or you could define this as a programmer error and raise an exception if one thread tries to close a file another thread is using. (The application will know much better how to handle the contention with locking or some other mechanism).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-08-16 10:26

Message:
Logged In: YES 
user_id=31435

To cheer you up, it's probably worse than that &lt;wink&gt;.  
While you're holding a file lock, in theory you dare not 
execute any code that may call back into Python, because 
the called code may try to do an operation on the file 
you've got locked, and then the whole system freezes. That 
is, independent of the GIL, it's not thoroughly safe to call 
PyObject_Print with a file lock held, because an object's 
__str__ may try to &quot;do something&quot; with the Python-level file 
object too.  The more depressing news is that a reentrant 
file lock would solve that one.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-08-16 10:04

Message:
Logged In: YES 
user_id=31392

I think I'm less worried about PyFile_AsFile() than I am
about PyFile_WriteObject().  The latter is invoked by the
print statement.  It extracts the FILE* using
PyFile_AsFile() and proceeds to pass it to PyObject_Print().
 PyObject_Print() MUST hold the GIL, but since it has the
raw FILE* it MUST hold the file lock.  But you can't hold
both locks :-(.


----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2002-08-15 15:49

Message:
Logged In: YES 
user_id=45365

I'm not sure your solution of locking in the file object is feasible. Every call of PyFile_AsFile() is dangerous, if the  code proceeds to release the GIL before using the FILE* it's in danger. And this code could be in extension modules too (I know there's quite a few in my own img package).

When I did the universal newlines patch I basically ignored the problem (thinking that no-one in their right mind would close a file in one thread while it's still in use in another: how wrong can one be:-).

The only real solution may be to get rid of PyFile_AsFile altogether, and replace it with PyFile_AsFileLocked() and PyFile_Unlock() and make these calls somehow work even when the GIL is held (possibly by temporarily releasing the GIL while acquiring the file lock).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595601&group_id=5470

From noreply at sourceforge.net  Sun May  7 13:55:17 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 07 May 2006 04:55:17 -0700
Subject: [ python-Bugs-1471427 ] tarfile.py chokes on long names
Message-ID: <E1Fchr3-0002Xi-Up@sc8-sf-web1.sourceforge.net>

Bugs item #1471427, was opened at 2006-04-16 22:34
Message generated for change (Comment added) made by alexanderweb
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1471427&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: Fixed
Priority: 5
Submitted By: Alexander Schremmer (alexanderweb)
Assigned to: Nobody/Anonymous (nobody)
Summary: tarfile.py chokes on long names

Initial Comment:
The following bug is reproducible on Py 2.4.3 and 2.5. 
It was tested on Windows. You need a tarfile with a 
long file name that triggers the GNU LONGNAME 
extension.

Extracting such a file gives me an IO error because it 
tries to create a file with a slash at the end. This is 
because 

        # Some old tar programs represent a directory 
as a regular
        # file with a trailing slash.
        if tarinfo.isreg() and tarinfo.name.endswith("/
"):
            tarinfo.type = DIRTYPE

sets the type incorrectly after it was called from the 
callback proc which has no possiblity to set the name 
of the intermediary tarinfo class because it is 
instantiated in the next-method.

So this yields a directory which should be a file which 
is obviously wrong. Might be related to commit 41340 
"Patch #1338314, Bug #1336623". (At least the code 
changed there is causing this bug).

----------------------------------------------------------------------

>Comment By: Alexander Schremmer (alexanderweb)
Date: 2006-05-07 13:55

Message:
Logged In: YES 
user_id=254738

Thanks, that seems to work. Try to get this into Py 2.5 :)

----------------------------------------------------------------------

Comment By: Lars Gust?bel (gustaebel)
Date: 2006-04-25 22:59

Message:
Logged In: YES 
user_id=642936

Fixing this issue is not quite as simple as I hoped it to
be. It would be possible to implement a quick fix that
solves the problem, but that would be too ugly for a stdlib
module. Instead, I have been busy writing a preliminary fix
for my development version of tarfile.py which is available
at http://www.gustaebel.de/lars/tarfile/.
It would be nice of you, if you'd download the 0.8.0 version
there and give it a try. Thank you.


----------------------------------------------------------------------

Comment By: Alexander Schremmer (alexanderweb)
Date: 2006-04-16 22:34

Message:
Logged In: YES 
user_id=254738

Hmm, I just want to clarify that tarfile doesn't give the IO 
error (it passes silently) but my code that expects a file 
instead of a directory ;-)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1471427&group_id=5470

From noreply at sourceforge.net  Sun May  7 15:22:45 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 07 May 2006 06:22:45 -0700
Subject: [ python-Bugs-1481770 ] hpux ia64 shared lib ext should be ".so"
Message-ID: <E1FcjDh-0004r7-9t@sc8-sf-web2.sourceforge.net>

Bugs item #1481770, was opened at 2006-05-04 05:43
Message generated for change (Comment added) made by deckrider
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1481770&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: David Everly (deckrider)
Assigned to: Nobody/Anonymous (nobody)
Summary: hpux ia64 shared lib ext should be ".so"

Initial Comment:
On hpux ia64, the shared library extension should be
".so".  This is currently problematic in that other
add-on python modules (such as those for subversion)
correctly detect the host_os/host_cpu and build
_module.so, which is not seen by python built using ".sl".

According to
http://devresource.hp.com/drc/resources/portguideipf/index.jsp#dynlinkfac


"Shared library names

Since dynamic linking APIs operate on shared libraries,
it is also important to note that the shared library
naming scheme on Linux is lib*.so; whereas, on HP-UX
11i Version 1.5 the naming scheme is lib*.sl for PA and
lib*.so on IPF. Also APIs may reside in different
libraries files on Linux and HP-UX, so you may need to
dynamically load a different shared library name on
HP-UX and Linux."

To translate this quote, PA=hppa and IPF=ia64.


----------------------------------------------------------------------

>Comment By: David Everly (deckrider)
Date: 2006-05-07 07:22

Message:
Logged In: YES 
user_id=1113403

Here is a patch against
http://svn.python.org/projects/python/branches/release24-maint

I don't have many evironments to test against, and only
Linux right now (will test on HPUX ia64 tomorrow and report
back).

----------------------------------------------------------------------

Comment By: David Everly (deckrider)
Date: 2006-05-05 06:07

Message:
Logged In: YES 
user_id=1113403

The patch I'm using now only works on hppa/ia64 and isn't
anything that can coexist nicely in the source package on
other hardware/os combinations.

I've looked at
http://svn.python.org/projects/python/branches/release24-maint/

I'm accustomed to a system using autoconf/libtool/automake
(recent versions) and never committing the output of those
tools, but only running them at source package generation time.

I say this, only to point out that I'm not understanding the
principles behind what I see in subversion.  I see
configure, and also configure.in.  Which should be patched?
 And if I don't patch configure, what is the process for
regenerating it (and with what versions of automake,
autoconf, and libtool?).

Also, the most recent libtool already correctly determines
shared library extension.

So I could probably provide a patch, but would need to
understand the environment better in order to do so.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-05-05 01:02

Message:
Logged In: YES 
user_id=33168

Do you think you could work on a patch to address this issue?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1481770&group_id=5470

From noreply at sourceforge.net  Sun May  7 17:27:51 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 07 May 2006 08:27:51 -0700
Subject: [ python-Feature Requests-1110010 ] 'attrmap' function,
	attrmap(x)['attname'] == x.attname
Message-ID: <E1FclAl-0002sQ-2W@sc8-sf-web1.sourceforge.net>

Feature Requests item #1110010, was opened at 2005-01-26 11:28
Message generated for change (Comment added) made by gregsmith
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1110010&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: Gregory Smith (gregsmith)
Assigned to: Nobody/Anonymous (nobody)
Summary: 'attrmap' function, attrmap(x)['attname'] == x.attname

Initial Comment:
One of the side effects of the new-style classes is that
objects don't necessarily have __dict__ attached to them.
It used to be possible to write things like

   def __str__(self):
          return "Node %(name)s, %(nlinks)d links,
active: %(active)s" % self.__dict__


... but this doesn't work if the class doesn't have a
__dict__. Even if does, I'm not sure it will always get
members from base classes.

There is a 'vars' function; you could put 'vars(self)'
in the above instead of self.__dict__, but it still
doesn't work if
the class doesn't have a __dict__.

I can see different solutions for this:

(1) change the 'string %' operator so that it allows
 %(.name)s, leading to a getattr() on the right-side
argument
  rather than a getitem. 

          return "Node %(.name)s, %(.nlinks)d links,
active: %(.active)s" % self

(2) Make a builtin like vars, but which works when the
object doesn't have a __dict__ I.e. attrmap(x) would
return a mapping which is bound to x, and reading
attrmap(x)['attname'] is the same as
getattr(x,'attname'). Thus

          return "Node %(name)s, %(nlinks)d links,
active: %(active)s" % attrmap(self)


This attrmap() function can be implemented in pure
python, of course.

I originally thought (1) made a lot of sense, but (2) seems
to work just as well and doesn't require changing much.
Also, (1) allows  cases like "%(name)s %(.name2)s",
which are not very useful, but are very likely to be
created by
accident; whereas in (2) you are deciding on the right
of the '%' whether you are naming attributes or
providing mapping keys. 

I'm not sure it's a good idea change 'vars' to have
this behaviour, since vars(x).keys() currently works in
a predictable way when vars(x) works; whereas
attrmap(x).keys() may not be complete, or possible, 
even when attrmap(x) is useful. I.e. when x has a
__getattr__ defined.
On the other hand, vars(x) doesn't currently do much at
all, so maybe it's possible to enhance it like this
without breaking anything.

The motivation for this came from the "%(name)s" issue,
but the attrmap() function would be useful in other
places e.g.

processdata( infile,  outfile, **attrmap(options))

... where options might be obtained from optparse, e.g.
  
Or, an attrmap can be used with the new Templates:
string.Template('Node $name').substitute( attrmap(node))

Both of these examples will work with vars(), but only
when the object actually has __dict__. This is why
I'm thinking it may make sense to enhance vars: some
code may be broken by the change; but other code,
broken by new-style classes, may be unbroken by this
change.

The proxy could be writable, so that
    attrmap(x)['a'] = y
is the same as
     x.a = y
.. which could have more uses.

A possible useful (possibly weird) variation: attrmap
accepts 1 or more parameters, and the resulting
proxy is bound to all of them. when attrmap(x,y,z)['a']
is done, the proxy will try x.a, y.a, z.a until one of
them doesn't raise AttributeError. So it's equivalent
to merging dictionaries. This would be useful
in the %(name)s or Template cases, where you want
information from several objects.





----------------------------------------------------------------------

>Comment By: Gregory Smith (gregsmith)
Date: 2006-05-07 11:27

Message:
Logged In: YES 
user_id=292741

I can't disagree with that -- one of the things I like about
python is that simple funcs I use fairly often can usually
be retyped out of my head in less time than it takes to find
them and copy them from another software project- and more
importantly, there's basically no risk that the fresh one
will be buggy, if it's expression is simple and clear.
So, the overhead of maintaining a zillion 'standard' utility
funcs outweighs the cost of having to recode them instead,
when they are small and simple. This applies as much to the
core library as it does to a site-specific library.

I do prefer if they have the same names each time I use them
though, since it makes it easier to transplant higher-level
chunks of code from one program to another. When I ran
across this issue and its solution, I figured it would be
something that, if available, could be used often enough to
justify have a standard name. But I agree now it shouldn't
be a builtin; having it as operator.attrmap still means you
can copy code using it from one application to another
without having to hunt down where 'attrmap' got implemented. 


----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-05-05 02:28

Message:
Logged In: YES 
user_id=341410

As I and others have expressed perhaps hundreds of times
over the last few years; not all X line functions/classes
should be built into Python.  This particular object doesn't
have enough general usefulness to make it into Python as a
builtin, so you would need to import something anyways.

If you are going to need to import to get at it, you may as
well put this somewhere, and perhaps monkey-patch
__builtins__ yourself so that you can get at it everywhere
without importing it.  Heck, you could even put it into
site.py .

If this were going to make it into Python, I would suggest
it go into the operator module, where a similar feature
already exists in the operator.attrgetter.  If there is also
desire, one may want to offer mapattr class which does
x.attr -> x['attr'] .

All in all, I'm -0; it would be useful, but I believe most
people would just write the 5-liner and call it good.

----------------------------------------------------------------------

Comment By: Gregory Smith (gregsmith)
Date: 2006-05-04 11:19

Message:
Logged In: YES 
user_id=292741

Josiah, I'm well aware of that, but as I said 10/26 I don't
want to add attribute mapping to a whole set of classes just
so they will all work a certain way in one specific
situation; I want a separate adapter so I can have attribute
mapping for ANY object in that specific situation. I can't
mixin a new base class into every class I might encounter,
since most of them are not under my control; but all of them
have an attribute interface and will all work with attrmap.
There's no reason to mess things up like that when
I can implement attrmap already (and have done) -- and you
have shown how short the code is on your 6/26/'05 post --
I'm just suggesting this is simple, elegant, and generally
useful enough to be included as a standard python gizmo.



----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2005-10-27 02:16

Message:
Logged In: YES 
user_id=341410

gregsmith:

class attrmap:
    def __getitem__(self, key):
        return getattr(self, key)

Use that as a mixin with any class you want to offer
attribute mapping support to.  As in...

class foo(..., attrmap):
    ...

Now your class has attribute mapping support.  Amazing!

As for the neatness of __dict__, I have used it before, but
when I need to rely on using __dict__, I make sure my object
has one (generally by not creating or using __slots__).

----------------------------------------------------------------------

Comment By: Gregory Smith (gregsmith)
Date: 2005-10-26 14:14

Message:
Logged In: YES 
user_id=292741


To josiahcarlson: Yes, I can add __getitem__ to any class.
But I don't see why I should make a whole bunch of classes
act like dictionaries,  only so that I can pass them to
single API (like string.Template) which requires a
dictionary. A class should have a dictionary behaviour if it
makes sense for that class; if I have to add it
specifically, and only, to make it work well in one
particular situation, that's a kluge. If I have to add dict
behaviour to a whole bunch of classes to make them all work
in that one situation, that's a serious kluge. And entirely
unintuitive, to borrow a phrase. When you encounter this
situation, IMO, it's clear that a little 'pipe-fitting' like
this is the best solution.

Furthermore, and to underline the above, what if I have a
class which already has a __getitem__ interface for it's own
purposes? Chances are this behaves in a way which makes it
useless for harvesting general attributes from the object;
the object always has  a getattr interface, however.

Since ALL objects have a getattr interface, and  there's a
fair number of APIs that require objects with a read-only,
string-keyed dict interface, why not have this universal
pipe-fitting to tie them together, so as not to have to
modify the objects and/or interfaces.

To rhettinger:
First off, what do you mean by 'use case'? I gave three
examples of the use of the function, with %attrmap(x),
string.Template(...).substitute(attrmap(x));
attrmap(options).
 I can expand these to more detail if you like. I didn't
give use examples for the 'write' case; I haven't
encountered a use for that.

Yes, you have to think a bit before you see what it's for.
That's arguably true for super(), slice() and
operator.attrgetter() as well. Once you've run into the
situation where it's useful, it becomes pretty clear what
it's for.  Given the general problem it solves, it's hard to
imagine a neater and more intuitive solution IMO.

Here's a 2-line sales pitch, which was implied, but not
given, in the original post:


  def __str__(self):
     return "MyObj(name=%(name)s, n=%(n)d, links = %(links)d
)" % attrmap(self)

vs. the harder-to-maintain

     return "MyObj( name=%s, n=%d, links = %d )" %
(self.name, self.n, self.links)

...this requires the programmer to maintain the same list of
symbols twice, a burden which is very common in languages
inferior to Python.

And obviously it's very simple (the base functionality is 5
lines). Like attrgetter, It becomes more useful when it's
always available in the standard lib, and a little faster if
it happens to be in C.

to loewis:
   fair enough, maybe it doesn't qualify for a builtin. But
it might make more sense to do it as operator.attrmap rather
than UserDict.AttrMap; it seems to fit into the same
category as attrgettr and itemgetter. I wasn't aware of
those two when I originally posted.

And am I the only one who thinks the first example I gave
(with __str__ using "..."%self.__dict__) is a pretty neat
trick? And who has noticed it's been broken  with new-style
classes? That by itself, IMO, calls for a fix, and replacing
self.__dict__ with attrmap(self) is a pretty simple fix.




----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-06-27 00:18

Message:
Logged In: YES 
user_id=80475

-1

While potentially useful, the function is entirely unintuitive (it has 
to be studied a bit before being able to see what it is for).  Also, 
the OP is short on use cases (none were presented).  IMO, this 
belongs as a cookbook recipe.

----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2005-06-26 13:47

Message:
Logged In: YES 
user_id=341410

An implementation of the base attrmap functionality (as
suggested by Reinhold in his post in python-dev)...

class attrmap:
    def __init__(self, obj):
        self.obj = obj
    def __getitem__(self, key):
        return getattr(self.obj, key)

To Gregory Smith:  If you merely add the __getitem__ method
with a 'self' as the first argument of getattr, you don't
even need attrmap.

As an aside, when I want dictionary-like behavior from my
classes, I use a dictionary or something that implements a
subset of the mapping protocol.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2005-02-11 19:51

Message:
Logged In: YES 
user_id=21627

I think I would rather not to see this as a builtin, e.g.
putting it into UserDict.AttrMap instead.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1110010&group_id=5470

From noreply at sourceforge.net  Sun May  7 17:41:06 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 07 May 2006 08:41:06 -0700
Subject: [ python-Bugs-1483384 ] Add set.member() method
Message-ID: <E1FclNa-0006CR-Ag@sc8-sf-web4-b.sourceforge.net>

Bugs item #1483384, was opened at 2006-05-07 11:41
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=1483384&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: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Tsai (michaeltsai)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add set.member() method

Initial Comment:
Right now, when I check membership in a set, the __in__ method just 
returns True/False if there is an object in the set that's == to the 
argument. I would like to have a member() method that returns the object 
in the set or raises KeyError if the argument is not in the set. This would 
be useful for interning and other cases where right now I'd use a 
degenerate dictionary where the keys and values are equal.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1483384&group_id=5470

From noreply at sourceforge.net  Sun May  7 22:36:29 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 07 May 2006 13:36:29 -0700
Subject: [ python-Feature Requests-1483384 ] Add set.member() method
Message-ID: <E1FcpzR-0001DZ-0v@sc8-sf-web1.sourceforge.net>

Feature Requests item #1483384, was opened at 2006-05-07 15:41
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1483384&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: Extension Modules
>Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Tsai (michaeltsai)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: Add set.member() method

Initial Comment:
Right now, when I check membership in a set, the __in__ method just 
returns True/False if there is an object in the set that's == to the 
argument. I would like to have a member() method that returns the object 
in the set or raises KeyError if the argument is not in the set. This would 
be useful for interning and other cases where right now I'd use a 
degenerate dictionary where the keys and values are equal.

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-05-07 20:36

Message:
Logged In: YES 
user_id=849994

Moving to Feature Requests. Note that I do not think Raymond
will agree to this.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1483384&group_id=5470

From noreply at sourceforge.net  Mon May  8 07:37:52 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 07 May 2006 22:37:52 -0700
Subject: [ python-Feature Requests-1483384 ] Add set.member() method
Message-ID: <E1FcyRM-0002la-1b@sc8-sf-web2.sourceforge.net>

Feature Requests item #1483384, was opened at 2006-05-07 10:41
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1483384&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: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Tsai (michaeltsai)
Assigned to: Raymond Hettinger (rhettinger)
Summary: Add set.member() method

Initial Comment:
Right now, when I check membership in a set, the __in__ method just 
returns True/False if there is an object in the set that's == to the 
argument. I would like to have a member() method that returns the object 
in the set or raises KeyError if the argument is not in the set. This would 
be useful for interning and other cases where right now I'd use a 
degenerate dictionary where the keys and values are equal.

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2006-05-08 00:37

Message:
Logged In: YES 
user_id=80475

I'm curious to see some of your dictionary examples that 
do not seem to tranlate cleanly with the existing set API.

In published code, I've not seen people writing anything 
like what is being requested, i.e. I haven't seen 
fragments like:
   if x in s:
      return x
   else:
      raise KeyError



----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-05-07 15:36

Message:
Logged In: YES 
user_id=849994

Moving to Feature Requests. Note that I do not think Raymond
will agree to this.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1483384&group_id=5470

From noreply at sourceforge.net  Mon May  8 14:07:47 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 08 May 2006 05:07:47 -0700
Subject: [ python-Feature Requests-1483384 ] Add set.member() method
Message-ID: <E1Fd4Wh-0001LJ-FD@sc8-sf-web4-b.sourceforge.net>

Feature Requests item #1483384, was opened at 2006-05-07 11:41
Message generated for change (Comment added) made by michaeltsai
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1483384&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: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Tsai (michaeltsai)
Assigned to: Raymond Hettinger (rhettinger)
Summary: Add set.member() method

Initial Comment:
Right now, when I check membership in a set, the __in__ method just 
returns True/False if there is an object in the set that's == to the 
argument. I would like to have a member() method that returns the object 
in the set or raises KeyError if the argument is not in the set. This would 
be useful for interning and other cases where right now I'd use a 
degenerate dictionary where the keys and values are equal.

----------------------------------------------------------------------

>Comment By: Michael Tsai (michaeltsai)
Date: 2006-05-08 08:07

Message:
Logged In: YES 
user_id=817528

Well, the example you wrote doesn't capture the pattern I was thinking of. I'm 
thinking of cases like:

d = {}
#...
x = d.setDefault(x, x)

where I want to get the canonical x. This might be x itself, or it might be 
another object that's ==. I doubt you've seen set code that does this with 
sets, because I don't think it's possible with the existing set API to do this 
efficiently.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2006-05-08 01:37

Message:
Logged In: YES 
user_id=80475

I'm curious to see some of your dictionary examples that 
do not seem to tranlate cleanly with the existing set API.

In published code, I've not seen people writing anything 
like what is being requested, i.e. I haven't seen 
fragments like:
   if x in s:
      return x
   else:
      raise KeyError



----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-05-07 16:36

Message:
Logged In: YES 
user_id=849994

Moving to Feature Requests. Note that I do not think Raymond
will agree to this.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1483384&group_id=5470

From noreply at sourceforge.net  Mon May  8 14:53:21 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 08 May 2006 05:53:21 -0700
Subject: [ python-Bugs-1483785 ] Doctest bug
Message-ID: <E1Fd5En-0007hK-BH@sc8-sf-web4-b.sourceforge.net>

Bugs item #1483785, was opened at 2006-05-08 14:53
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=1483785&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: stnsls (stnsls)
Assigned to: Nobody/Anonymous (nobody)
Summary: Doctest bug

Initial Comment:
When i run doctest on the module, i get that error: 
 
 
 
[sm at localhost Spyca]$ python Spyca.py 
********************************************************************** 
File "Spyca.py", line 840, in 
__main__.City.Select_all 
Failed example: 
    print City.Select_all(Country.Get_rowid('<default 
country>')) 
Exception raised: 
    Traceback (most recent call last): 
      File "/usr/lib/python2.4/doctest.py", line 
1243, in __run 
        compileflags, 1) in test.globs 
      File "<doctest __main__.City.Select_all[0]>", 
line 1, in ? 
        print 
City.Select_all(Country.Get_rowid('<default 
country>')) 
      File "Spyca.py", line 846, in Select_all 
        return [cls(i) for i in 
Db.Exec(sql).fetchall()] 
      File "Spyca.py", line 760, in __init__ 
        elif isinstance(this, tuple) or 
isinstance(this, list): self.Select_seq(this) 
      File "Spyca.py", line 817, in Select_seq 
        if not isinstance(seq[3], Latitude): raise 
SpycaException(SpycaInitError, type(seq[3])) 
    SpycaException: Instanciation or argument error. 
[<type 'unicode'>] 
********************************************************************** 
1 items had failures: 
   1 of   1 in __main__.City.Select_all 
***Test Failed*** 1 failures. 
 
 
 
Now, when i do all the same in the interpreter: 
 
 
 
 
[sm at localhost Spyca]$ python 
Python 2.4.1 (#2, Aug 25 2005, 18:20:57) 
[GCC 4.0.1 (4.0.1-2mdk for Mandriva Linux release 
2006.0)] on linux2 
Type "help", "copyright", "credits" or "license" for 
more information. 
>>> import Spyca as S 
>>> lat = S.Latitude() 
>>> lon = S.Longitude() 
>>> seq = (None, 'myCity', None, lat, lon, 0, '') 
>>> c = S.City(seq) 
>>> print c 
myCity 
>>> repr(c) 
"[None, 'myCity', None, [0, 0 ,0, 0.0], [0, 0 ,0, 
0.0], 0, '']" 
>>> 
 
 
 
As you can see, no error in the interpreter. 
 
 
-------- 
Have a nice day. Thanks for the best scripting 
language ;) 
 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1483785&group_id=5470

From noreply at sourceforge.net  Mon May  8 15:10:58 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 08 May 2006 06:10:58 -0700
Subject: [ python-Bugs-1483785 ] Doctest bug
Message-ID: <E1Fd5Vq-0001Aa-56@sc8-sf-web3.sourceforge.net>

Bugs item #1483785, was opened at 2006-05-08 14:53
Message generated for change (Settings changed) made by stnsls
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1483785&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: Deleted
Resolution: None
Priority: 5
Submitted By: stnsls (stnsls)
Assigned to: Nobody/Anonymous (nobody)
Summary: Doctest bug

Initial Comment:
When i run doctest on the module, i get that error: 
 
 
 
[sm at localhost Spyca]$ python Spyca.py 
********************************************************************** 
File "Spyca.py", line 840, in 
__main__.City.Select_all 
Failed example: 
    print City.Select_all(Country.Get_rowid('<default 
country>')) 
Exception raised: 
    Traceback (most recent call last): 
      File "/usr/lib/python2.4/doctest.py", line 
1243, in __run 
        compileflags, 1) in test.globs 
      File "<doctest __main__.City.Select_all[0]>", 
line 1, in ? 
        print 
City.Select_all(Country.Get_rowid('<default 
country>')) 
      File "Spyca.py", line 846, in Select_all 
        return [cls(i) for i in 
Db.Exec(sql).fetchall()] 
      File "Spyca.py", line 760, in __init__ 
        elif isinstance(this, tuple) or 
isinstance(this, list): self.Select_seq(this) 
      File "Spyca.py", line 817, in Select_seq 
        if not isinstance(seq[3], Latitude): raise 
SpycaException(SpycaInitError, type(seq[3])) 
    SpycaException: Instanciation or argument error. 
[<type 'unicode'>] 
********************************************************************** 
1 items had failures: 
   1 of   1 in __main__.City.Select_all 
***Test Failed*** 1 failures. 
 
 
 
Now, when i do all the same in the interpreter: 
 
 
 
 
[sm at localhost Spyca]$ python 
Python 2.4.1 (#2, Aug 25 2005, 18:20:57) 
[GCC 4.0.1 (4.0.1-2mdk for Mandriva Linux release 
2006.0)] on linux2 
Type "help", "copyright", "credits" or "license" for 
more information. 
>>> import Spyca as S 
>>> lat = S.Latitude() 
>>> lon = S.Longitude() 
>>> seq = (None, 'myCity', None, lat, lon, 0, '') 
>>> c = S.City(seq) 
>>> print c 
myCity 
>>> repr(c) 
"[None, 'myCity', None, [0, 0 ,0, 0.0], [0, 0 ,0, 
0.0], 0, '']" 
>>> 
 
 
 
As you can see, no error in the interpreter. 
 
 
-------- 
Have a nice day. Thanks for the best scripting 
language ;) 
 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1483785&group_id=5470

From noreply at sourceforge.net  Mon May  8 19:05:07 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 08 May 2006 10:05:07 -0700
Subject: [ python-Bugs-1483963 ] struct.unpack problem with @, =, < specifiers
Message-ID: <E1Fd9AR-0003ox-RA@sc8-sf-web2.sourceforge.net>

Bugs item #1483963, was opened at 2006-05-08 13: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=1483963&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: Christian Hudon (chrish42)
Assigned to: Nobody/Anonymous (nobody)
Summary: struct.unpack problem with @, =, < specifiers

Initial Comment:
When using struct to unpack floats, I'm getting
inconsistent results when using the '<d' specification
instead of '@d' on a little-endian machine (Intel).
Here's a short python snippet that demonstrates the
problem.

import sys, struct

s = '\x00\x00\x00\x00\x00\x00\xf8\x7f'

>>> sys.byteorder
'little'

# This is correct...
>>> struct.unpack('@d', s)
(nan,)

# These should be equivalent for unpacking a single 
# double on little-endian arch... but they're not.
>>> struct.unpack('<d', s)
(inf,)
>>> struct.unpack('=d', s)
(inf,)


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1483963&group_id=5470

From noreply at sourceforge.net  Mon May  8 19:59:13 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 08 May 2006 10:59:13 -0700
Subject: [ python-Bugs-1483997 ] pydoc doesn't create html-file
Message-ID: <E1FdA0n-0001NE-SD@sc8-sf-web3.sourceforge.net>

Bugs item #1483997, was opened at 2006-05-08 19:59
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1483997&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: Gregor Lingl (glingl)
Assigned to: Nobody/Anonymous (nobody)
Summary: pydoc doesn't create html-file

Initial Comment:
The call

c:\Python25\Lib\pydoc.py -w testdoc

results in an error-message:

Traceback ...
  File ...
  ...
 
  ...
  File "c:\Python25\Lib\inspect.py",line 564,in walktree
   classes.sort(key=attrgetter('__module__','__name__'))
TypeError: attrgetter expected 1 arguments, got 2

The same call with Python 2.4 works correctly

regards,

Gregor Lingl


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1483997&group_id=5470

From noreply at sourceforge.net  Mon May  8 20:00:54 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 08 May 2006 11:00:54 -0700
Subject: [ python-Bugs-1417699 ] float/atof have become locale aware
Message-ID: <E1FdA2Q-00044I-3Q@sc8-sf-web4-b.sourceforge.net>

Bugs item #1417699, was opened at 2006-01-29 01:04
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1417699&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: 7
Submitted By: Bernhard Herzog (bernhard)
Assigned to: Martin v. L??wis (loewis)
Summary: float/atof have become locale aware

Initial Comment:
The builtin float and the function string.atof have
become locale aware in Python 2.4:

Python 2.4.2 (#1, Nov 29 2005, 16:07:55) 
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import locale
>>> import string
>>> locale.setlocale(locale.LC_ALL, "de_DE")
'de_DE'
>>> float("1,5")
1.5
>>> string.atof("1,5")
1.5


This doesn't match what's specified in pep 331:

        - float() and str() stay locale-unaware.

It also doesn't match the documentation for atof:

  Convert a string to a floating point number.
  The string must have the standard syntax for a
  floating point literal in Python, optionally
  preceded by a sign ("+" or "-"). Note that this
  behaves identical to the built-in function float()
  when passed a string.

The documentation for float() doesn't state which
format is accepted by float(), though.

The reason for this behavior is ultimately, that
PyOS_ascii_strtod accepts the locale specific
convention in addition to the "C"-locale/python
convention, even though the comment in the code
preceding its definition states:

  This function behaves like the standard strtod() 
  function does in the C locale.




----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-05-08 18:00

Message:
Logged In: YES 
user_id=849994

I grepped around and found PyOS_ascii_strtod in the
following places:

* stropmodule::atof
* cPickle::load_float (the writing of locale dependent
floats was fixed recently)
* floatobject::PyFloat_FromString
* complexobject::complex_subtype_from_string

In my opinion, all these should not tolerate localized
floats, so Gustavo, please ask the original author how to
achieve this.

----------------------------------------------------------------------

Comment By: Gustavo J. A. M. Carneiro (gustavo)
Date: 2006-05-04 09:47

Message:
Logged In: YES 
user_id=908

My comment is, is "PyOS_ascii_strtod accepting both forms"
something that is harmful and should be fixed?

I didn't exactly write the PyOS_ascii_strtod code; I only
integrated it with Python.  But if we really need to fix
this, I'll try to figure out how to make it not accept
floating points in locale aware format; if necessary I'll
ask help from  the original author of the code, Alexander
Larsson.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-05-04 04:42

Message:
Logged In: YES 
user_id=21627

It's a bug. As bernhard says, it originates from
PyOS_ascii_strtod accepting both forms, which in turn
happens because it just leaves the locale-specific decimal
point in the string, only replacing the . with the
locale-specific point. Then, the platform's strtod will
happily accept the locale-specific version. 

I'd like Gustavo Carneiro to comment.

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-17 12:19

Message:
Logged In: YES 
user_id=1188172

Martin, you checked in the patch which is mentioned in PEP
331. Is this correct behavior?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1417699&group_id=5470

From noreply at sourceforge.net  Mon May  8 23:45:48 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 08 May 2006 14:45:48 -0700
Subject: [ python-Bugs-1484172 ] hyper-threading locks up sleeping threads
Message-ID: <E1FdDY4-00065w-8X@sc8-sf-web3.sourceforge.net>

Bugs item #1484172, was opened at 2006-05-08 16: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=1484172&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: Threads
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Olaf Meding (olafmeding)
Assigned to: Nobody/Anonymous (nobody)
Summary: hyper-threading locks up sleeping threads

Initial Comment:
Below are 2 files.  The first is a Python program that 
demonstrates the problem within less than 1 hour 
(often just a few minutes).  The second is a C++ 
program that shows that the Win32 Sleep() function 
works as expected (the program was started 3 days ago 
and is still running).

Note, I also attached the source code.

Note, the Python programs hangs (stops responding) 
with hyper-threading turned on (a BIOS setting), but 
works as expected with hyper-threading turned off.

This problem happens on Windows only (the below Python 
program ran for 24 hours on Linux without a problem).

Variations of the Python program also lock up:

Tried importing win32api instead of importing time and 
using the win32api.GetTickCount() and win32api.Sleep() 
methods.

Tried using lock = threading.Event() and lock.wait() 
instead of time.sleep().

Tried importing Queue and using q = Queue.Queue() and 
q.get(True, sleepTime).

Note, the Windows task manager shows 2 CPUs on the 
Performance tab with hyper-threading is turned on.

Both Python 2.3.5 and 2.4.3 (downloaded from 
python.org) have this problem.

The operating system is MS Windows XP Professional.

winmsd.exe (Start Menu > Run) shows:
2CPUs: x86 Family 15 Model 4 Stepping 1 GenuineIntel 
~3000 MHz
Version: 5.1.2600 Service Pack 2 Build 2600

Could someone with a hyper-threading (or dual-core or 
multi-processor) CPU please confirm this bug?

Many Thanks

Olaf


Here is the expected output of both programs (the 
progam has locked up if the numbers stop printing 
every 10 seconds or so):
python testsleep.py
thread 1 started, sleep time 0.010
thread 2 started, sleep time 0.003
1 1 1 2 1 1 1 2 1 1 1 2 1 1 1 1 2 1 1 1

# testsleep.py
import threading
import time

class Task(threading.Thread):
        def __init__(self, n, t):
                threading.Thread.__init__(self)
                self.n = n  # thread id
                self.t = t  # sleep time
        def run(self):
                print 'thread %d started, sleep time 
%.3f' % (self.n, self.t)
                count = 0
                printCount = int(10 / self.t)
                while True:
                        start = time.clock()
                        time.sleep(self.t)
                        stop = time.clock()
                        if stop - start > 1.0:
                                print 'thread', 
self.n, stop - start

                        count += 1
                        if count > printCount:
                                count = 0
                                print self.n,  # print 
sign of live

def test():
        thread1 = Task(1, 0.01)  # thread 1, sleep 10 
ms
        thread2 = Task(2, 0.003) # thread 2, sleep  3 
ms
        thread1.start()
        thread2.start()

test()

-------------------------------------------------------
---------------------------

// testsleep.cpp
// Compiled with Visual C++ version 6 (in debug mode) 
as a Win32 console application.

#include <windows.h>
#include <stdio.h>
#include <time.h>

typedef struct {
    int id;
    int ms;

} param_s;

DWORD WINAPI threadFunction(LPVOID param)
{
    param_s* p = (param_s*)param;
    long elapsedTime;
    long time1, time2;
    long printCount = long(10000 / p->ms);  // loop 
iterations in 10 seconds
    long count = 0;

    printf("thread %d started, sleep time: %d 
ms" "\n", p->id, p->ms);

    while(true) {
        time1 = GetTickCount();
        Sleep(p->ms);
        time2 = GetTickCount();

        elapsedTime = time2 - time1;
        if(elapsedTime > 1000)
            printf("thread %d slept for %d ms" "\n", p-
>id, elapsedTime);

        count++;
        if(count > printCount) {
            count = 0;
            printf("%d ", p->id);  // print sign of 
live
        }
    }

    return 0;
}

int main(int argc, char* argv[])
{
    param_s p1, p2;

    p1.id = 1;
    p1.ms = 10;

    p2.id = 2;
    p2.ms = 3;

    CreateThread(NULL, 0, threadFunction, (void*)&p1, 
0, NULL);
    CreateThread(NULL, 0, threadFunction, (void*)&p2, 
0, NULL);

    getchar();  // wait until the user presses the 
enter key.

    return 0; 
}

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1484172&group_id=5470

From noreply at sourceforge.net  Mon May  8 23:58:22 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 08 May 2006 14:58:22 -0700
Subject: [ python-Bugs-1484172 ] hyper-threading locks up sleeping threads
Message-ID: <E1FdDkE-0002vi-8u@sc8-sf-web2.sourceforge.net>

Bugs item #1484172, was opened at 2006-05-08 17:45
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1484172&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: Threads
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Olaf Meding (olafmeding)
Assigned to: Nobody/Anonymous (nobody)
Summary: hyper-threading locks up sleeping threads

Initial Comment:
Below are 2 files.  The first is a Python program that 
demonstrates the problem within less than 1 hour 
(often just a few minutes).  The second is a C++ 
program that shows that the Win32 Sleep() function 
works as expected (the program was started 3 days ago 
and is still running).

Note, I also attached the source code.

Note, the Python programs hangs (stops responding) 
with hyper-threading turned on (a BIOS setting), but 
works as expected with hyper-threading turned off.

This problem happens on Windows only (the below Python 
program ran for 24 hours on Linux without a problem).

Variations of the Python program also lock up:

Tried importing win32api instead of importing time and 
using the win32api.GetTickCount() and win32api.Sleep() 
methods.

Tried using lock = threading.Event() and lock.wait() 
instead of time.sleep().

Tried importing Queue and using q = Queue.Queue() and 
q.get(True, sleepTime).

Note, the Windows task manager shows 2 CPUs on the 
Performance tab with hyper-threading is turned on.

Both Python 2.3.5 and 2.4.3 (downloaded from 
python.org) have this problem.

The operating system is MS Windows XP Professional.

winmsd.exe (Start Menu > Run) shows:
2CPUs: x86 Family 15 Model 4 Stepping 1 GenuineIntel 
~3000 MHz
Version: 5.1.2600 Service Pack 2 Build 2600

Could someone with a hyper-threading (or dual-core or 
multi-processor) CPU please confirm this bug?

Many Thanks

Olaf


Here is the expected output of both programs (the 
progam has locked up if the numbers stop printing 
every 10 seconds or so):
python testsleep.py
thread 1 started, sleep time 0.010
thread 2 started, sleep time 0.003
1 1 1 2 1 1 1 2 1 1 1 2 1 1 1 1 2 1 1 1

# testsleep.py
import threading
import time

class Task(threading.Thread):
        def __init__(self, n, t):
                threading.Thread.__init__(self)
                self.n = n  # thread id
                self.t = t  # sleep time
        def run(self):
                print 'thread %d started, sleep time 
%.3f' % (self.n, self.t)
                count = 0
                printCount = int(10 / self.t)
                while True:
                        start = time.clock()
                        time.sleep(self.t)
                        stop = time.clock()
                        if stop - start > 1.0:
                                print 'thread', 
self.n, stop - start

                        count += 1
                        if count > printCount:
                                count = 0
                                print self.n,  # print 
sign of live

def test():
        thread1 = Task(1, 0.01)  # thread 1, sleep 10 
ms
        thread2 = Task(2, 0.003) # thread 2, sleep  3 
ms
        thread1.start()
        thread2.start()

test()

-------------------------------------------------------
---------------------------

// testsleep.cpp
// Compiled with Visual C++ version 6 (in debug mode) 
as a Win32 console application.

#include <windows.h>
#include <stdio.h>
#include <time.h>

typedef struct {
    int id;
    int ms;

} param_s;

DWORD WINAPI threadFunction(LPVOID param)
{
    param_s* p = (param_s*)param;
    long elapsedTime;
    long time1, time2;
    long printCount = long(10000 / p->ms);  // loop 
iterations in 10 seconds
    long count = 0;

    printf("thread %d started, sleep time: %d 
ms" "\n", p->id, p->ms);

    while(true) {
        time1 = GetTickCount();
        Sleep(p->ms);
        time2 = GetTickCount();

        elapsedTime = time2 - time1;
        if(elapsedTime > 1000)
            printf("thread %d slept for %d ms" "\n", p-
>id, elapsedTime);

        count++;
        if(count > printCount) {
            count = 0;
            printf("%d ", p->id);  // print sign of 
live
        }
    }

    return 0;
}

int main(int argc, char* argv[])
{
    param_s p1, p2;

    p1.id = 1;
    p1.ms = 10;

    p2.id = 2;
    p2.ms = 3;

    CreateThread(NULL, 0, threadFunction, (void*)&p1, 
0, NULL);
    CreateThread(NULL, 0, threadFunction, (void*)&p2, 
0, NULL);

    getchar();  // wait until the user presses the 
enter key.

    return 0; 
}

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2006-05-08 17:58

Message:
Logged In: YES 
user_id=31435

As noted (multiple times by now ;-)) on c.l.py, the Python
program does not hang on my similar HT box:

http://mail.python.org/pipermail/python-list/2006-May/340538.html


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1484172&group_id=5470

From noreply at sourceforge.net  Tue May  9 06:11:24 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 08 May 2006 21:11:24 -0700
Subject: [ python-Bugs-1481770 ] hpux ia64 shared lib ext should be ".so"
Message-ID: <E1FdJZE-0006fq-Ma@sc8-sf-web5.sourceforge.net>

Bugs item #1481770, was opened at 2006-05-04 05:43
Message generated for change (Comment added) made by deckrider
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1481770&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: David Everly (deckrider)
Assigned to: Nobody/Anonymous (nobody)
Summary: hpux ia64 shared lib ext should be ".so"

Initial Comment:
On hpux ia64, the shared library extension should be
".so".  This is currently problematic in that other
add-on python modules (such as those for subversion)
correctly detect the host_os/host_cpu and build
_module.so, which is not seen by python built using ".sl".

According to
http://devresource.hp.com/drc/resources/portguideipf/index.jsp#dynlinkfac


"Shared library names

Since dynamic linking APIs operate on shared libraries,
it is also important to note that the shared library
naming scheme on Linux is lib*.so; whereas, on HP-UX
11i Version 1.5 the naming scheme is lib*.sl for PA and
lib*.so on IPF. Also APIs may reside in different
libraries files on Linux and HP-UX, so you may need to
dynamically load a different shared library name on
HP-UX and Linux."

To translate this quote, PA=hppa and IPF=ia64.


----------------------------------------------------------------------

>Comment By: David Everly (deckrider)
Date: 2006-05-08 22:11

Message:
Logged In: YES 
user_id=1113403

I tested against hpux ia64 today, and found that the
original patch required correction.  Here is the result.

----------------------------------------------------------------------

Comment By: David Everly (deckrider)
Date: 2006-05-07 07:22

Message:
Logged In: YES 
user_id=1113403

Here is a patch against
http://svn.python.org/projects/python/branches/release24-maint

I don't have many evironments to test against, and only
Linux right now (will test on HPUX ia64 tomorrow and report
back).

----------------------------------------------------------------------

Comment By: David Everly (deckrider)
Date: 2006-05-05 06:07

Message:
Logged In: YES 
user_id=1113403

The patch I'm using now only works on hppa/ia64 and isn't
anything that can coexist nicely in the source package on
other hardware/os combinations.

I've looked at
http://svn.python.org/projects/python/branches/release24-maint/

I'm accustomed to a system using autoconf/libtool/automake
(recent versions) and never committing the output of those
tools, but only running them at source package generation time.

I say this, only to point out that I'm not understanding the
principles behind what I see in subversion.  I see
configure, and also configure.in.  Which should be patched?
 And if I don't patch configure, what is the process for
regenerating it (and with what versions of automake,
autoconf, and libtool?).

Also, the most recent libtool already correctly determines
shared library extension.

So I could probably provide a patch, but would need to
understand the environment better in order to do so.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-05-05 01:02

Message:
Logged In: YES 
user_id=33168

Do you think you could work on a patch to address this issue?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1481770&group_id=5470

From noreply at sourceforge.net  Tue May  9 06:15:58 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 08 May 2006 21:15:58 -0700
Subject: [ python-Bugs-1481770 ] hpux ia64 shared lib ext should be ".so"
Message-ID: <E1FdJde-0000Ee-6Z@sc8-sf-web3.sourceforge.net>

Bugs item #1481770, was opened at 2006-05-04 05:43
Message generated for change (Settings changed) made by deckrider
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1481770&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: David Everly (deckrider)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: hpux ia64 shared lib ext should be ".so"

Initial Comment:
On hpux ia64, the shared library extension should be
".so".  This is currently problematic in that other
add-on python modules (such as those for subversion)
correctly detect the host_os/host_cpu and build
_module.so, which is not seen by python built using ".sl".

According to
http://devresource.hp.com/drc/resources/portguideipf/index.jsp#dynlinkfac


"Shared library names

Since dynamic linking APIs operate on shared libraries,
it is also important to note that the shared library
naming scheme on Linux is lib*.so; whereas, on HP-UX
11i Version 1.5 the naming scheme is lib*.sl for PA and
lib*.so on IPF. Also APIs may reside in different
libraries files on Linux and HP-UX, so you may need to
dynamically load a different shared library name on
HP-UX and Linux."

To translate this quote, PA=hppa and IPF=ia64.


----------------------------------------------------------------------

Comment By: David Everly (deckrider)
Date: 2006-05-08 22:11

Message:
Logged In: YES 
user_id=1113403

I tested against hpux ia64 today, and found that the
original patch required correction.  Here is the result.

----------------------------------------------------------------------

Comment By: David Everly (deckrider)
Date: 2006-05-07 07:22

Message:
Logged In: YES 
user_id=1113403

Here is a patch against
http://svn.python.org/projects/python/branches/release24-maint

I don't have many evironments to test against, and only
Linux right now (will test on HPUX ia64 tomorrow and report
back).

----------------------------------------------------------------------

Comment By: David Everly (deckrider)
Date: 2006-05-05 06:07

Message:
Logged In: YES 
user_id=1113403

The patch I'm using now only works on hppa/ia64 and isn't
anything that can coexist nicely in the source package on
other hardware/os combinations.

I've looked at
http://svn.python.org/projects/python/branches/release24-maint/

I'm accustomed to a system using autoconf/libtool/automake
(recent versions) and never committing the output of those
tools, but only running them at source package generation time.

I say this, only to point out that I'm not understanding the
principles behind what I see in subversion.  I see
configure, and also configure.in.  Which should be patched?
 And if I don't patch configure, what is the process for
regenerating it (and with what versions of automake,
autoconf, and libtool?).

Also, the most recent libtool already correctly determines
shared library extension.

So I could probably provide a patch, but would need to
understand the environment better in order to do so.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-05-05 01:02

Message:
Logged In: YES 
user_id=33168

Do you think you could work on a patch to address this issue?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1481770&group_id=5470

From noreply at sourceforge.net  Tue May  9 06:36:15 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 08 May 2006 21:36:15 -0700
Subject: [ python-Feature Requests-1483384 ] Add set.member() method
Message-ID: <E1FdJxH-0005JR-4f@sc8-sf-web4-b.sourceforge.net>

Feature Requests item #1483384, was opened at 2006-05-07 10:41
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1483384&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: Extension Modules
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Michael Tsai (michaeltsai)
Assigned to: Raymond Hettinger (rhettinger)
Summary: Add set.member() method

Initial Comment:
Right now, when I check membership in a set, the __in__ method just 
returns True/False if there is an object in the set that's == to the 
argument. I would like to have a member() method that returns the object 
in the set or raises KeyError if the argument is not in the set. This would 
be useful for interning and other cases where right now I'd use a 
degenerate dictionary where the keys and values are equal.

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2006-05-08 23:36

Message:
Logged In: YES 
user_id=80475

The use case is interesting and points-out that the set 
API provides no way to retrieve the exact set member that 
matches an equality comparison; however, that is 
essentially a description of a mapping operation, not a 
set operation.  The x=d.setdefault(x,x) approach 
satisfactorily fulfills the use case (though with a bit 
more memory consumption for the value that duplicates the 
key).

Also, I'm disinclined to introduce such a method to the 
set API which is made simple by a uniform focus on 
equality comparisons and intuitive operations.  Adding an 
identity focused method makes the whole API harder to 
understand and less of a power tool suitable for 
beginners. IOW, I expect that the method would harm more 
than it would help.

I'm rejecting the feature request but want to thank you 
for the thought provoking idea.

----------------------------------------------------------------------

Comment By: Michael Tsai (michaeltsai)
Date: 2006-05-08 07:07

Message:
Logged In: YES 
user_id=817528

Well, the example you wrote doesn't capture the pattern I was thinking of. I'm 
thinking of cases like:

d = {}
#...
x = d.setDefault(x, x)

where I want to get the canonical x. This might be x itself, or it might be 
another object that's ==. I doubt you've seen set code that does this with 
sets, because I don't think it's possible with the existing set API to do this 
efficiently.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2006-05-08 00:37

Message:
Logged In: YES 
user_id=80475

I'm curious to see some of your dictionary examples that 
do not seem to tranlate cleanly with the existing set API.

In published code, I've not seen people writing anything 
like what is being requested, i.e. I haven't seen 
fragments like:
   if x in s:
      return x
   else:
      raise KeyError



----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-05-07 15:36

Message:
Logged In: YES 
user_id=849994

Moving to Feature Requests. Note that I do not think Raymond
will agree to this.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1483384&group_id=5470

From noreply at sourceforge.net  Tue May  9 06:51:31 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 08 May 2006 21:51:31 -0700
Subject: [ python-Feature Requests-1465406 ] Allowing the definition of
	constants
Message-ID: <E1FdKC3-0004v5-0a@sc8-sf-web4-b.sourceforge.net>

Feature Requests item #1465406, was opened at 2006-04-05 18:30
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1465406&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: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Chris Wilson (ciw42)
Assigned to: Nobody/Anonymous (nobody)
Summary: Allowing the definition of constants

Initial Comment:
One of the current optimizations due in v2.5 includes
constant folding of expressions, which as it stands
serves as a way of somply getting rid of a redundant
arithmetic operations and the like.

In practice, it's rare a developer would leave an
expression such as "2+3" sat in his/her code, but by
allowing the declaration of constants within a script,
it could make this new feature *much* more useful.

As an example, in a recent script I had the following
at the top, outside the main loop:

SCREEN_WIDTH=640
SCREEN_HEIGHT=480
SCREEN_RATIO=SCREEN_WIDTH/SCREEN_HEIGHT

As SCREEN_RATIO is used a number of times during my
main loop, it makes sense to pre-calculate it to avoid
the extra processing, but if the compiler were aware
that SCREEN_WIDTH and SCREEN_HEIGHT were constants, it
could optimise out the calculation and I could include
the calculation in-place.

I frequently make use of "constants" to make my code
more readable, and wonder whether there is any
performance penalty or lack of optimisation going on
due to them in fact being regular variables?

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2006-05-08 23:51

Message:
Logged In: YES 
user_id=80475

Introducing a new keyword, "const", requires a PEP.  Such 
a PEP should be backed-up by timings that demonstrate 
performance improvements impressive enough to warrant a 
change.  In my experience, replacing global lookups with 
constants almost never produces much a speed-up in real 
code.

If you write a PEP, it needs to first go through 
discussion on comp.lang.python.  Also, you should find out 
how this would affect Jython and IronPython.


----------------------------------------------------------------------

Comment By: Chris Wilson (ciw42)
Date: 2006-04-28 08:38

Message:
Logged In: YES 
user_id=1018283

I see your point, and it's a good example of why using
namespaces is so important, but in practice, with my
proposal in place, the code you propose simply wouldn't compile.

Assuming the compiler simply substituted the literal
"3.1415" for "pi" as I've proposed, you'd end up with
"3.1415 = 4", and a syntax error for trying to assign to a
literal value. You'd not get as far as running the code, so
in practice there'd be no issues with it running incorrectly.

Being able to declare constants is important as it allows
the compiler to make the sort of optimistations I mentioned
previously.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-10 08:55

Message:
Logged In: YES 
user_id=21627

The problem is that declaring the value assignment const
doesn't help. Consider this:

from math import pi

def area(r):
  return r*r*pi

pi = 4

print area(10)

So even though math.pi might be declared as a constant,
hard-coding its value into the function area would break
this program - the value of the variable pi might change not
change inside math, but it might change where it is imported.

----------------------------------------------------------------------

Comment By: Chris Wilson (ciw42)
Date: 2006-04-06 16:59

Message:
Logged In: YES 
user_id=1018283

I've re-opened this, as I don't feel it would be difficult
to implement or require any fundamental changes to the
parser or runtime. In fact, it would be very easy, and
potentially very useful beyond the scope of my initial
suggestion.

Appologies to rhettinger if this seems rude, but I would ask
that you give the following some consideration.

The addition of a "const" or similar compiler directive
would allow the compiler to simply do an on-the-fly
substitution for the specified value/string etc. There would
be no code analysis required, and adding this type of
functionality would carry no real overheads or further
complicate the compilation process. There would be no
changes required within the runtime.

Once substituted, the already incorporated compiler constant
folding features would then come into play.

I suppose, that what I'm suggesting is effectively a basic
pre-compiler macro feature. This in itself may prove useful
in many other situations.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2006-04-05 18:57

Message:
Logged In: YES 
user_id=80475

Python is too dynamic for this kind of optimization to be 
done automatically.  If those "constants" are defined at 
the module level, they can be changed by code outside the 
module.  Even within the module, it would take a thorough 
analysis of the code to determine that nothing was trying 
to alter the value of the global variable.  If 
the "constant" is defined inside a function, it is still a 
local variable subject to change by later lines in 
function.

Your best bet is to use the bind_consts recipe at ASPN.  
It will automatically turn some global references into 
locals:  
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/277
940

It may be possible to adapt the recipe to go an additional 
step and fold the globals "constants".

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1465406&group_id=5470

From noreply at sourceforge.net  Tue May  9 12:14:07 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 09 May 2006 03:14:07 -0700
Subject: [ python-Bugs-1484556 ] Output of KlocWork on Python2.4.3 sources
Message-ID: <E1FdPEF-00043b-0f@sc8-sf-web3.sourceforge.net>

Bugs item #1484556, was opened at 2006-05-09 13:14
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=1484556&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Miki Tebeka (tebeka)
Assigned to: Nobody/Anonymous (nobody)
Summary: Output of KlocWork on Python2.4.3 sources

Initial Comment:
We're evaluating KlocWork (http://www.klocwork.com),
I've ran it on the source of Python 2.4.3 and the
output is attached (1562 warnings).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1484556&group_id=5470

From noreply at sourceforge.net  Tue May  9 12:59:12 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 09 May 2006 03:59:12 -0700
Subject: [ python-Bugs-1484580 ] ctypes documenation obscure and incomplete
Message-ID: <E1FdPvs-0001yD-Uv@sc8-sf-web1.sourceforge.net>

Bugs item #1484580, was opened at 2006-05-09 10:59
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1484580&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: Nicko van Someren (nicko)
Assigned to: Nobody/Anonymous (nobody)
Summary: ctypes documenation obscure and incomplete

Initial Comment:
The documentation for ctypes in Python 2.5, drawn largely from the 
original ctypes tutorial, misses a number of important points which 
users will want to know.  In particular the documentation surrounding 
casting of types is currently non-existant and the documentation 
regarding the relationship between pointer(), byref() and array objects 
is at best limited.

In order to fix this I would suggest the following changes:

1) A new sub-sub-sub-section 13.14.1.x should be added to 
document the "cast()" function provided by ctypes.  The cast function 
takes two parameters, a ctypes object of some sort and a ctypes type 
class, and it returns the former cast to the later. e.g.:

    class Foo(Structure):
        _fields_ = [("x", c_int), ("y", c_int)]
    class Bar(Structure):
        _fields_ = [("count", c_int),("values", c_void_p)]

    f = Foo(1,2)
    b = Bar(1, cast(pointer(f), c_void_p))

I'm sure that there are many other subtleties to the cast() function 
which I don't know about, because they are not currently documented!

2) Nowhere is is explicitly stated that, where a pointer to a type is 
expected, a ctypes array object can be assigned instead.  While this is 
arguably intuitive to any C programmer it could with being 
documented.  Otherwise people will write:
    someFun.argtypes = [POINTER(Foo)]
    tenFoos = (Foo * 10)()
    someFun(cast(byref(tenFoos), POINTER(Foo)))
when the last line is better written:
    someFun(tenFoos)
Adding some words on this subject to section 13.14.1.13 (Arrays) or 
13.14.1.14 (Pointers) would be helpful.




----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1484580&group_id=5470

From noreply at sourceforge.net  Tue May  9 14:30:50 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 09 May 2006 05:30:50 -0700
Subject: [ python-Bugs-1404925 ] subprocess.Popen inside thread locks the
	thread in some case
Message-ID: <E1FdRMY-0000oV-SI@sc8-sf-web2.sourceforge.net>

Bugs item #1404925, was opened at 2006-01-13 16:05
Message generated for change (Comment added) made by bigorilla
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1404925&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: Threads
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Toon Verstraelen (tovrstra)
Assigned to: Peter ?
strand (astrand)
Summary: subprocess.Popen inside thread locks the thread in some case

Initial Comment:
The bug can be verified with the example program
attached to this bugs. Two files are attached:
my_thread.py and main.py

When main.py is executed the thread hangs on
subprocess.Popen, while my_thread.py, which is imported
by main.py runs without problems. In fact both should
do exactly the same since main.py doesn nothing but
importing my_thread.

My python version:

Python 2.4.2 (#1, Oct 17 2005, 09:05:20)
[GCC 3.3.6 (Gentoo 3.3.6, ssp-3.3.6-1.0, pie-8.7.8)] on
linux2

If any more info is required, 

----------------------------------------------------------------------

Comment By: Yair Chuchem (bigorilla)
Date: 2006-05-09 12:30

Message:
Logged In: YES 
user_id=232571

this thread explains why this happens and how to solve it:
http://groups.google.com/group/comp.lang.python/browse_thread/thread/5fae8a453c95ae89/42f5c9f9215dbb1e#42f5c9f9215dbb1e
I implemented the fix locally at mine:
at os.py, _execvpe, first line:
remove the "from errno import ...",
add a global "import errno" at the start
and change stuff imported from errno from "X" to "errno.X"


----------------------------------------------------------------------

Comment By: Ralf Schmitt (titty)
Date: 2006-01-13 17:41

Message:
Logged In: YES 
user_id=17929

glibc version 2.3.5.
If I add a time.sleep(1) at the end of my_thread.py I can
also reproduce this error reliably on ubuntu.


----------------------------------------------------------------------

Comment By: Toon Verstraelen (tovrstra)
Date: 2006-01-13 16:58

Message:
Logged In: YES 
user_id=970944

What version of glibc do you have on your ubuntu system? I
have glibc-2.3.5-r2, where r2 stands for second patch
revision from the gentoo distribution. In my case I can not
interrupt 'python main.py'. I have to use ctrl-z and then
'kill %1'.

----------------------------------------------------------------------

Comment By: Ralf Schmitt (titty)
Date: 2006-01-13 16:30

Message:
Logged In: YES 
user_id=17929

I cannot reproduce this error on ubuntu linux using python
2.4.2.
However, I am able to reproduce it using python 2.4.2
running on FreeBSD 4.11.

Stopping the program with ctrl-c results in the following
output:

ralf at stronzo:~/tmp$ python main.py 
before Popen
^CException in thread Thread-1:
Traceback (most recent call last):
  File "/usr/local/lib/python2.4/threading.py", line 442, in
__bootstrap
    self.run()
  File "/home/ralf/tmp/my_thread.py", line 7, in run
    sp = Popen(["ls", "-al"], stdout=PIPE, stderr=STDOUT)
  File "/usr/local/lib/python2.4/subprocess.py", line 542,
in __init__
    errread, errwrite)
  File "/usr/local/lib/python2.4/subprocess.py", line 970,
in _execute_child
    data = os.read(errpipe_read, 1048576) # Exceptions
limited to 1 MB
OSError: [Errno 4] Interrupted system call

Error in atexit._run_exitfuncs:
Traceback (most recent call last):
  File "/usr/local/lib/python2.4/atexit.py", line 24, in
_run_exitfuncs
    func(*targs, **kargs)
  File "/usr/local/lib/python2.4/threading.py", line 632, in
__exitfunc
    t.join()
  File "/usr/local/lib/python2.4/threading.py", line 539, in
join
    self.__block.wait()
  File "/usr/local/lib/python2.4/threading.py", line 203, in
wait
    waiter.acquire()
KeyboardInterrupt
Error in sys.exitfunc:
Traceback (most recent call last):
  File "/usr/local/lib/python2.4/atexit.py", line 24, in
_run_exitfuncs
    func(*targs, **kargs)
  File "/usr/local/lib/python2.4/threading.py", line 632, in
__exitfunc
    t.join()
  File "/usr/local/lib/python2.4/threading.py", line 539, in
join
    self.__block.wait()
  File "/usr/local/lib/python2.4/threading.py", line 203, in
wait
    waiter.acquire()
KeyboardInterrupt
ralf at stronzo:~/tmp$


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1404925&group_id=5470

From noreply at sourceforge.net  Tue May  9 15:56:31 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 09 May 2006 06:56:31 -0700
Subject: [ python-Bugs-1471427 ] tarfile.py chokes on long names
Message-ID: <E1FdShT-00036J-5f@sc8-sf-web1.sourceforge.net>

Bugs item #1471427, was opened at 2006-04-16 22:34
Message generated for change (Comment added) made by gustaebel
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1471427&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: Fixed
Priority: 5
Submitted By: Alexander Schremmer (alexanderweb)
Assigned to: Nobody/Anonymous (nobody)
Summary: tarfile.py chokes on long names

Initial Comment:
The following bug is reproducible on Py 2.4.3 and 2.5. 
It was tested on Windows. You need a tarfile with a 
long file name that triggers the GNU LONGNAME 
extension.

Extracting such a file gives me an IO error because it 
tries to create a file with a slash at the end. This is 
because 

        # Some old tar programs represent a directory 
as a regular
        # file with a trailing slash.
        if tarinfo.isreg() and tarinfo.name.endswith("/
"):
            tarinfo.type = DIRTYPE

sets the type incorrectly after it was called from the 
callback proc which has no possiblity to set the name 
of the intermediary tarinfo class because it is 
instantiated in the next-method.

So this yields a directory which should be a file which 
is obviously wrong. Might be related to commit 41340 
"Patch #1338314, Bug #1336623". (At least the code 
changed there is causing this bug).

----------------------------------------------------------------------

Comment By: Lars Gust?bel (gustaebel)
Date: 2006-05-09 15:56

Message:
Logged In: YES 
user_id=642936

I have posted the fix as patch #1484695. Thanks for your report.

----------------------------------------------------------------------

Comment By: Alexander Schremmer (alexanderweb)
Date: 2006-05-07 13:55

Message:
Logged In: YES 
user_id=254738

Thanks, that seems to work. Try to get this into Py 2.5 :)

----------------------------------------------------------------------

Comment By: Lars Gust?bel (gustaebel)
Date: 2006-04-25 22:59

Message:
Logged In: YES 
user_id=642936

Fixing this issue is not quite as simple as I hoped it to
be. It would be possible to implement a quick fix that
solves the problem, but that would be too ugly for a stdlib
module. Instead, I have been busy writing a preliminary fix
for my development version of tarfile.py which is available
at http://www.gustaebel.de/lars/tarfile/.
It would be nice of you, if you'd download the 0.8.0 version
there and give it a try. Thank you.


----------------------------------------------------------------------

Comment By: Alexander Schremmer (alexanderweb)
Date: 2006-04-16 22:34

Message:
Logged In: YES 
user_id=254738

Hmm, I just want to clarify that tarfile doesn't give the IO 
error (it passes silently) but my code that expects a file 
instead of a directory ;-)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1471427&group_id=5470

From noreply at sourceforge.net  Tue May  9 20:35:29 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 09 May 2006 11:35:29 -0700
Subject: [ python-Bugs-1484580 ] ctypes documenation obscure and incomplete
Message-ID: <E1FdX3R-0006mU-Jr@sc8-sf-web5.sourceforge.net>

Bugs item #1484580, was opened at 2006-05-09 12:59
Message generated for change (Settings changed) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1484580&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: Nicko van Someren (nicko)
>Assigned to: Thomas Heller (theller)
Summary: ctypes documenation obscure and incomplete

Initial Comment:
The documentation for ctypes in Python 2.5, drawn largely from the 
original ctypes tutorial, misses a number of important points which 
users will want to know.  In particular the documentation surrounding 
casting of types is currently non-existant and the documentation 
regarding the relationship between pointer(), byref() and array objects 
is at best limited.

In order to fix this I would suggest the following changes:

1) A new sub-sub-sub-section 13.14.1.x should be added to 
document the "cast()" function provided by ctypes.  The cast function 
takes two parameters, a ctypes object of some sort and a ctypes type 
class, and it returns the former cast to the later. e.g.:

    class Foo(Structure):
        _fields_ = [("x", c_int), ("y", c_int)]
    class Bar(Structure):
        _fields_ = [("count", c_int),("values", c_void_p)]

    f = Foo(1,2)
    b = Bar(1, cast(pointer(f), c_void_p))

I'm sure that there are many other subtleties to the cast() function 
which I don't know about, because they are not currently documented!

2) Nowhere is is explicitly stated that, where a pointer to a type is 
expected, a ctypes array object can be assigned instead.  While this is 
arguably intuitive to any C programmer it could with being 
documented.  Otherwise people will write:
    someFun.argtypes = [POINTER(Foo)]
    tenFoos = (Foo * 10)()
    someFun(cast(byref(tenFoos), POINTER(Foo)))
when the last line is better written:
    someFun(tenFoos)
Adding some words on this subject to section 13.14.1.13 (Arrays) or 
13.14.1.14 (Pointers) would be helpful.




----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1484580&group_id=5470

From noreply at sourceforge.net  Tue May  9 20:36:47 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 09 May 2006 11:36:47 -0700
Subject: [ python-Bugs-1460514 ] ctypes extension does not compile on Mac OS
	10.3.9
Message-ID: <E1FdX4h-0007IH-FQ@sc8-sf-web5.sourceforge.net>

Bugs item #1460514, was opened at 2006-03-29 10:28
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460514&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 7
Submitted By: Andrew Dalke (dalke)
Assigned to: Thomas Heller (theller)
Summary: ctypes extension does not compile on Mac OS 10.3.9

Initial Comment:
I compiled Python from CVS this morning.  It silently failed to compile 
ctypes.  Here is the text surrounding the failure

gcc [deleted] -c /Users/dalke/cvses/python-svn/Modules/_ctypes/
libffi/src/powerpc/darwin_closure.S -o build/temp.darwin-7.9.0-
Power_Macintosh-2.5/darwin_closure.o
darwin_closure.S:249:unknown section attribute: live_support
darwin_closure.S:249:Rest of line ignored. 1st junk character valued 69 
(E).
building 'itertools' extension
 ...

Python installed but when I tried to import ctypes I got

  File "/usr/local/lib/python2.5/ctypes/__init__.py", line 8, in 
<module>
    from _ctypes import Union, Structure, Array
ImportError: No module named _ctypes

I tracked it down to the '+live_support' attribute from the 
darwin_closure.S.  My compiler does not understand that.

Thomas Heller (in private email) pointed out the text from the ctypes 
README

        On OS X, the segment attribute live_support must be
	defined. If your compiler doesn't know about it, upgrade or
	set the environment variable CCASFLAGS="-Dno_live_support".

Upgrading is out of the option.  I set the environment variable but that 
did not fix things when I tried to recompile Python.  However, editing 
the file to remove the "+live_support" works.  All the self-tests passed, 
and my experimentation this afternoon was successful.



----------------------------------------------------------------------

>Comment By: Thomas Heller (theller)
Date: 2006-05-09 20:36

Message:
Logged In: YES 
user_id=11105

I forgot to close this item.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2006-04-15 22:33

Message:
Logged In: YES 
user_id=11105

Thanks for the feedback.

For the warnings in Modules/_ctypes/cfield.c, I have no idea
what is wrong there.

For the warnings in the libffi-sources I tend to ignore them
because I don't want to change them too much.

For the test-failure: can you find out why this fails?

(In the meantime I'm trying to get hold of 10.3 installation
disks - any tips how to shrink the only existing partition
on my mac mini running 10.4 and setting up a multi-boot
system would be appreciated, if anyone wants to help.  As an
alternative ssh-access to an existing osx installation for
testing would of course also help. I don't know if this is
feasible or not ;-)

----------------------------------------------------------------------

Comment By: Andrew Dalke (dalke)
Date: 2006-04-14 02:51

Message:
Logged In: YES 
user_id=190903

Sorry - was ill and not doing anything for a week.

I've built the latest code from SVN.  No problems with the compilation and I 
am able to import just fine.

I did get the following compiler warnings

/Users/dalke/cvses/python-svn/Modules/_ctypes/cfield.c: In function 
`CField_repr':
/Users/dalke/cvses/python-svn/Modules/_ctypes/cfield.c:259: warning: 
signed size_t format, Py_ssize_t arg (arg 3)
/Users/dalke/cvses/python-svn/Modules/_ctypes/cfield.c:267: warning: 
signed size_t format, Py_ssize_t arg (arg 3)


/Users/dalke/cvses/python-svn/Modules/_ctypes/libffi/src/powerpc/
ffi_darwin.c:383: warning: function declaration isn't a prototype
/Users/dalke/cvses/python-svn/Modules/_ctypes/libffi/src/powerpc/
ffi_darwin.c:384: warning: function declaration isn't a prototype
/Users/dalke/cvses/python-svn/Modules/_ctypes/libffi/src/powerpc/
ffi_darwin.c:388: warning: function declaration isn't a prototype
/Users/dalke/cvses/python-svn/Modules/_ctypes/libffi/src/powerpc/
ffi_darwin.c:389: warning: function declaration isn't a prototype
/Users/dalke/cvses/python-svn/Modules/_ctypes/libffi/src/powerpc/
ffi_darwin.c:394: warning: function declaration isn't a prototype
/Users/dalke/cvses/python-svn/Modules/_ctypes/libffi/src/powerpc/
ffi_darwin.c: In function `ffi_closure_helper_DARWIN':
/Users/dalke/cvses/python-svn/Modules/_ctypes/libffi/src/powerpc/
ffi_darwin.c:622: warning: unused variable `temp_ld'

When I run the self test I get one error

FAILED (errors=1)
Traceback (most recent call last):
  File "Lib/test/test_ctypes.py", line 12, in <module>
    test_main()
  File "Lib/test/test_ctypes.py", line 9, in test_main
    run_suite(unittest.TestSuite(suites))
  File "/Users/dalke/cvses/python-svn/Lib/test/test_support.py", line 285, in 
run_suite
    raise TestFailed(err)
test.test_support.TestFailed: Traceback (most recent call last):
  File "/Users/dalke/cvses/python-svn/Lib/ctypes/test/test_loading.py", line 
30, in test_load
    cdll.load(libc_name)
  File "/Users/dalke/cvses/python-svn/Lib/ctypes/_loader.py", line 112, in 
load
    return self._load(libname, mode)
  File "/Users/dalke/cvses/python-svn/Lib/ctypes/_loader.py", line 153, in 
_load
    return self.load_library(pathname, mode)
  File "/Users/dalke/cvses/python-svn/Lib/ctypes/_loader.py", line 124, in 
load_library
    return self._dlltype(libname, mode)
  File "/Users/dalke/cvses/python-svn/Lib/ctypes/__init__.py", line 288, in 
__init__
    self._handle = _dlopen(self._name, mode)
OSError: dlcompat: unable to open this file with RTLD_LOCAL


which is probably ignorable - OS X has its own sense of what shared libraries 
do.


----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2006-04-03 22:18

Message:
Logged In: YES 
user_id=11105

As a temporary fix, I removed the '+live_support' attribute
in the source file.  Andrew, can you please verify that this
works for you?

Thanks, Thomas

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460514&group_id=5470

From noreply at sourceforge.net  Tue May  9 20:38:27 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 09 May 2006 11:38:27 -0700
Subject: [ python-Bugs-1467450 ] test_ctypes fails on OSX 10.3
Message-ID: <E1FdX6J-0007xx-Tl@sc8-sf-web5.sourceforge.net>

Bugs item #1467450, was opened at 2006-04-10 03:21
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467450&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: Anthony Baxter (anthonybaxter)
Assigned to: Thomas Heller (theller)
Summary: test_ctypes fails on OSX 10.3

Initial Comment:
test test_ctypes failed -- Traceback (most recent call
last):
  File
"/Users/anthonybaxter/python/Lib/ctypes/test/test_loading.py",
line 30, in test_load
    cdll.load(libc_name)
  File
"/Users/anthonybaxter/python/Lib/ctypes/_loader.py",
line 112, in load
    return self._load(libname, mode)
  File
"/Users/anthonybaxter/python/Lib/ctypes/_loader.py",
line 153, in _load
    return self.load_library(pathname, mode)
  File
"/Users/anthonybaxter/python/Lib/ctypes/_loader.py",
line 124, in load_library
    return self._dlltype(libname, mode)
  File
"/Users/anthonybaxter/python/Lib/ctypes/__init__.py",
line 288, in __init__
    self._handle = _dlopen(self._name, mode)
OSError: dlcompat: unable to open this file with RTLD_LOCAL

This happens both with and without the patch in r43748.

Darwin sam.local 7.9.0 Darwin Kernel Version 7.9.0: Wed
Mar 30 20:11:17 PST 2005;
root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC  Power
Macintosh powerpc

GCC version:
Reading specs from /usr/libexec/gcc/darwin/ppc/3.3/specs
Thread model: posix
gcc version 3.3 20030304 (Apple Computer, Inc. build 1640)


----------------------------------------------------------------------

>Comment By: Thomas Heller (theller)
Date: 2006-05-09 20:38

Message:
Logged In: YES 
user_id=11105

Does this failure still occur with Python 2.5a2, or the
current SVN trunk?

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2006-04-13 08:59

Message:
Logged In: YES 
user_id=11105

I'm trying to get a copy of OS X 10.3, then will try to
install it and look after this problem.
OTOH, the ctypes loading code is currently rewritten in the
upstream version - this will probably prevent this failure.

In the meantime, can you try to find out the cause of this
failure?  Would RTLD_GLOBAL instead of RTLD_LOCAL work? Is
the library file missing?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467450&group_id=5470

From noreply at sourceforge.net  Tue May  9 20:47:58 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 09 May 2006 11:47:58 -0700
Subject: [ python-Bugs-1481296 ] long(float('nan'))!=0L
Message-ID: <E1FdXFW-0000j3-Oj@sc8-sf-web1.sourceforge.net>

Bugs item #1481296, was opened at 2006-05-03 19:39
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1481296&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.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Erik Dahl (edahl)
Assigned to: Nobody/Anonymous (nobody)
Summary: long(float('nan'))!=0L

Initial Comment:
on all platforms I can test long(float('nan'))=0L

But on maxos X intel long(float('nan'))!=0L

it returns:

000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000L

This is a problem because:

>>> 344 - long(float('nan'))    
Objects/longobject.c:1645: failed assertion `borrow == 0'
Abort trap




----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2006-05-09 19:47

Message:
Logged In: YES 
user_id=6656

Nevertheless, assuming that a compiler implements the relavent standards (i.e. 
Appendix F of C99) it's pretty clear that what PyLong_FromDouble does with a 
nan is pretty random.  frexp(dval, &expo); for dval nan stores an unspecified 
value in expo which is then used to compute the length of the resulting long.  If 
the unspecified value is large-ish and positive, hilarity ensues.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-05-03 20:09

Message:
Logged In: YES 
user_id=31435

Try it on Windows and you'll get:

>>> long(float('nan'))
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ValueError: invalid literal for float(): nan

Nothing about the behavior of NaNs, infinities, or signed
zeroes is defined or guaranteed by Python.  You use them at
your own risk, and their behavior does vary wildly in
practice (according to the HW, OS, C compiler, C library,
and even the C compiler flags specified when compiling Python).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1481296&group_id=5470

From noreply at sourceforge.net  Tue May  9 22:06:10 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 09 May 2006 13:06:10 -0700
Subject: [ python-Bugs-1484978 ] Doc for new_panel() missing scope info
Message-ID: <E1FdYTC-0002U4-ME@sc8-sf-web4-b.sourceforge.net>

Bugs item #1484978, was opened at 2006-05-09 20:06
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=1484978&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: Troels Therkelsen (troelst)
Assigned to: Nobody/Anonymous (nobody)
Summary: Doc for new_panel() missing scope info

Initial Comment:
The (current) documentation for curses.panel.new_panel
() does not explain that if the panel object returned 
by the function goes out of scope, or is explicitly 
deleted, the associated panel is immediately 
destroyed and removed from the panel stack.  Since 
this is distinctly different from how normal curses 
windows work (text printed to a destroyed window 
doesn't go away).

Maybe the documentation could read something like: 

----

new_panel(win) 

Returns a panel object, associating it with the given 
window win.  Be aware that you need to keep the 
returned panel object referenced explicitly.  If you 
don't, the panel object is garbage collected and 
removed from the panel stack.

----

Of course, one could argue that since there's no 
functions for deleting panels, that it's obvious it's 
handled via normal Python scoping rules, but I got 
stumped by this and it was only by looking into the 
examples in Demo/curses that I figured out what was 
going on.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1484978&group_id=5470

From noreply at sourceforge.net  Wed May 10 04:16:32 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 09 May 2006 19:16:32 -0700
Subject: [ python-Bugs-1462152 ] Python does not check for POSIX compliant
	open() modes
Message-ID: <E1FdeFc-0004tx-4N@sc8-sf-web4-b.sourceforge.net>

Bugs item #1462152, was opened at 2006-03-31 10: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=1462152&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: Matt Fleming (splitscreen)
>Assigned to: Georg Brandl (gbrandl)
Summary: Python does not check for POSIX compliant open() modes

Initial Comment:
Python does not check for POSIX-compliant modes when
passing them to open() and fopen().

According to the POSIX standard all modes should start
with either an 'a', 'r' or 'w'.

This patch implements this check in the
check_the_mode() function of fileobject.c and a test
has been modified in the test_file.py test.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2006-05-09 22:16

Message:
Logged In: YES 
user_id=31435

You're right, I reviewed the older patch.  One of the same
comments, though, plus a new one:

1. The docs should state that this requirement is new in
Python 2.5; in LaTeX, something like

\versionchanged[Restriction on first letter of mode string
introduced]{2.5}

2. We can never assume that allocating memory will work:   after

    newmode = PyMem_MALLOC(strlen(mode) + 3);

you must guard against `newmode` being NULL (and raise an
exception it if is; e.g., call PyErr_NoMemory()).

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-04-28 05:55

Message:
Logged In: YES 
user_id=849994

Tim: Did you review file-modes.diff which is really the
latest patch? (There's no test in it either, but I'll add
one when I check it in)

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-04-23 21:19

Message:
Logged In: YES 
user_id=31435

This is still ;-) fine with me.  There doesn't seem to be a
test in fileobject2.diff.  WRT the docs, "must either be"
should say "must be one of" instead ("either" is proper for
two choices, but there are three).  It should state that
this requirement is new in Python 2.5; in LaTeX, something like

\versionchanged[Restriction on first letter of mode string
introduced]{2.5}

----------------------------------------------------------------------

Comment By: Matt Fleming (splitscreen)
Date: 2006-04-12 06:14

Message:
Logged In: YES 
user_id=1126061

Yeah, your patch looks much better.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-04-06 04:15

Message:
Logged In: YES 
user_id=849994

splitscreen: your patch was incomplete and could have
overwritten memory.

tim_one: Attaching new patch implementing what I proposed in
my comment below.

----------------------------------------------------------------------

Comment By: Matt Fleming (splitscreen)
Date: 2006-04-01 16:59

Message:
Logged In: YES 
user_id=1126061

Ok, uploading latest patch, not quite sure I've hit the mark
here.

Please review.


----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-04-01 15:43

Message:
Logged In: YES 
user_id=849994

Yes, I want to remove 'U' from the mode since it's at this
point already recognized by Python, and it's not meaningful
to the underlying C library.

----------------------------------------------------------------------

Comment By: Matt Fleming (splitscreen)
Date: 2006-04-01 14:32

Message:
Logged In: YES 
user_id=1126061

Ignore my question, it's for "universal newlines", right? 

Have I understood your proposal correctly in that you want
to remove the 'U' from the mode? 

----------------------------------------------------------------------

Comment By: Matt Fleming (splitscreen)
Date: 2006-04-01 09:14

Message:
Logged In: YES 
user_id=1126061

That seems sensible. What does a mode containing 'U' mean
anyway?

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-04-01 02:08

Message:
Logged In: YES 
user_id=849994

Instead of this patch, I'd rather like check_the_mode to

* remove any 'U' from the mode string
* if 'U' was found:
  * error out if the new string begins with 'w' or 'a'
  * add a 'r' and 'b' if it isn't already given
* if not:
  * error out if the string doesn't begin with 'w', 'r', 'a'

What do you think of it?

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-03-31 13:03

Message:
Logged In: YES 
user_id=31435

There's a small danger of backward-incompatibility here,
since platforms are free to support any goofy mode
characters they like, and Python just passes on whatever the
user typed.  I understand that some MS compilers in debug
mode raise internal exceptions, but that's an MS bug and the
workaround is dead easy ("don't do that").

All that said, I'm in favor of this patch ;-).  However, if
it goes in two things are needed:

1. The error message should be more informative, like

   PyErr_Format(PyExc_ValueError, "mode argument must "
     "begin with 'w', 'r', or 'a', not '%.200s'", mode);

2. The Python docs should change to match (i.e., the
   manual should document this new restriction on mode
   strings).

WRT the test case, it's more natural to write, e.g.,

    TESTFN in s

than

    s.find(TESTFN) != -1

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462152&group_id=5470

From noreply at sourceforge.net  Wed May 10 06:33:57 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 09 May 2006 21:33:57 -0700
Subject: [ python-Bugs-1390321 ] Building without C++ should not fail.
Message-ID: <E1FdgOb-0004p4-Bm@sc8-sf-web5.sourceforge.net>

Bugs item #1390321, was opened at 2005-12-26 05:11
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1390321&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: Aahz (aahz)
Assigned to: Martin v. L??wis (loewis)
Summary: Building without C++ should not fail.

Initial Comment:
This just verified against HEAD:

./configure fails on Linux without g++ installed unless --without-cxx
given.  README should mention this.  Error is 

checking for C++ compiler default output file name... configure: error: C++ compiler cannot create executables

Inside config.log it says:

gcc: installation problem, cannot exec 'cc1plus': No such file or directory

(There's been some discussion about not requiring C++ installation by
default -- until that's settled, we should at least update the README.)


----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-05-10 06:33

Message:
Logged In: YES 
user_id=21627

This should be fixed in the trunk now. For 2.4, I added
documentation to README in r45946.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-04-06 02:31

Message:
Logged In: YES 
user_id=3066

The group notes this is for Python 2.5, but I think it
applies to 2.4.x as well.

Re-categorizing as a build issue since Martin says it is.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2005-12-28 01:03

Message:
Logged In: YES 
user_id=21627

The real solution to this problem is that configure
shouldn't fail.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1390321&group_id=5470

From noreply at sourceforge.net  Wed May 10 06:45:12 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 09 May 2006 21:45:12 -0700
Subject: [ python-Bugs-1484556 ] Output of KlocWork on Python2.4.3 sources
Message-ID: <E1FdgZU-0001Dn-FH@sc8-sf-web2.sourceforge.net>

Bugs item #1484556, was opened at 2006-05-09 12:14
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1484556&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Miki Tebeka (tebeka)
Assigned to: Nobody/Anonymous (nobody)
Summary: Output of KlocWork on Python2.4.3 sources

Initial Comment:
We're evaluating KlocWork (http://www.klocwork.com),
I've ran it on the source of Python 2.4.3 and the
output is attached (1562 warnings).

----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-05-10 06:45

Message:
Logged In: YES 
user_id=21627

Thanks for these results. Unfortunately, they seem to
contain many false positives, so it is unclear how one
should proceed with them.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1484556&group_id=5470

From noreply at sourceforge.net  Wed May 10 06:50:45 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 09 May 2006 21:50:45 -0700
Subject: [ python-Bugs-1481770 ] hpux ia64 shared lib ext should be ".so"
Message-ID: <E1Fdger-0000oW-Iq@sc8-sf-web4-b.sourceforge.net>

Bugs item #1481770, was opened at 2006-05-04 13:43
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1481770&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: David Everly (deckrider)
Assigned to: Neal Norwitz (nnorwitz)
Summary: hpux ia64 shared lib ext should be ".so"

Initial Comment:
On hpux ia64, the shared library extension should be
".so".  This is currently problematic in that other
add-on python modules (such as those for subversion)
correctly detect the host_os/host_cpu and build
_module.so, which is not seen by python built using ".sl".

According to
http://devresource.hp.com/drc/resources/portguideipf/index.jsp#dynlinkfac


"Shared library names

Since dynamic linking APIs operate on shared libraries,
it is also important to note that the shared library
naming scheme on Linux is lib*.so; whereas, on HP-UX
11i Version 1.5 the naming scheme is lib*.sl for PA and
lib*.so on IPF. Also APIs may reside in different
libraries files on Linux and HP-UX, so you may need to
dynamically load a different shared library name on
HP-UX and Linux."

To translate this quote, PA=hppa and IPF=ia64.


----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-05-10 06:50

Message:
Logged In: YES 
user_id=21627

The patch looks fine to me. FYI, we include configure output
in the source repository so that people can build from the
source repository without requiring them to run autoconf
first. Patching configure.in only is the right thing to do;
whoever commits the patch will regenerate configure before
commiting it.

----------------------------------------------------------------------

Comment By: David Everly (deckrider)
Date: 2006-05-09 06:11

Message:
Logged In: YES 
user_id=1113403

I tested against hpux ia64 today, and found that the
original patch required correction.  Here is the result.

----------------------------------------------------------------------

Comment By: David Everly (deckrider)
Date: 2006-05-07 15:22

Message:
Logged In: YES 
user_id=1113403

Here is a patch against
http://svn.python.org/projects/python/branches/release24-maint

I don't have many evironments to test against, and only
Linux right now (will test on HPUX ia64 tomorrow and report
back).

----------------------------------------------------------------------

Comment By: David Everly (deckrider)
Date: 2006-05-05 14:07

Message:
Logged In: YES 
user_id=1113403

The patch I'm using now only works on hppa/ia64 and isn't
anything that can coexist nicely in the source package on
other hardware/os combinations.

I've looked at
http://svn.python.org/projects/python/branches/release24-maint/

I'm accustomed to a system using autoconf/libtool/automake
(recent versions) and never committing the output of those
tools, but only running them at source package generation time.

I say this, only to point out that I'm not understanding the
principles behind what I see in subversion.  I see
configure, and also configure.in.  Which should be patched?
 And if I don't patch configure, what is the process for
regenerating it (and with what versions of automake,
autoconf, and libtool?).

Also, the most recent libtool already correctly determines
shared library extension.

So I could probably provide a patch, but would need to
understand the environment better in order to do so.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-05-05 09:02

Message:
Logged In: YES 
user_id=33168

Do you think you could work on a patch to address this issue?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1481770&group_id=5470

From noreply at sourceforge.net  Wed May 10 07:13:52 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 09 May 2006 22:13:52 -0700
Subject: [ python-Bugs-1485280 ] The name is qmail, not Qmail
Message-ID: <E1Fdh1E-0004bh-Tt@sc8-sf-web1.sourceforge.net>

Bugs item #1485280, was opened at 2006-05-09 23: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=1485280&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: None
Status: Open
Resolution: None
Priority: 5
Submitted By: David Phillips (electrum)
Assigned to: Nobody/Anonymous (nobody)
Summary: The name is qmail, not Qmail

Initial Comment:
The lib/module-mailbox document mentions "Qmail", but 
it should be "qmail".

http://cr.yp.to/qmail.html

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1485280&group_id=5470

From noreply at sourceforge.net  Wed May 10 07:14:23 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 09 May 2006 22:14:23 -0700
Subject: [ python-Bugs-1485280 ] The name is qmail, not Qmail
Message-ID: <E1Fdh1j-0008Fh-2c@sc8-sf-web5.sourceforge.net>

Bugs item #1485280, was opened at 2006-05-09 23:13
Message generated for change (Settings changed) made by electrum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1485280&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: None
Status: Open
Resolution: None
>Priority: 1
Submitted By: David Phillips (electrum)
Assigned to: Nobody/Anonymous (nobody)
Summary: The name is qmail, not Qmail

Initial Comment:
The lib/module-mailbox document mentions "Qmail", but 
it should be "qmail".

http://cr.yp.to/qmail.html

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1485280&group_id=5470

From noreply at sourceforge.net  Wed May 10 09:17:13 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 10 May 2006 00:17:13 -0700
Subject: [ python-Bugs-1481770 ] hpux ia64 shared lib ext should be ".so"
Message-ID: <E1Fdiwb-0000gr-1V@sc8-sf-web5.sourceforge.net>

Bugs item #1481770, was opened at 2006-05-04 04:43
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1481770&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: Accepted
Priority: 5
Submitted By: David Everly (deckrider)
Assigned to: Neal Norwitz (nnorwitz)
Summary: hpux ia64 shared lib ext should be ".so"

Initial Comment:
On hpux ia64, the shared library extension should be
".so".  This is currently problematic in that other
add-on python modules (such as those for subversion)
correctly detect the host_os/host_cpu and build
_module.so, which is not seen by python built using ".sl".

According to
http://devresource.hp.com/drc/resources/portguideipf/index.jsp#dynlinkfac


"Shared library names

Since dynamic linking APIs operate on shared libraries,
it is also important to note that the shared library
naming scheme on Linux is lib*.so; whereas, on HP-UX
11i Version 1.5 the naming scheme is lib*.sl for PA and
lib*.so on IPF. Also APIs may reside in different
libraries files on Linux and HP-UX, so you may need to
dynamically load a different shared library name on
HP-UX and Linux."

To translate this quote, PA=hppa and IPF=ia64.


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-05-10 00:17

Message:
Logged In: YES 
user_id=33168

It looked fine to me too.  I wish you didn't have to set the
extension more than once.  That's not a problem with this
patch though.  I'll try to get around to checking this in
unless someone beats me to it.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-05-09 21:50

Message:
Logged In: YES 
user_id=21627

The patch looks fine to me. FYI, we include configure output
in the source repository so that people can build from the
source repository without requiring them to run autoconf
first. Patching configure.in only is the right thing to do;
whoever commits the patch will regenerate configure before
commiting it.

----------------------------------------------------------------------

Comment By: David Everly (deckrider)
Date: 2006-05-08 21:11

Message:
Logged In: YES 
user_id=1113403

I tested against hpux ia64 today, and found that the
original patch required correction.  Here is the result.

----------------------------------------------------------------------

Comment By: David Everly (deckrider)
Date: 2006-05-07 06:22

Message:
Logged In: YES 
user_id=1113403

Here is a patch against
http://svn.python.org/projects/python/branches/release24-maint

I don't have many evironments to test against, and only
Linux right now (will test on HPUX ia64 tomorrow and report
back).

----------------------------------------------------------------------

Comment By: David Everly (deckrider)
Date: 2006-05-05 05:07

Message:
Logged In: YES 
user_id=1113403

The patch I'm using now only works on hppa/ia64 and isn't
anything that can coexist nicely in the source package on
other hardware/os combinations.

I've looked at
http://svn.python.org/projects/python/branches/release24-maint/

I'm accustomed to a system using autoconf/libtool/automake
(recent versions) and never committing the output of those
tools, but only running them at source package generation time.

I say this, only to point out that I'm not understanding the
principles behind what I see in subversion.  I see
configure, and also configure.in.  Which should be patched?
 And if I don't patch configure, what is the process for
regenerating it (and with what versions of automake,
autoconf, and libtool?).

Also, the most recent libtool already correctly determines
shared library extension.

So I could probably provide a patch, but would need to
understand the environment better in order to do so.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-05-05 00:02

Message:
Logged In: YES 
user_id=33168

Do you think you could work on a patch to address this issue?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1481770&group_id=5470

From noreply at sourceforge.net  Wed May 10 12:10:07 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 10 May 2006 03:10:07 -0700
Subject: [ python-Bugs-1485447 ] subprocess.Popen + cwd + relative args[0]
Message-ID: <E1Fdldv-00087S-80@sc8-sf-web1.sourceforge.net>

Bugs item #1485447, was opened at 2006-05-10 11:10
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=1485447&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: Windows
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Sheppard (markshep)
Assigned to: Nobody/Anonymous (nobody)
Summary: subprocess.Popen + cwd + relative args[0]

Initial Comment:
The documentation for subprocess.Popen says:

"""
args should be a string, or a sequence of program
arguments. The program to execute is normally the first
item in the args sequence or string, but can be
explicitly set by using the executable argument.
"""

and

"""
If cwd is not None, the current directory will be
changed to cwd before the child is executed.
"""

However if you set the cwd parameter and in args[0]
specify a relative path to an executable from the cwd
directory it doesn't work.  To get it to work you have
to make args[0] use a relative path from the current
directory of the python process, not the directory you
specify in the cwd parameter.

Possibly this is the intended behaviour, in which case
the documentation is lacking by omitting this fact.  Or
maybe this isn't the intended behaviour in which case
it's a bug in the code.

I've not tested this on any platform other than Windows
so don't know if this is consistent across platforms.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1485447&group_id=5470

From noreply at sourceforge.net  Wed May 10 14:17:38 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 10 May 2006 05:17:38 -0700
Subject: [ python-Bugs-1483963 ] struct.unpack problem with @, =, < specifiers
Message-ID: <E1FdndK-0007Qi-PD@sc8-sf-web1.sourceforge.net>

Bugs item #1483963, was opened at 2006-05-08 18:05
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1483963&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: Christian Hudon (chrish42)
Assigned to: Nobody/Anonymous (nobody)
Summary: struct.unpack problem with @, =, < specifiers

Initial Comment:
When using struct to unpack floats, I'm getting
inconsistent results when using the '<d' specification
instead of '@d' on a little-endian machine (Intel).
Here's a short python snippet that demonstrates the
problem.

import sys, struct

s = '\x00\x00\x00\x00\x00\x00\xf8\x7f'

>>> sys.byteorder
'little'

# This is correct...
>>> struct.unpack('@d', s)
(nan,)

# These should be equivalent for unpacking a single 
# double on little-endian arch... but they're not.
>>> struct.unpack('<d', s)
(inf,)
>>> struct.unpack('=d', s)
(inf,)


----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2006-05-10 13:17

Message:
Logged In: YES 
user_id=6656

Can you try Python from svn HEAD?  Or did you?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1483963&group_id=5470

From noreply at sourceforge.net  Wed May 10 14:36:12 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 10 May 2006 05:36:12 -0700
Subject: [ python-Bugs-1481296 ] long(float('nan'))!=0L
Message-ID: <E1FdnvI-00069f-Np@sc8-sf-web1.sourceforge.net>

Bugs item #1481296, was opened at 2006-05-03 13:39
Message generated for change (Comment added) made by edahl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1481296&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.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Erik Dahl (edahl)
Assigned to: Nobody/Anonymous (nobody)
Summary: long(float('nan'))!=0L

Initial Comment:
on all platforms I can test long(float('nan'))=0L

But on maxos X intel long(float('nan'))!=0L

it returns:

000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000L

This is a problem because:

>>> 344 - long(float('nan'))    
Objects/longobject.c:1645: failed assertion `borrow == 0'
Abort trap




----------------------------------------------------------------------

>Comment By: Erik Dahl (edahl)
Date: 2006-05-10 07:36

Message:
Logged In: YES 
user_id=1482543

Just to be clear this does cause a crash in the interpreter.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2006-05-09 13:47

Message:
Logged In: YES 
user_id=6656

Nevertheless, assuming that a compiler implements the relavent standards (i.e. 
Appendix F of C99) it's pretty clear that what PyLong_FromDouble does with a 
nan is pretty random.  frexp(dval, &expo); for dval nan stores an unspecified 
value in expo which is then used to compute the length of the resulting long.  If 
the unspecified value is large-ish and positive, hilarity ensues.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-05-03 14:09

Message:
Logged In: YES 
user_id=31435

Try it on Windows and you'll get:

>>> long(float('nan'))
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ValueError: invalid literal for float(): nan

Nothing about the behavior of NaNs, infinities, or signed
zeroes is defined or guaranteed by Python.  You use them at
your own risk, and their behavior does vary wildly in
practice (according to the HW, OS, C compiler, C library,
and even the C compiler flags specified when compiling Python).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1481296&group_id=5470

From noreply at sourceforge.net  Wed May 10 15:28:04 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 10 May 2006 06:28:04 -0700
Subject: [ python-Feature Requests-1485576 ] Backwards compatibility support
	for Py_ssize_t
Message-ID: <E1FdojU-00009m-Fl@sc8-sf-web1.sourceforge.net>

Feature Requests item #1485576, was opened at 2006-05-10 13:28
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1485576&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: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Konrad Hinsen (hinsen)
Assigned to: Nobody/Anonymous (nobody)
Summary: Backwards compatibility support for Py_ssize_t

Initial Comment:
PEP353 recommends to add the following code snippet to extension 
modules to ensure compatibility with pre-2.5 interpreters:

#if PY_VERSION_HEX < 0x02050000
typedef int Py_ssize_t;
#define PY_SSIZE_T_MAX INT_MAX
#define PY_SSIZE_T_MIN INT_MIN
#endif

This is insufficient, because type definitions that use Py_ssize_t must 
also be added. Here is what works for me, though they may be more 
definitions to be included:

#if PY_VERSION_HEX < 0x02050000
typedef int Py_ssize_t;
#define PY_SSIZE_T_MAX INT_MAX
#define PY_SSIZE_T_MIN INT_MIN
typedef Py_ssize_t (*lenfunc)(PyObject *);
typedef PyObject *(*ssizeargfunc)(PyObject *, Py_ssize_t);
typedef PyObject *(*ssizessizeargfunc)(PyObject *, Py_ssize_t, 
Py_ssize_t);
typedef int(*ssizeobjargproc)(PyObject *, Py_ssize_t, PyObject *);
typedef int(*ssizessizeobjargproc)(PyObject *, Py_ssize_t, Py_ssize_t, 
PyObject *);
typedef Py_ssize_t (*readbufferproc)(PyObject *, Py_ssize_t, void **);
typedef Py_ssize_t (*writebufferproc)(PyObject *, Py_ssize_t, void **);
typedef Py_ssize_t (*segcountproc)(PyObject *, Py_ssize_t *);
typedef Py_ssize_t (*charbufferproc)(PyObject *, Py_ssize_t, char **);
#endif

However, the main problem is elsewhere. Extension modules may well 
need to use Py_ssize_t in their own data types, and may furthermore 
with to make these data types available to yet other extension 
modules. In practice, this requires the inclusion of a code block such 
as the one shown above inside header files. However, this requires a 
mechanism for avoiding redefinitions, which at the moment does not 
seem to exist. My request is to add such a mechanism to Python 2.5 
and recommend its consistent use in an update of PEP353.

Concretely, I propose that Python 2.5 should define a macro 
PY_HAS_PY_SSIZE_T, and that PEP353 should recommend the inclusion 
of the code snippet

#ifndef PY_HAS_PY_SSIZE_T
#define PY_HAS_PY_SSIZE_T
typedef int Py_ssize_t;

/* add all the other definitions here */

#endif

that contains an exhaustive set of definitions that depend on 
Py_ssize_t.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1485576&group_id=5470

From noreply at sourceforge.net  Wed May 10 16:24:55 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 10 May 2006 07:24:55 -0700
Subject: [ python-Bugs-1483963 ] struct.unpack problem with @, =, < specifiers
Message-ID: <E1FdpcV-000252-AG@sc8-sf-web4-b.sourceforge.net>

Bugs item #1483963, was opened at 2006-05-08 13:05
Message generated for change (Comment added) made by chrish42
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1483963&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: Christian Hudon (chrish42)
Assigned to: Nobody/Anonymous (nobody)
Summary: struct.unpack problem with @, =, < specifiers

Initial Comment:
When using struct to unpack floats, I'm getting
inconsistent results when using the '<d' specification
instead of '@d' on a little-endian machine (Intel).
Here's a short python snippet that demonstrates the
problem.

import sys, struct

s = '\x00\x00\x00\x00\x00\x00\xf8\x7f'

>>> sys.byteorder
'little'

# This is correct...
>>> struct.unpack('@d', s)
(nan,)

# These should be equivalent for unpacking a single 
# double on little-endian arch... but they're not.
>>> struct.unpack('<d', s)
(inf,)
>>> struct.unpack('=d', s)
(inf,)


----------------------------------------------------------------------

>Comment By: Christian Hudon (chrish42)
Date: 2006-05-10 10:24

Message:
Logged In: YES 
user_id=980271

I had tried with 2.3.5 and 2.4.1 and the bug was present in
both versions. I just tried with svn HEAD, and the bug is
fixed there (at least in the revision that I tried). 

It'd be nice if this bug fix could be included in the next
2.4 point release, assuming the fix is not too complicated.
Is there a process for nominating bugfixes for the main-2.4
branch?

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2006-05-10 08:17

Message:
Logged In: YES 
user_id=6656

Can you try Python from svn HEAD?  Or did you?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1483963&group_id=5470

From noreply at sourceforge.net  Wed May 10 16:30:52 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 10 May 2006 07:30:52 -0700
Subject: [ python-Bugs-1483963 ] struct.unpack problem with @, =, < specifiers
Message-ID: <E1FdpiG-0003jW-0O@sc8-sf-web2.sourceforge.net>

Bugs item #1483963, was opened at 2006-05-08 18:05
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1483963&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: Christian Hudon (chrish42)
Assigned to: Nobody/Anonymous (nobody)
Summary: struct.unpack problem with @, =, < specifiers

Initial Comment:
When using struct to unpack floats, I'm getting
inconsistent results when using the '<d' specification
instead of '@d' on a little-endian machine (Intel).
Here's a short python snippet that demonstrates the
problem.

import sys, struct

s = '\x00\x00\x00\x00\x00\x00\xf8\x7f'

>>> sys.byteorder
'little'

# This is correct...
>>> struct.unpack('@d', s)
(nan,)

# These should be equivalent for unpacking a single 
# double on little-endian arch... but they're not.
>>> struct.unpack('<d', s)
(inf,)
>>> struct.unpack('=d', s)
(inf,)


----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2006-05-10 15:30

Message:
Logged In: YES 
user_id=6656

I'm glad my fix worked.  I'm not personally inclined to port the fixes to the 2.4 
branch, as they are indeed fairly involved.

----------------------------------------------------------------------

Comment By: Christian Hudon (chrish42)
Date: 2006-05-10 15:24

Message:
Logged In: YES 
user_id=980271

I had tried with 2.3.5 and 2.4.1 and the bug was present in
both versions. I just tried with svn HEAD, and the bug is
fixed there (at least in the revision that I tried). 

It'd be nice if this bug fix could be included in the next
2.4 point release, assuming the fix is not too complicated.
Is there a process for nominating bugfixes for the main-2.4
branch?

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2006-05-10 13:17

Message:
Logged In: YES 
user_id=6656

Can you try Python from svn HEAD?  Or did you?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1483963&group_id=5470

From noreply at sourceforge.net  Wed May 10 16:31:49 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 10 May 2006 07:31:49 -0700
Subject: [ python-Bugs-1485280 ] The name is qmail, not Qmail
Message-ID: <E1FdpjB-0002qV-Fd@sc8-sf-web5.sourceforge.net>

Bugs item #1485280, was opened at 2006-05-10 05:13
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1485280&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: None
>Status: Closed
>Resolution: Fixed
Priority: 1
Submitted By: David Phillips (electrum)
Assigned to: Nobody/Anonymous (nobody)
Summary: The name is qmail, not Qmail

Initial Comment:
The lib/module-mailbox document mentions "Qmail", but 
it should be "qmail".

http://cr.yp.to/qmail.html

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-05-10 14:31

Message:
Logged In: YES 
user_id=849994

This is already fixed in the development docs.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1485280&group_id=5470

From noreply at sourceforge.net  Wed May 10 17:59:35 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 10 May 2006 08:59:35 -0700
Subject: [ python-Bugs-1482988 ] docs for 'profile' should refer to
	pstats.Stats
Message-ID: <E1Fdr67-0001M9-9S@sc8-sf-web2.sourceforge.net>

Bugs item #1482988, was opened at 2006-05-06 12:54
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1482988&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: Ori Peleg (oripel)
Assigned to: Nobody/Anonymous (nobody)
Summary: docs for 'profile' should refer to pstats.Stats

Initial Comment:
The docs for module 'profile' refer to 'profile.Stats',
which look like:

def Stats(*args):
    print 'Report generating functions are in the
"pstats" module\a'

This is true in older Python versions, as well as 2.5a2:

http://docs.python.org/dev/lib/module-profile.html

Suggestion: have the documentation point to
pstats.Stats instead, and possibly remove the
placeholder 'Stats' in module profile, or have it raise
an exception instead of printing an error.


----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-05-10 15:59

Message:
Logged In: YES 
user_id=849994

I added a \note about the module change in rev. 45949.

----------------------------------------------------------------------

Comment By: Ori Peleg (oripel)
Date: 2006-05-06 12:57

Message:
Logged In: YES 
user_id=1131251

A correction - the docs do refer to the 'this class from the
pstats module', but this easily missed by someone skipping
carefully reading the preamble text (like me :-/ )

You could say this is PEBKAC (problem exists between
keyboard and chair), but I suggest it's a common phenomenon
meaning the pointer to module 'pstats' should be more prominent.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1482988&group_id=5470

From noreply at sourceforge.net  Wed May 10 18:09:58 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 10 May 2006 09:09:58 -0700
Subject: [ python-Bugs-1485447 ] subprocess.Popen + cwd + relative args[0]
Message-ID: <E1FdrGA-00006V-KZ@sc8-sf-web3.sourceforge.net>

Bugs item #1485447, was opened at 2006-05-10 10:10
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1485447&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: Windows
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Mark Sheppard (markshep)
Assigned to: Nobody/Anonymous (nobody)
Summary: subprocess.Popen + cwd + relative args[0]

Initial Comment:
The documentation for subprocess.Popen says:

"""
args should be a string, or a sequence of program
arguments. The program to execute is normally the first
item in the args sequence or string, but can be
explicitly set by using the executable argument.
"""

and

"""
If cwd is not None, the current directory will be
changed to cwd before the child is executed.
"""

However if you set the cwd parameter and in args[0]
specify a relative path to an executable from the cwd
directory it doesn't work.  To get it to work you have
to make args[0] use a relative path from the current
directory of the python process, not the directory you
specify in the cwd parameter.

Possibly this is the intended behaviour, in which case
the documentation is lacking by omitting this fact.  Or
maybe this isn't the intended behaviour in which case
it's a bug in the code.

I've not tested this on any platform other than Windows
so don't know if this is consistent across platforms.


----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-05-10 16:09

Message:
Logged In: YES 
user_id=849994

This is indeed intended behavior. "cwd" is the new current
directory for the child, not for the parent. I clarified
this in rev. 45950, 45951(2.4).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1485447&group_id=5470

From noreply at sourceforge.net  Wed May 10 18:12:21 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 10 May 2006 09:12:21 -0700
Subject: [ python-Bugs-1484978 ] Doc for new_panel() missing scope info
Message-ID: <E1FdrIT-0000wu-Tj@sc8-sf-web3.sourceforge.net>

Bugs item #1484978, was opened at 2006-05-09 20:06
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1484978&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: Troels Therkelsen (troelst)
Assigned to: Nobody/Anonymous (nobody)
Summary: Doc for new_panel() missing scope info

Initial Comment:
The (current) documentation for curses.panel.new_panel
() does not explain that if the panel object returned 
by the function goes out of scope, or is explicitly 
deleted, the associated panel is immediately 
destroyed and removed from the panel stack.  Since 
this is distinctly different from how normal curses 
windows work (text printed to a destroyed window 
doesn't go away).

Maybe the documentation could read something like: 

----

new_panel(win) 

Returns a panel object, associating it with the given 
window win.  Be aware that you need to keep the 
returned panel object referenced explicitly.  If you 
don't, the panel object is garbage collected and 
removed from the panel stack.

----

Of course, one could argue that since there's no 
functions for deleting panels, that it's obvious it's 
handled via normal Python scoping rules, but I got 
stumped by this and it was only by looking into the 
examples in Demo/curses that I figured out what was 
going on.

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-05-10 16:12

Message:
Logged In: YES 
user_id=849994

Thanks for reporting, I applied your new wording in rev.
45952, 45953(2.4).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1484978&group_id=5470

From noreply at sourceforge.net  Wed May 10 18:16:46 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 10 May 2006 09:16:46 -0700
Subject: [ python-Bugs-1483997 ] pydoc doesn't create html-file
Message-ID: <E1FdrMk-0002U8-7I@sc8-sf-web3.sourceforge.net>

Bugs item #1483997, was opened at 2006-05-08 17:59
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1483997&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: Not a Bug
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Gregor Lingl (glingl)
Assigned to: Nobody/Anonymous (nobody)
Summary: pydoc doesn't create html-file

Initial Comment:
The call

c:\Python25\Lib\pydoc.py -w testdoc

results in an error-message:

Traceback ...
  File ...
  ...
 
  ...
  File "c:\Python25\Lib\inspect.py",line 564,in walktree
   classes.sort(key=attrgetter('__module__','__name__'))
TypeError: attrgetter expected 1 arguments, got 2

The same call with Python 2.4 works correctly

regards,

Gregor Lingl


----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-05-10 16:16

Message:
Logged In: YES 
user_id=849994

The problem is that when you call pydoc.py directly, it will
use whatever interpreter is registered in your Windows
environment to run .py files, which in your case is the 2.4
interpreter.

The 2.5 version of pydoc uses some new features which
require a 2.5 interpreter to run, so until Python 2.5 is
installed on your box use something like

c:\python25\bin\python c:\python25\lib\pydoc.py ....

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1483997&group_id=5470

From noreply at sourceforge.net  Wed May 10 18:26:47 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 10 May 2006 09:26:47 -0700
Subject: [ python-Bugs-1471427 ] tarfile.py chokes on long names
Message-ID: <E1FdrWR-0004tk-Ac@sc8-sf-web5.sourceforge.net>

Bugs item #1471427, was opened at 2006-04-16 20:34
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1471427&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
>Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Alexander Schremmer (alexanderweb)
Assigned to: Nobody/Anonymous (nobody)
Summary: tarfile.py chokes on long names

Initial Comment:
The following bug is reproducible on Py 2.4.3 and 2.5. 
It was tested on Windows. You need a tarfile with a 
long file name that triggers the GNU LONGNAME 
extension.

Extracting such a file gives me an IO error because it 
tries to create a file with a slash at the end. This is 
because 

        # Some old tar programs represent a directory 
as a regular
        # file with a trailing slash.
        if tarinfo.isreg() and tarinfo.name.endswith("/
"):
            tarinfo.type = DIRTYPE

sets the type incorrectly after it was called from the 
callback proc which has no possiblity to set the name 
of the intermediary tarinfo class because it is 
instantiated in the next-method.

So this yields a directory which should be a file which 
is obviously wrong. Might be related to commit 41340 
"Patch #1338314, Bug #1336623". (At least the code 
changed there is causing this bug).

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-05-10 16:26

Message:
Logged In: YES 
user_id=849994

Said patch has now been applied.

----------------------------------------------------------------------

Comment By: Lars Gust?bel (gustaebel)
Date: 2006-05-09 13:56

Message:
Logged In: YES 
user_id=642936

I have posted the fix as patch #1484695. Thanks for your report.

----------------------------------------------------------------------

Comment By: Alexander Schremmer (alexanderweb)
Date: 2006-05-07 11:55

Message:
Logged In: YES 
user_id=254738

Thanks, that seems to work. Try to get this into Py 2.5 :)

----------------------------------------------------------------------

Comment By: Lars Gust?bel (gustaebel)
Date: 2006-04-25 20:59

Message:
Logged In: YES 
user_id=642936

Fixing this issue is not quite as simple as I hoped it to
be. It would be possible to implement a quick fix that
solves the problem, but that would be too ugly for a stdlib
module. Instead, I have been busy writing a preliminary fix
for my development version of tarfile.py which is available
at http://www.gustaebel.de/lars/tarfile/.
It would be nice of you, if you'd download the 0.8.0 version
there and give it a try. Thank you.


----------------------------------------------------------------------

Comment By: Alexander Schremmer (alexanderweb)
Date: 2006-04-16 20:34

Message:
Logged In: YES 
user_id=254738

Hmm, I just want to clarify that tarfile doesn't give the IO 
error (it passes silently) but my code that expects a file 
instead of a directory ;-)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1471427&group_id=5470

From noreply at sourceforge.net  Wed May 10 21:45:47 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 10 May 2006 12:45:47 -0700
Subject: [ python-Bugs-1484580 ] ctypes documenation obscure and incomplete
Message-ID: <E1Fdud1-00087x-RW@sc8-sf-web3.sourceforge.net>

Bugs item #1484580, was opened at 2006-05-09 12:59
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1484580&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: Nicko van Someren (nicko)
Assigned to: Thomas Heller (theller)
Summary: ctypes documenation obscure and incomplete

Initial Comment:
The documentation for ctypes in Python 2.5, drawn largely from the 
original ctypes tutorial, misses a number of important points which 
users will want to know.  In particular the documentation surrounding 
casting of types is currently non-existant and the documentation 
regarding the relationship between pointer(), byref() and array objects 
is at best limited.

In order to fix this I would suggest the following changes:

1) A new sub-sub-sub-section 13.14.1.x should be added to 
document the "cast()" function provided by ctypes.  The cast function 
takes two parameters, a ctypes object of some sort and a ctypes type 
class, and it returns the former cast to the later. e.g.:

    class Foo(Structure):
        _fields_ = [("x", c_int), ("y", c_int)]
    class Bar(Structure):
        _fields_ = [("count", c_int),("values", c_void_p)]

    f = Foo(1,2)
    b = Bar(1, cast(pointer(f), c_void_p))

I'm sure that there are many other subtleties to the cast() function 
which I don't know about, because they are not currently documented!

2) Nowhere is is explicitly stated that, where a pointer to a type is 
expected, a ctypes array object can be assigned instead.  While this is 
arguably intuitive to any C programmer it could with being 
documented.  Otherwise people will write:
    someFun.argtypes = [POINTER(Foo)]
    tenFoos = (Foo * 10)()
    someFun(cast(byref(tenFoos), POINTER(Foo)))
when the last line is better written:
    someFun(tenFoos)
Adding some words on this subject to section 13.14.1.13 (Arrays) or 
13.14.1.14 (Pointers) would be helpful.




----------------------------------------------------------------------

>Comment By: Thomas Heller (theller)
Date: 2006-05-10 21:45

Message:
Logged In: YES 
user_id=11105

Nicko, the attached file 'conversions.txt' contains a first
draft of a chapter that describes the 'cast' function and
that arrays are also accepted instead of pointers.  Could
you please review if this is useful?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1484580&group_id=5470

From noreply at sourceforge.net  Thu May 11 04:30:56 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 10 May 2006 19:30:56 -0700
Subject: [ python-Bugs-1462352 ] socket.ssl won't work together with
	socket.settimeout on Win
Message-ID: <E1Fe0x6-0001Ik-5d@sc8-sf-web2.sourceforge.net>

Bugs item #1462352, was opened at 2006-03-31 11:11
Message generated for change (Comment added) made by jasonbrady
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462352&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: Windows
Group: Python 2.4
Status: Closed
Resolution: Fixed
Priority: 6
Submitted By: Georg Brandl (gbrandl)
Assigned to: Trent Mick (tmick)
Summary: socket.ssl won't work together with socket.settimeout on Win

Initial Comment:
Symptoms:

>>> import socket
>>> s = socket.socket()
>>> s.settimeout(30.0)
>>> s.connect(("gmail.org", 995))
>>> ss = socket.ssl(s)
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
   File "C:\python24\lib\socket.py", line 74, in ssl
     return _realssl(sock, keyfile, certfile)
 socket.sslerror: (2, 'The operation did not complete
(read)')

This does not occur on Unix, where
test_socket_ssl.test_timeout runs smoothly.

----------------------------------------------------------------------

Comment By: Jason Brady (jasonbrady)
Date: 2006-05-10 19:30

Message:
Logged In: YES 
user_id=1520816

I would like to confirm that this bug still exists. A simple
example, from the docs no less, that fails.

If you set any timeout on sockets, and try to make an ssl
connection, you get "socket.sslerror: (2, 'The operation did
not complete (read)')".

This is running on Windows XP Professional, SP2, latest
python 2.4.3.

-------------------------------------------------------------
import socket

print 'Timeout: '
print socket.getdefaulttimeout()
socket.setdefaulttimeout(None)
print 'Timeout: '
print socket.getdefaulttimeout()

import httplib
conn = httplib.HTTPSConnection("sourceforge.net")
conn.request("GET", "/projects/python/")
r1 = conn.getresponse()
print r1.status, r1.reason
data1 = r1.read()
conn.close()
print data1
-----------------------------------------------------------

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-04-08 06:00

Message:
Logged In: YES 
user_id=31435

Yup, saw that, but I'd like input from Trent (it's his box):
 why is it timing out at all?  30 seconds is a huge blob of
time, and none of the other buildbots are timing out.  When
I disabled test_socket_ssl's test_timeout, _all_ buildbot
slaves were timing out (because gmail.org simply wasn't
responding to anyone at the time).

IOW, there may be a Win2K-specific bug in the Python
implementation here (note that Trent's is the only Win2K
slave we have).

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-04-08 05:52

Message:
Logged In: YES 
user_id=849994

Now one Windows buildbot turned red again since the timeout
didn't raise socket.timeout but socket.error... :-|

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-04-08 05:48

Message:
Logged In: YES 
user_id=31435

Whoa -- good eye, Martin!  Thank you.  Looks like bugs all
over the place.

FYI, I later rehabilitated the disabled part of
test_socket_ssl, and removed the Windows special-casing, in
revs 43734 (trunk) and 43735 (2.4 branch).

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-08 02:18

Message:
Logged In: YES 
user_id=21627

The problem is that WIN32 isn't initially defined.
WinSock2.h has this structure:

#if !defined(WIN32) && !defined(_WIN64)
#include <pshpack4.h>
#endif

#include <windows.h>

#if !defined(WIN32) && !defined(_WIN64)
#include <poppack.h>
#endif

Even though WIN32 is initially not defined, it is defined
at the end of WinSock2.h, so that the poppack.h is not
included. That leaves a pragma pack(push,4) on the pack
stack. I haven't traced where exactly WIN32 is defined,
but it probably comes from Ole2.h.

Fixed in 43731 and 43732. Not sure whether anything needs to
be done to the test suite.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-04-08 00:48

Message:
Logged In: YES 
user_id=31435

Normal MS struct member alignment is definitely screwed up
inside _ssl.c, but still don't know how that happens. 
sizeof this struct should be 16, but is reported as 12 when
the source is inside _ssl.c:

struct dummy {
    int a;
    double x;
};

(note that in the details in previous comments, the double
&Sock->sock_timeout was not 8-byte aligned in _ssl.c, but
was in socketmodule.c).  I don't see any MS packing pragmas
in any of the OpenSSL .h files either.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-04-07 23:05

Message:
Logged In: YES 
user_id=31435

As a sanity check on all those details, inside newPySSLObject()

*(double *)((char *)&Sock->sock_timeout + 4)

is in fact 30.0.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-04-07 22:25

Message:
Logged In: YES 
user_id=31435

I did a data breakpoint on the 8 bytes in the sock_timeout
member, and it never triggered:  nothing stores anything
there to change 30.0 to 0.0.

Instead, socketmodule.c and _ssl.c have different views of
where the members of a PySocketSockObject live.  WRT
socketmodule.c sock_settimeout's `s`, and _ssl.c
newPySSLObject's `Sock` (which are the same object in the
test case), the debugger agrees about the addresses at which
these members live:

&s->_ob_next    0x0096c3e8
&s->_ob_prev    0x0096c3ec
&s->ob_refcnt   0x0096c3f0
&s->ob_type     0x0096c3f4
&s->sock_fd     0x0096c3f8
&s->sock_family 0x0096c3fc
&s->sock_type   0x0096c400
&s->sock_proto  0x0096c404
&s->sock_addr   0x0096c408
&s->errorhandler 0x0096c488

But there's a radical disconnect about where it thinks
sock_timeout lives:

&s->sock_timeout    0x0096c490
&Sock->sock_timeout 0x0096c48c

Indeed,

    printf("%d\n", sizeof(PySocketSockObject));

displays different results:

socketmodule.c: 176
_ssl.c:         172

I'm unclear about why.  Doing

    printf("%d\n", sizeof(sock_addr_t));

prints 128 in both modules, so there's not an obvious
difference there.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-04-01 18:08

Message:
Logged In: YES 
user_id=31435

BTW, does anyone understand why this part of my first
comment was true?:

"""
check_socket_and_wait_for_timeout() takes the "else if
(s->sock_timeout == 0.0)" path and and returns
SOCKET_IS_NONBLOCKING.
"""

How did s->sock_timeout become 0?  s.settimeout(30.0) was
called, and the same s was passed to socket.ssl().  I don't
understand this at all:

>>> s.connect(("gmail.org", 995))
>>> s.gettimeout()
30.0
>>> s._sock
<socket object, fd=1920, family=2, type=1, protocol=0>
>>> s._sock.gettimeout()
30.0
>>> ss = socket.ssl(s)

but a breakpoint in newPySSLObject() right there shows that
Sock->sock_timeout is 0.0.  HTF did that happen?

If I poke 30.0 (under the debugger) into Sock->sock_timeout
at the start of newPySSLObject(), the constructor finishes
unexceptionally.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-04-01 17:57

Message:
Logged In: YES 
user_id=31435

gmail.com happened to respond when I tried it today, so I
can confirm (alas) that the patch at

http://pastebin.com/633224

made no difference to the outcome on Windows.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-03-31 17:36

Message:
Logged In: YES 
user_id=31435

Because the

s.connect(("gmail.org", 995))

line started timing out on all (non-Windows) buildbot slaves
some hours ago, causing all test runs to fail, I disabled
test_timeout on all boxes for now (on trunk & on 2.4 branch).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-03-31 15:23

Message:
Logged In: YES 
user_id=31435

Note that this is a problem in 2.4 and trunk.

The sample code worked fine earlier today if (and only if) I
left out the .settimeout() call.

Note that buildbot test runs are failing in trunk and 2.4
branch now on non-Windows boxes, because the

s.connect(("gmail.org", 995))

line is timing out (the new test is disabled on Windows, and
that's why the Windows buildbots are still passing).  At the
moment, that's timing out on my Windows box too.  We clearly
need a more reliable net address to connect to.

On Bug Day IRC, "arekm" last asked that I try this patch on
 Windows:

http://pastebin.com/633224

Unfortunately, I haven't been able to get beyond the
s.connect(("gmail.org", 995)) line since then, so still
don't know whether that helps.  Nothing else did ;-)

On Windows, in newPySSLObject(),
"ret = SSL_connect(self->ssl);" returns -1
"err = SSL_get_error(self->ssl, ret);" returns 2
"if (err == SSL_ERROR_WANT_READ)" triggers.
check_socket_and_wait_for_timeout() takes the "else if
(s->sock_timeout == 0.0)" path and and returns
SOCKET_IS_NONBLOCKING.
newPySSLObject() breaks out of its loop then, and does
"PySSL_SetError(self, ret); goto fail;"

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462352&group_id=5470

From noreply at sourceforge.net  Thu May 11 04:31:14 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 10 May 2006 19:31:14 -0700
Subject: [ python-Bugs-1462352 ] socket.ssl won't work together with
	socket.settimeout on Win
Message-ID: <E1Fe0xO-0001SW-Ss@sc8-sf-web2.sourceforge.net>

Bugs item #1462352, was opened at 2006-03-31 11:11
Message generated for change (Comment added) made by jasonbrady
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462352&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: Windows
Group: Python 2.4
Status: Closed
Resolution: Fixed
Priority: 6
Submitted By: Georg Brandl (gbrandl)
Assigned to: Trent Mick (tmick)
Summary: socket.ssl won't work together with socket.settimeout on Win

Initial Comment:
Symptoms:

>>> import socket
>>> s = socket.socket()
>>> s.settimeout(30.0)
>>> s.connect(("gmail.org", 995))
>>> ss = socket.ssl(s)
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
   File "C:\python24\lib\socket.py", line 74, in ssl
     return _realssl(sock, keyfile, certfile)
 socket.sslerror: (2, 'The operation did not complete
(read)')

This does not occur on Unix, where
test_socket_ssl.test_timeout runs smoothly.

----------------------------------------------------------------------

Comment By: Jason Brady (jasonbrady)
Date: 2006-05-10 19:31

Message:
Logged In: YES 
user_id=1520816

I would like to confirm that this bug still exists. A simple
example, from the docs no less, that fails.

If you set any timeout on sockets, and try to make an ssl
connection, you get "socket.sslerror: (2, 'The operation did
not complete (read)')".

This is running on Windows XP Professional, SP2, latest
python 2.4.3.

-------------------------------------------------------------
import socket

print 'Timeout: '
print socket.getdefaulttimeout()
socket.setdefaulttimeout(None)
print 'Timeout: '
print socket.getdefaulttimeout()

import httplib
conn = httplib.HTTPSConnection("sourceforge.net")
conn.request("GET", "/projects/python/")
r1 = conn.getresponse()
print r1.status, r1.reason
data1 = r1.read()
conn.close()
print data1
-----------------------------------------------------------

----------------------------------------------------------------------

Comment By: Jason Brady (jasonbrady)
Date: 2006-05-10 19:30

Message:
Logged In: YES 
user_id=1520816

I would like to confirm that this bug still exists. A simple
example, from the docs no less, that fails.

If you set any timeout on sockets, and try to make an ssl
connection, you get "socket.sslerror: (2, 'The operation did
not complete (read)')".

This is running on Windows XP Professional, SP2, latest
python 2.4.3.

-------------------------------------------------------------
import socket

print 'Timeout: '
print socket.getdefaulttimeout()
socket.setdefaulttimeout(None)
print 'Timeout: '
print socket.getdefaulttimeout()

import httplib
conn = httplib.HTTPSConnection("sourceforge.net")
conn.request("GET", "/projects/python/")
r1 = conn.getresponse()
print r1.status, r1.reason
data1 = r1.read()
conn.close()
print data1
-----------------------------------------------------------

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-04-08 06:00

Message:
Logged In: YES 
user_id=31435

Yup, saw that, but I'd like input from Trent (it's his box):
 why is it timing out at all?  30 seconds is a huge blob of
time, and none of the other buildbots are timing out.  When
I disabled test_socket_ssl's test_timeout, _all_ buildbot
slaves were timing out (because gmail.org simply wasn't
responding to anyone at the time).

IOW, there may be a Win2K-specific bug in the Python
implementation here (note that Trent's is the only Win2K
slave we have).

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-04-08 05:52

Message:
Logged In: YES 
user_id=849994

Now one Windows buildbot turned red again since the timeout
didn't raise socket.timeout but socket.error... :-|

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-04-08 05:48

Message:
Logged In: YES 
user_id=31435

Whoa -- good eye, Martin!  Thank you.  Looks like bugs all
over the place.

FYI, I later rehabilitated the disabled part of
test_socket_ssl, and removed the Windows special-casing, in
revs 43734 (trunk) and 43735 (2.4 branch).

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-08 02:18

Message:
Logged In: YES 
user_id=21627

The problem is that WIN32 isn't initially defined.
WinSock2.h has this structure:

#if !defined(WIN32) && !defined(_WIN64)
#include <pshpack4.h>
#endif

#include <windows.h>

#if !defined(WIN32) && !defined(_WIN64)
#include <poppack.h>
#endif

Even though WIN32 is initially not defined, it is defined
at the end of WinSock2.h, so that the poppack.h is not
included. That leaves a pragma pack(push,4) on the pack
stack. I haven't traced where exactly WIN32 is defined,
but it probably comes from Ole2.h.

Fixed in 43731 and 43732. Not sure whether anything needs to
be done to the test suite.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-04-08 00:48

Message:
Logged In: YES 
user_id=31435

Normal MS struct member alignment is definitely screwed up
inside _ssl.c, but still don't know how that happens. 
sizeof this struct should be 16, but is reported as 12 when
the source is inside _ssl.c:

struct dummy {
    int a;
    double x;
};

(note that in the details in previous comments, the double
&Sock->sock_timeout was not 8-byte aligned in _ssl.c, but
was in socketmodule.c).  I don't see any MS packing pragmas
in any of the OpenSSL .h files either.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-04-07 23:05

Message:
Logged In: YES 
user_id=31435

As a sanity check on all those details, inside newPySSLObject()

*(double *)((char *)&Sock->sock_timeout + 4)

is in fact 30.0.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-04-07 22:25

Message:
Logged In: YES 
user_id=31435

I did a data breakpoint on the 8 bytes in the sock_timeout
member, and it never triggered:  nothing stores anything
there to change 30.0 to 0.0.

Instead, socketmodule.c and _ssl.c have different views of
where the members of a PySocketSockObject live.  WRT
socketmodule.c sock_settimeout's `s`, and _ssl.c
newPySSLObject's `Sock` (which are the same object in the
test case), the debugger agrees about the addresses at which
these members live:

&s->_ob_next    0x0096c3e8
&s->_ob_prev    0x0096c3ec
&s->ob_refcnt   0x0096c3f0
&s->ob_type     0x0096c3f4
&s->sock_fd     0x0096c3f8
&s->sock_family 0x0096c3fc
&s->sock_type   0x0096c400
&s->sock_proto  0x0096c404
&s->sock_addr   0x0096c408
&s->errorhandler 0x0096c488

But there's a radical disconnect about where it thinks
sock_timeout lives:

&s->sock_timeout    0x0096c490
&Sock->sock_timeout 0x0096c48c

Indeed,

    printf("%d\n", sizeof(PySocketSockObject));

displays different results:

socketmodule.c: 176
_ssl.c:         172

I'm unclear about why.  Doing

    printf("%d\n", sizeof(sock_addr_t));

prints 128 in both modules, so there's not an obvious
difference there.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-04-01 18:08

Message:
Logged In: YES 
user_id=31435

BTW, does anyone understand why this part of my first
comment was true?:

"""
check_socket_and_wait_for_timeout() takes the "else if
(s->sock_timeout == 0.0)" path and and returns
SOCKET_IS_NONBLOCKING.
"""

How did s->sock_timeout become 0?  s.settimeout(30.0) was
called, and the same s was passed to socket.ssl().  I don't
understand this at all:

>>> s.connect(("gmail.org", 995))
>>> s.gettimeout()
30.0
>>> s._sock
<socket object, fd=1920, family=2, type=1, protocol=0>
>>> s._sock.gettimeout()
30.0
>>> ss = socket.ssl(s)

but a breakpoint in newPySSLObject() right there shows that
Sock->sock_timeout is 0.0.  HTF did that happen?

If I poke 30.0 (under the debugger) into Sock->sock_timeout
at the start of newPySSLObject(), the constructor finishes
unexceptionally.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-04-01 17:57

Message:
Logged In: YES 
user_id=31435

gmail.com happened to respond when I tried it today, so I
can confirm (alas) that the patch at

http://pastebin.com/633224

made no difference to the outcome on Windows.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-03-31 17:36

Message:
Logged In: YES 
user_id=31435

Because the

s.connect(("gmail.org", 995))

line started timing out on all (non-Windows) buildbot slaves
some hours ago, causing all test runs to fail, I disabled
test_timeout on all boxes for now (on trunk & on 2.4 branch).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-03-31 15:23

Message:
Logged In: YES 
user_id=31435

Note that this is a problem in 2.4 and trunk.

The sample code worked fine earlier today if (and only if) I
left out the .settimeout() call.

Note that buildbot test runs are failing in trunk and 2.4
branch now on non-Windows boxes, because the

s.connect(("gmail.org", 995))

line is timing out (the new test is disabled on Windows, and
that's why the Windows buildbots are still passing).  At the
moment, that's timing out on my Windows box too.  We clearly
need a more reliable net address to connect to.

On Bug Day IRC, "arekm" last asked that I try this patch on
 Windows:

http://pastebin.com/633224

Unfortunately, I haven't been able to get beyond the
s.connect(("gmail.org", 995)) line since then, so still
don't know whether that helps.  Nothing else did ;-)

On Windows, in newPySSLObject(),
"ret = SSL_connect(self->ssl);" returns -1
"err = SSL_get_error(self->ssl, ret);" returns 2
"if (err == SSL_ERROR_WANT_READ)" triggers.
check_socket_and_wait_for_timeout() takes the "else if
(s->sock_timeout == 0.0)" path and and returns
SOCKET_IS_NONBLOCKING.
newPySSLObject() breaks out of its loop then, and does
"PySSL_SetError(self, ret); goto fail;"

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462352&group_id=5470

From noreply at sourceforge.net  Thu May 11 04:35:46 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 10 May 2006 19:35:46 -0700
Subject: [ python-Bugs-1462352 ] socket.ssl won't work together with
	socket.settimeout on Win
Message-ID: <E1Fe11m-0003n8-MG@sc8-sf-web2.sourceforge.net>

Bugs item #1462352, was opened at 2006-03-31 11:11
Message generated for change (Comment added) made by jasonbrady
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462352&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: Windows
Group: Python 2.4
Status: Closed
Resolution: Fixed
Priority: 6
Submitted By: Georg Brandl (gbrandl)
Assigned to: Trent Mick (tmick)
Summary: socket.ssl won't work together with socket.settimeout on Win

Initial Comment:
Symptoms:

>>> import socket
>>> s = socket.socket()
>>> s.settimeout(30.0)
>>> s.connect(("gmail.org", 995))
>>> ss = socket.ssl(s)
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
   File "C:\python24\lib\socket.py", line 74, in ssl
     return _realssl(sock, keyfile, certfile)
 socket.sslerror: (2, 'The operation did not complete
(read)')

This does not occur on Unix, where
test_socket_ssl.test_timeout runs smoothly.

----------------------------------------------------------------------

Comment By: Jason Brady (jasonbrady)
Date: 2006-05-10 19:35

Message:
Logged In: YES 
user_id=1520816

Sorry for the double post, slash dot doesn't confirm posts
like it does account registration!

----------------------------------------------------------------------

Comment By: Jason Brady (jasonbrady)
Date: 2006-05-10 19:31

Message:
Logged In: YES 
user_id=1520816

I would like to confirm that this bug still exists. A simple
example, from the docs no less, that fails.

If you set any timeout on sockets, and try to make an ssl
connection, you get "socket.sslerror: (2, 'The operation did
not complete (read)')".

This is running on Windows XP Professional, SP2, latest
python 2.4.3.

-------------------------------------------------------------
import socket

print 'Timeout: '
print socket.getdefaulttimeout()
socket.setdefaulttimeout(None)
print 'Timeout: '
print socket.getdefaulttimeout()

import httplib
conn = httplib.HTTPSConnection("sourceforge.net")
conn.request("GET", "/projects/python/")
r1 = conn.getresponse()
print r1.status, r1.reason
data1 = r1.read()
conn.close()
print data1
-----------------------------------------------------------

----------------------------------------------------------------------

Comment By: Jason Brady (jasonbrady)
Date: 2006-05-10 19:30

Message:
Logged In: YES 
user_id=1520816

I would like to confirm that this bug still exists. A simple
example, from the docs no less, that fails.

If you set any timeout on sockets, and try to make an ssl
connection, you get "socket.sslerror: (2, 'The operation did
not complete (read)')".

This is running on Windows XP Professional, SP2, latest
python 2.4.3.

-------------------------------------------------------------
import socket

print 'Timeout: '
print socket.getdefaulttimeout()
socket.setdefaulttimeout(None)
print 'Timeout: '
print socket.getdefaulttimeout()

import httplib
conn = httplib.HTTPSConnection("sourceforge.net")
conn.request("GET", "/projects/python/")
r1 = conn.getresponse()
print r1.status, r1.reason
data1 = r1.read()
conn.close()
print data1
-----------------------------------------------------------

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-04-08 06:00

Message:
Logged In: YES 
user_id=31435

Yup, saw that, but I'd like input from Trent (it's his box):
 why is it timing out at all?  30 seconds is a huge blob of
time, and none of the other buildbots are timing out.  When
I disabled test_socket_ssl's test_timeout, _all_ buildbot
slaves were timing out (because gmail.org simply wasn't
responding to anyone at the time).

IOW, there may be a Win2K-specific bug in the Python
implementation here (note that Trent's is the only Win2K
slave we have).

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-04-08 05:52

Message:
Logged In: YES 
user_id=849994

Now one Windows buildbot turned red again since the timeout
didn't raise socket.timeout but socket.error... :-|

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-04-08 05:48

Message:
Logged In: YES 
user_id=31435

Whoa -- good eye, Martin!  Thank you.  Looks like bugs all
over the place.

FYI, I later rehabilitated the disabled part of
test_socket_ssl, and removed the Windows special-casing, in
revs 43734 (trunk) and 43735 (2.4 branch).

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-08 02:18

Message:
Logged In: YES 
user_id=21627

The problem is that WIN32 isn't initially defined.
WinSock2.h has this structure:

#if !defined(WIN32) && !defined(_WIN64)
#include <pshpack4.h>
#endif

#include <windows.h>

#if !defined(WIN32) && !defined(_WIN64)
#include <poppack.h>
#endif

Even though WIN32 is initially not defined, it is defined
at the end of WinSock2.h, so that the poppack.h is not
included. That leaves a pragma pack(push,4) on the pack
stack. I haven't traced where exactly WIN32 is defined,
but it probably comes from Ole2.h.

Fixed in 43731 and 43732. Not sure whether anything needs to
be done to the test suite.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-04-08 00:48

Message:
Logged In: YES 
user_id=31435

Normal MS struct member alignment is definitely screwed up
inside _ssl.c, but still don't know how that happens. 
sizeof this struct should be 16, but is reported as 12 when
the source is inside _ssl.c:

struct dummy {
    int a;
    double x;
};

(note that in the details in previous comments, the double
&Sock->sock_timeout was not 8-byte aligned in _ssl.c, but
was in socketmodule.c).  I don't see any MS packing pragmas
in any of the OpenSSL .h files either.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-04-07 23:05

Message:
Logged In: YES 
user_id=31435

As a sanity check on all those details, inside newPySSLObject()

*(double *)((char *)&Sock->sock_timeout + 4)

is in fact 30.0.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-04-07 22:25

Message:
Logged In: YES 
user_id=31435

I did a data breakpoint on the 8 bytes in the sock_timeout
member, and it never triggered:  nothing stores anything
there to change 30.0 to 0.0.

Instead, socketmodule.c and _ssl.c have different views of
where the members of a PySocketSockObject live.  WRT
socketmodule.c sock_settimeout's `s`, and _ssl.c
newPySSLObject's `Sock` (which are the same object in the
test case), the debugger agrees about the addresses at which
these members live:

&s->_ob_next    0x0096c3e8
&s->_ob_prev    0x0096c3ec
&s->ob_refcnt   0x0096c3f0
&s->ob_type     0x0096c3f4
&s->sock_fd     0x0096c3f8
&s->sock_family 0x0096c3fc
&s->sock_type   0x0096c400
&s->sock_proto  0x0096c404
&s->sock_addr   0x0096c408
&s->errorhandler 0x0096c488

But there's a radical disconnect about where it thinks
sock_timeout lives:

&s->sock_timeout    0x0096c490
&Sock->sock_timeout 0x0096c48c

Indeed,

    printf("%d\n", sizeof(PySocketSockObject));

displays different results:

socketmodule.c: 176
_ssl.c:         172

I'm unclear about why.  Doing

    printf("%d\n", sizeof(sock_addr_t));

prints 128 in both modules, so there's not an obvious
difference there.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-04-01 18:08

Message:
Logged In: YES 
user_id=31435

BTW, does anyone understand why this part of my first
comment was true?:

"""
check_socket_and_wait_for_timeout() takes the "else if
(s->sock_timeout == 0.0)" path and and returns
SOCKET_IS_NONBLOCKING.
"""

How did s->sock_timeout become 0?  s.settimeout(30.0) was
called, and the same s was passed to socket.ssl().  I don't
understand this at all:

>>> s.connect(("gmail.org", 995))
>>> s.gettimeout()
30.0
>>> s._sock
<socket object, fd=1920, family=2, type=1, protocol=0>
>>> s._sock.gettimeout()
30.0
>>> ss = socket.ssl(s)

but a breakpoint in newPySSLObject() right there shows that
Sock->sock_timeout is 0.0.  HTF did that happen?

If I poke 30.0 (under the debugger) into Sock->sock_timeout
at the start of newPySSLObject(), the constructor finishes
unexceptionally.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-04-01 17:57

Message:
Logged In: YES 
user_id=31435

gmail.com happened to respond when I tried it today, so I
can confirm (alas) that the patch at

http://pastebin.com/633224

made no difference to the outcome on Windows.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-03-31 17:36

Message:
Logged In: YES 
user_id=31435

Because the

s.connect(("gmail.org", 995))

line started timing out on all (non-Windows) buildbot slaves
some hours ago, causing all test runs to fail, I disabled
test_timeout on all boxes for now (on trunk & on 2.4 branch).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-03-31 15:23

Message:
Logged In: YES 
user_id=31435

Note that this is a problem in 2.4 and trunk.

The sample code worked fine earlier today if (and only if) I
left out the .settimeout() call.

Note that buildbot test runs are failing in trunk and 2.4
branch now on non-Windows boxes, because the

s.connect(("gmail.org", 995))

line is timing out (the new test is disabled on Windows, and
that's why the Windows buildbots are still passing).  At the
moment, that's timing out on my Windows box too.  We clearly
need a more reliable net address to connect to.

On Bug Day IRC, "arekm" last asked that I try this patch on
 Windows:

http://pastebin.com/633224

Unfortunately, I haven't been able to get beyond the
s.connect(("gmail.org", 995)) line since then, so still
don't know whether that helps.  Nothing else did ;-)

On Windows, in newPySSLObject(),
"ret = SSL_connect(self->ssl);" returns -1
"err = SSL_get_error(self->ssl, ret);" returns 2
"if (err == SSL_ERROR_WANT_READ)" triggers.
check_socket_and_wait_for_timeout() takes the "else if
(s->sock_timeout == 0.0)" path and and returns
SOCKET_IS_NONBLOCKING.
newPySSLObject() breaks out of its loop then, and does
"PySSL_SetError(self, ret); goto fail;"

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462352&group_id=5470

From noreply at sourceforge.net  Thu May 11 06:16:11 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 10 May 2006 21:16:11 -0700
Subject: [ python-Bugs-1462352 ] socket.ssl won't work together with
	socket.settimeout on Win
Message-ID: <E1Fe2ax-0006gt-DX@sc8-sf-web1.sourceforge.net>

Bugs item #1462352, was opened at 2006-03-31 21:11
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462352&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: Windows
Group: Python 2.4
Status: Closed
Resolution: Fixed
Priority: 6
Submitted By: Georg Brandl (gbrandl)
Assigned to: Trent Mick (tmick)
Summary: socket.ssl won't work together with socket.settimeout on Win

Initial Comment:
Symptoms:

>>> import socket
>>> s = socket.socket()
>>> s.settimeout(30.0)
>>> s.connect(("gmail.org", 995))
>>> ss = socket.ssl(s)
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
   File "C:\python24\lib\socket.py", line 74, in ssl
     return _realssl(sock, keyfile, certfile)
 socket.sslerror: (2, 'The operation did not complete
(read)')

This does not occur on Unix, where
test_socket_ssl.test_timeout runs smoothly.

----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-05-11 06:16

Message:
Logged In: YES 
user_id=21627

jasonbrady, you might be misunderstanding how this bug
tracker is used. When I posted a message on 2006-04-08
saying that this is fixed, I meant what I said: "Fixed in
43731 and 43732." If you go to the download page, you see
that Python 2.4.3 was released on on March 29, 2006. IOW, it
does not contain that fix, and never will - the time machine
doesn't work for that case :-) 

Python 2.4.4 will contain the fix, but we mark the bug as
fixed today already because the "current" source code does
not contain the bug anymore.

----------------------------------------------------------------------

Comment By: Jason Brady (jasonbrady)
Date: 2006-05-11 04:35

Message:
Logged In: YES 
user_id=1520816

Sorry for the double post, slash dot doesn't confirm posts
like it does account registration!

----------------------------------------------------------------------

Comment By: Jason Brady (jasonbrady)
Date: 2006-05-11 04:31

Message:
Logged In: YES 
user_id=1520816

I would like to confirm that this bug still exists. A simple
example, from the docs no less, that fails.

If you set any timeout on sockets, and try to make an ssl
connection, you get "socket.sslerror: (2, 'The operation did
not complete (read)')".

This is running on Windows XP Professional, SP2, latest
python 2.4.3.

-------------------------------------------------------------
import socket

print 'Timeout: '
print socket.getdefaulttimeout()
socket.setdefaulttimeout(None)
print 'Timeout: '
print socket.getdefaulttimeout()

import httplib
conn = httplib.HTTPSConnection("sourceforge.net")
conn.request("GET", "/projects/python/")
r1 = conn.getresponse()
print r1.status, r1.reason
data1 = r1.read()
conn.close()
print data1
-----------------------------------------------------------

----------------------------------------------------------------------

Comment By: Jason Brady (jasonbrady)
Date: 2006-05-11 04:30

Message:
Logged In: YES 
user_id=1520816

I would like to confirm that this bug still exists. A simple
example, from the docs no less, that fails.

If you set any timeout on sockets, and try to make an ssl
connection, you get "socket.sslerror: (2, 'The operation did
not complete (read)')".

This is running on Windows XP Professional, SP2, latest
python 2.4.3.

-------------------------------------------------------------
import socket

print 'Timeout: '
print socket.getdefaulttimeout()
socket.setdefaulttimeout(None)
print 'Timeout: '
print socket.getdefaulttimeout()

import httplib
conn = httplib.HTTPSConnection("sourceforge.net")
conn.request("GET", "/projects/python/")
r1 = conn.getresponse()
print r1.status, r1.reason
data1 = r1.read()
conn.close()
print data1
-----------------------------------------------------------

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-04-08 15:00

Message:
Logged In: YES 
user_id=31435

Yup, saw that, but I'd like input from Trent (it's his box):
 why is it timing out at all?  30 seconds is a huge blob of
time, and none of the other buildbots are timing out.  When
I disabled test_socket_ssl's test_timeout, _all_ buildbot
slaves were timing out (because gmail.org simply wasn't
responding to anyone at the time).

IOW, there may be a Win2K-specific bug in the Python
implementation here (note that Trent's is the only Win2K
slave we have).

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-04-08 14:52

Message:
Logged In: YES 
user_id=849994

Now one Windows buildbot turned red again since the timeout
didn't raise socket.timeout but socket.error... :-|

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-04-08 14:48

Message:
Logged In: YES 
user_id=31435

Whoa -- good eye, Martin!  Thank you.  Looks like bugs all
over the place.

FYI, I later rehabilitated the disabled part of
test_socket_ssl, and removed the Windows special-casing, in
revs 43734 (trunk) and 43735 (2.4 branch).

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-08 11:18

Message:
Logged In: YES 
user_id=21627

The problem is that WIN32 isn't initially defined.
WinSock2.h has this structure:

#if !defined(WIN32) && !defined(_WIN64)
#include <pshpack4.h>
#endif

#include <windows.h>

#if !defined(WIN32) && !defined(_WIN64)
#include <poppack.h>
#endif

Even though WIN32 is initially not defined, it is defined
at the end of WinSock2.h, so that the poppack.h is not
included. That leaves a pragma pack(push,4) on the pack
stack. I haven't traced where exactly WIN32 is defined,
but it probably comes from Ole2.h.

Fixed in 43731 and 43732. Not sure whether anything needs to
be done to the test suite.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-04-08 09:48

Message:
Logged In: YES 
user_id=31435

Normal MS struct member alignment is definitely screwed up
inside _ssl.c, but still don't know how that happens. 
sizeof this struct should be 16, but is reported as 12 when
the source is inside _ssl.c:

struct dummy {
    int a;
    double x;
};

(note that in the details in previous comments, the double
&Sock->sock_timeout was not 8-byte aligned in _ssl.c, but
was in socketmodule.c).  I don't see any MS packing pragmas
in any of the OpenSSL .h files either.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-04-08 08:05

Message:
Logged In: YES 
user_id=31435

As a sanity check on all those details, inside newPySSLObject()

*(double *)((char *)&Sock->sock_timeout + 4)

is in fact 30.0.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-04-08 07:25

Message:
Logged In: YES 
user_id=31435

I did a data breakpoint on the 8 bytes in the sock_timeout
member, and it never triggered:  nothing stores anything
there to change 30.0 to 0.0.

Instead, socketmodule.c and _ssl.c have different views of
where the members of a PySocketSockObject live.  WRT
socketmodule.c sock_settimeout's `s`, and _ssl.c
newPySSLObject's `Sock` (which are the same object in the
test case), the debugger agrees about the addresses at which
these members live:

&s->_ob_next    0x0096c3e8
&s->_ob_prev    0x0096c3ec
&s->ob_refcnt   0x0096c3f0
&s->ob_type     0x0096c3f4
&s->sock_fd     0x0096c3f8
&s->sock_family 0x0096c3fc
&s->sock_type   0x0096c400
&s->sock_proto  0x0096c404
&s->sock_addr   0x0096c408
&s->errorhandler 0x0096c488

But there's a radical disconnect about where it thinks
sock_timeout lives:

&s->sock_timeout    0x0096c490
&Sock->sock_timeout 0x0096c48c

Indeed,

    printf("%d\n", sizeof(PySocketSockObject));

displays different results:

socketmodule.c: 176
_ssl.c:         172

I'm unclear about why.  Doing

    printf("%d\n", sizeof(sock_addr_t));

prints 128 in both modules, so there's not an obvious
difference there.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-04-02 04:08

Message:
Logged In: YES 
user_id=31435

BTW, does anyone understand why this part of my first
comment was true?:

"""
check_socket_and_wait_for_timeout() takes the "else if
(s->sock_timeout == 0.0)" path and and returns
SOCKET_IS_NONBLOCKING.
"""

How did s->sock_timeout become 0?  s.settimeout(30.0) was
called, and the same s was passed to socket.ssl().  I don't
understand this at all:

>>> s.connect(("gmail.org", 995))
>>> s.gettimeout()
30.0
>>> s._sock
<socket object, fd=1920, family=2, type=1, protocol=0>
>>> s._sock.gettimeout()
30.0
>>> ss = socket.ssl(s)

but a breakpoint in newPySSLObject() right there shows that
Sock->sock_timeout is 0.0.  HTF did that happen?

If I poke 30.0 (under the debugger) into Sock->sock_timeout
at the start of newPySSLObject(), the constructor finishes
unexceptionally.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-04-02 03:57

Message:
Logged In: YES 
user_id=31435

gmail.com happened to respond when I tried it today, so I
can confirm (alas) that the patch at

http://pastebin.com/633224

made no difference to the outcome on Windows.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-04-01 03:36

Message:
Logged In: YES 
user_id=31435

Because the

s.connect(("gmail.org", 995))

line started timing out on all (non-Windows) buildbot slaves
some hours ago, causing all test runs to fail, I disabled
test_timeout on all boxes for now (on trunk & on 2.4 branch).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-04-01 01:23

Message:
Logged In: YES 
user_id=31435

Note that this is a problem in 2.4 and trunk.

The sample code worked fine earlier today if (and only if) I
left out the .settimeout() call.

Note that buildbot test runs are failing in trunk and 2.4
branch now on non-Windows boxes, because the

s.connect(("gmail.org", 995))

line is timing out (the new test is disabled on Windows, and
that's why the Windows buildbots are still passing).  At the
moment, that's timing out on my Windows box too.  We clearly
need a more reliable net address to connect to.

On Bug Day IRC, "arekm" last asked that I try this patch on
 Windows:

http://pastebin.com/633224

Unfortunately, I haven't been able to get beyond the
s.connect(("gmail.org", 995)) line since then, so still
don't know whether that helps.  Nothing else did ;-)

On Windows, in newPySSLObject(),
"ret = SSL_connect(self->ssl);" returns -1
"err = SSL_get_error(self->ssl, ret);" returns 2
"if (err == SSL_ERROR_WANT_READ)" triggers.
check_socket_and_wait_for_timeout() takes the "else if
(s->sock_timeout == 0.0)" path and and returns
SOCKET_IS_NONBLOCKING.
newPySSLObject() breaks out of its loop then, and does
"PySSL_SetError(self, ret); goto fail;"

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462352&group_id=5470

From noreply at sourceforge.net  Thu May 11 06:31:05 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 10 May 2006 21:31:05 -0700
Subject: [ python-Bugs-1046077 ] urllib2: better import ftplib and gopherlib
	etc late
Message-ID: <E1Fe2pN-0004Nw-7B@sc8-sf-web2.sourceforge.net>

Bugs item #1046077, was opened at 2004-10-13 11:41
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1046077&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: Closed
>Resolution: Out of Date
Priority: 5
Submitted By: kxroberto (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2: better import ftplib and gopherlib etc late

Initial Comment:
I've always trouble shrinking a py2exe'd package,
because of this. its also a speed issue. urllib2 is
most time used only with http(s) ...?

*** urllib2_old.py	Tue May 11 16:14:34 2004
--- urllib2.py	Wed Oct 13 11:32:44 2004
*************** f = urllib2.urlopen('http://www.python.o
*** 88,95 ****
  # check digest against correct (i.e. non-apache)
implementation
  
  import base64
- import ftplib
- import gopherlib
  import httplib
  import inspect
  import md5
--- 88,93 ----
*************** class FileHandler(BaseHandler):
*** 1009,1014 ****
--- 1007,1013 ----
  
  class FTPHandler(BaseHandler):
      def ftp_open(self, req):
+         import ftplib
          host = req.get_host()
          if not host:
              raise IOError, ('ftp error', 'no host given')
*************** class CacheFTPHandler(FTPHandler):
*** 1110,1115 ****
--- 1109,1115 ----
  
  class GopherHandler(BaseHandler):
      def gopher_open(self, req):
+         import gopherlib
          host = req.get_host()
          if not host:
              raise GopherError('no host given')


----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-05-11 06:31

Message:
Logged In: YES 
user_id=21627

Closing this as out-of-date; it is replaced by #1484793.

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2005-05-19 22:38

Message:
Logged In: YES 
user_id=261020

Since Jeremy doesn't like the idea, this should probably be
closed, but:

Robert re-submitted this as patch 1053150.


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2004-11-07 15:42

Message:
Logged In: YES 
user_id=31392

I'd rather not move imports from their typical place for a
small performance chance in an unusual use case.


----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2004-10-16 00:55

Message:
Logged In: YES 
user_id=593130

Since you have a patch, this should have been submitted as 
a patch rather than a bug.  In any case, the patch needs to 
be submitted as separate file

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1046077&group_id=5470

From noreply at sourceforge.net  Thu May 11 11:14:42 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 11 May 2006 02:14:42 -0700
Subject: [ python-Bugs-1486335 ] httplib: read/_read_chunked failes with
	ValueError sometime
Message-ID: <E1Fe7Fq-00013J-Ro@sc8-sf-web2.sourceforge.net>

Bugs item #1486335, was opened at 2006-05-11 11:14
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=1486335&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: kxroberto (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: httplib: read/_read_chunked failes with ValueError sometime

Initial Comment:
This occasionally shows up in a logged trace, when a
application crahes on ValueError on a
http(s)_response.read() :

(py2.3.5 - yet relevant httplib code is still the same
in current httplib) 


.... \'  File "socket.pyo", line 283,
in read\\n\', \'  File "httplib.pyo", line 389, in
read\\n\', \'  File "httplib.pyo", line 426, in
_read_chunked\\n\', \'ValueError: invalid literal for
int(): \\n\']  :::

its the line:

chunk_left = int(line, 16)


Don't know what this line is about. Yet, that should be
protected, as a http_response.read() should not fail
with ValueError, but only with
IOError/EnvironmentError, socket.error - otherwise
Error Exception handling becomes a random task.

-Robert


Side note regarding IO exception handling: See also FR
#1481036 (IOBaseError): why socket.error.__bases__ is
(<class exceptions.Exception at 0x011244E0>,)  ?


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1486335&group_id=5470

From noreply at sourceforge.net  Thu May 11 14:05:52 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 11 May 2006 05:05:52 -0700
Subject: [ python-Bugs-978833 ] SSL-ed sockets don't close correct?
Message-ID: <E1Fe9vU-0003FT-U5@sc8-sf-web3.sourceforge.net>

Bugs item #978833, was opened at 2004-06-24 11:57
Message generated for change (Comment added) made by kxroberto
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=978833&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: 8
Submitted By: kxroberto (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: SSL-ed sockets don't close correct?

Initial Comment:
When testing FTP over SSL I have strong doubt, that
ssl-ed sockets are not closed correctly. (This doesn't
show with https because nobody takes care about whats
going on "after the party".) See the following :

---

I need to run FTP over SSL from windows (not shitty
sftp via ssh etc!)
as explained on
http://www.ford-hutchinson.com/~fh-1-pfh/ftps-ext.html
(good variant
3: FTP_TLS )

I tried to learn from M2Crypto's ftpslib.py (uses
OpenSSL - not
Pythons SSL) and made a wrapper for ftplib.FTP using
Pythons SSL.

I wrap the cmd socket like:

        self.voidcmd('AUTH TLS')
        ssl = socket.ssl(self.sock, self.key_file,
self.cert_file)
        import httplib
        self.sock = httplib.FakeSocket(self.sock, ssl)
        self.file = self.sock.makefile('rb')

Everything works ok, if I don't SSL the data port
connection, but only
the
If I SSL the data port connection too, it almosts work,
but ...

        self.voidcmd('PBSZ 0')
        self.voidcmd('PROT P')

wrap the data connection with SSL:

            ssl = socket.ssl(conn, self.key_file,
self.cert_file)
            import httplib
            conn = httplib.FakeSocket(conn, ssl)

than in retrbinary it hangs endless in the last 'return
self.voidresp()'. all data of the retrieved file is
already correctly
in my basket! The ftp server just won't send the final
'226 Transfer
complete.' on the cmd socket. Why?

    def retrbinary(self, cmd, callback, blocksize=8192,
rest=None):
        self.voidcmd('TYPE I')
        conn = self.transfercmd(cmd, rest)
        fp = conn.makefile('rb')
        while 1:
            #data = conn.recv(blocksize)
            data = fp.read()    #blocksize)
            if not data:
                break
            callback(data)
        fp.close()
        conn.close()
        return self.voidresp()


what could be reason? 
The server is a ProFTPD 1.2.9 Server.
I debugged, that the underlying (Shared)socket of the
conn object is
really closed.
(If I simly omit the self.voidresp(), I have one file
in the box, but
subsequent ftp communication on that connection is not
anymore
correct.)

----------------------------------------------------------------------

>Comment By: kxroberto (kxroberto)
Date: 2006-05-11 14:05

Message:
Logged In: YES 
user_id=972995

Testing it with Python2.5a2, the problem is still there.

Without the .shutdown(2) (or .shutdown(1)) patch to the
httplib.SharedSocket (base for FakeSocket), the ftps example
freezes on the cmd channel, because the SSL'ed data channel
doesn't close/terminate --> FTPS server doesn't respond on
the cmd channel. The ftps example is most specific to show
the bug. 

Yet you can also easily blow up a HTTPS-server with this
decent test code who only opens (bigger!) files and closes
without reading everything:

Python 2.5a2 (r25a2:45740, May 11 2006, 11:25:30)
[GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
Robert's Interactive Python - TAB=complete
import sys,os,re,string,time,glob,thread,pdb
>>> import urllib
>>> l=[]
>>> for i in range(10):
...    f=urllib.urlopen('https://srv/big-Python-2.5a2.tgz')
...    f.close()
...    l.append(f)
...
>>>


=> in the (apache) servers ssl_engine_log you can see that
connections remain open (until apache times out after 2
minutes) and lots of extra apache daemons are started!

=> f.close() doesn't really close the connection (until it
is __del__'ed )


Trying around I found that the original undeleted f.fp._ssl
is most probably the cause and holds the real socket open. 
a f.fp._sock.close() doesn't close also  - but only when del
f.fp._ssl is done. (only a f.fp._sock._sock.close() would
force the close). The original fp is held in closures of
.readline(s)/__iter__/next... 

--

I now tried an alternative patch (instead of the
shutdown(2)-patch), which also so far seems to cure
everything . Maybe thats the right solution for the bug:

--- httplib.py.orig     2006-05-11 11:25:32.000000000 +0200
+++ httplib.py  2006-05-11 13:45:07.000000000 +0200
@@ -970,6 +970,7 @@
             self._shared.decref()
             self._closed = 1
             self._shared = None
+            self._ssl = None

 class SSLFile(SharedSocketClient):
     """File-like object wrapping an SSL socket."""
@@ -1085,6 +1086,7 @@
     def close(self):
         SharedSocketClient.close(self)
         self._sock = self.__class__._closedsocket()
+        self._ssl = None

     def makefile(self, mode, bufsize=None):
         if mode != 'r' and mode != 'rb':


--------------



In another application with SSL'ed SMTP connections there
arose similar problems.

I also worked around the problem in smtplib.py so far in a
similar style:

    def close(self):
        self.realsock.shutdown(2)
        self.realsock.close()


---

Yet, the right patch maybe (not tested extensively so far):


--- Lib-orig/smtplib.py 2006-05-03 13:10:40.000000000 +0200
+++ Lib/smtplib.py      2006-05-11 13:50:12.000000000 +0200
@@ -142,6 +142,7 @@
     sendall = send

     def close(self):
+        self.sslobj = None
         self.realsock.close()

 class SSLFakeFile:
@@ -161,7 +162,7 @@
         return str

     def close(self):
-        pass
+        self.sslobj = None

 def quoteaddr(addr):
     """Quote a subset of the email addresses defined by RFC
821.


------------------

-robert

----------------------------------------------------------------------

Comment By: kxroberto (kxroberto)
Date: 2005-09-24 21:45

Message:
Logged In: YES 
user_id=972995

Now I managed to solve the problem for me with attached
patch of httplib.py: a explicit shutdown ( 2 or 1 ) of the
(faked) ssl'ed socket solves it. 
I still guess the ssl'ed socket (ssl dll) should do that
auto on sock.close() 
Thus I  leave it as a bug HERE. Right?

[ I also have the hope, that this also solves the
ssl-eof-errors with https (of some of my users; will see
this in future)


*** \usr\src\py24old/httplib.py Sat Sep 24 21:35:28 2005
--- httplib.py  Sat Sep 24 21:37:48 2005
*************** class SharedSocket:
*** 899,904 ****
--- 899,905 ----
          self._refcnt -= 1
          assert self._refcnt >= 0
          if self._refcnt == 0:
+             self.sock.shutdown(2)
              self.sock.close()

      def __del__(self):

----------------------------------------------------------------------

Comment By: kxroberto (kxroberto)
Date: 2005-09-24 21:06

Message:
Logged In: YES 
user_id=972995

I retried that again with py2.4.1. The problem/bug is still
there.

In attachment I supplied a full FTPS client test_ftpslib.py
with simple test function - ready to run into the problem:
At the end of ftp.retrlines 'return self.voidresp()' 
freezes : waiting eternally for response bytes at the
command port. the same at the end of .storelines after the
data is transfered on the data port.

My preliminary guess is still, that python's ssl has a
severe (EOF?) problem closing a socket/connection correctly.
 obviously this problem doesn't show up with https because
everything is done on one connection - no dependency on a
correct socket/connect close signal.

(from other https communication with some proxies in between
my users get ssl-eof-error errors also. I still can't solve
that bug too. this shows python's ssl has a severe EOF bug
with complex https also - or cannot handle certain
situations correct.)

I learned the FTPS/TLS client from M2crypto's ftpslib. the
only difference in (transposed) logic, that I can see is,
that M2crpyto uses an additional line
"conn.set_session(self.sock.get_session())" during setup of
the data port ssl connection. I don't know what it is,
pythons ssl doesn't have sucht "session"-functions, but I
think it has no severe meaning.?

Robert

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-12-22 06:14

Message:
Logged In: YES 
user_id=357491

Since I believe this was fixed with the patch Tino mentions and Roberto 
has not replied, I am closing as fixed.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-08-17 01:18

Message:
Logged In: YES 
user_id=357491

Is this still a problem for you, Roberto, with Python 2.4a2?

----------------------------------------------------------------------

Comment By: Tino Lange (tinolange)
Date: 2004-07-11 00:30

Message:
Logged In: YES 
user_id=212920

Hi Roberto!

Today a patch for _ssl.c was checked in (see #945642) that
might solve your problem, too.

Could you please grab the *next* alpha (this will be Python
2.4 Alpha 2) and test and report afterwards if it is solved?

Thanks for your help!

Tino


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=978833&group_id=5470

From noreply at sourceforge.net  Thu May 11 18:17:05 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 11 May 2006 09:17:05 -0700
Subject: [ python-Bugs-1486663 ] Over-zealous keyword-arguments check for
	built-in set class
Message-ID: <E1FeDqb-0005CZ-7P@sc8-sf-web4-b.sourceforge.net>

Bugs item #1486663, was opened at 2006-05-11 17:17
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1486663&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: dib (dib_at_work)
Assigned to: Nobody/Anonymous (nobody)
Summary: Over-zealous keyword-arguments check for built-in set class

Initial Comment:
The fix for bug #1119418 (xrange() builtin accepts
keyword arg silently) included in Python 2.4.2c1+
breaks code that passes keyword argument(s) into
classes derived from the built-in set class, even if
those derived classes explictly accept those keyword
arguments and avoid passing them down to the built-in
base class.

Simplified version of code in attached
BuiltinSetKeywordArgumentsCheckBroken.py fails at (G)
due to bug #1119418 if version < 2.4.2c1; if version >=
2.4.2c1 (G) passes thanks to that bug fix, but instead
(H) incorrectly-in-my-view fails.

[Presume similar cases would fail for xrange and the
other classes mentioned in #1119418.]

  -- David Bruce

(Tested on 2.4, 2.4.2, 2.5a2 on linux2, win32.)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1486663&group_id=5470

From noreply at sourceforge.net  Thu May 11 18:18:14 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 11 May 2006 09:18:14 -0700
Subject: [ python-Bugs-1486663 ] Over-zealous keyword-arguments check for
	built-in set class
Message-ID: <E1FeDri-0000Bx-E8@sc8-sf-web1.sourceforge.net>

Bugs item #1486663, was opened at 2006-05-11 17:17
Message generated for change (Settings changed) made by dib_at_work
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1486663&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: 6
Submitted By: dib (dib_at_work)
Assigned to: Nobody/Anonymous (nobody)
Summary: Over-zealous keyword-arguments check for built-in set class

Initial Comment:
The fix for bug #1119418 (xrange() builtin accepts
keyword arg silently) included in Python 2.4.2c1+
breaks code that passes keyword argument(s) into
classes derived from the built-in set class, even if
those derived classes explictly accept those keyword
arguments and avoid passing them down to the built-in
base class.

Simplified version of code in attached
BuiltinSetKeywordArgumentsCheckBroken.py fails at (G)
due to bug #1119418 if version < 2.4.2c1; if version >=
2.4.2c1 (G) passes thanks to that bug fix, but instead
(H) incorrectly-in-my-view fails.

[Presume similar cases would fail for xrange and the
other classes mentioned in #1119418.]

  -- David Bruce

(Tested on 2.4, 2.4.2, 2.5a2 on linux2, win32.)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1486663&group_id=5470

From noreply at sourceforge.net  Thu May 11 19:23:47 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 11 May 2006 10:23:47 -0700
Subject: [ python-Bugs-1486663 ] Over-zealous keyword-arguments check for
	built-in set class
Message-ID: <E1FeEt9-0001Ce-L9@sc8-sf-web3.sourceforge.net>

Bugs item #1486663, was opened at 2006-05-11 16:17
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1486663&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: 6
Submitted By: dib (dib_at_work)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: Over-zealous keyword-arguments check for built-in set class

Initial Comment:
The fix for bug #1119418 (xrange() builtin accepts
keyword arg silently) included in Python 2.4.2c1+
breaks code that passes keyword argument(s) into
classes derived from the built-in set class, even if
those derived classes explictly accept those keyword
arguments and avoid passing them down to the built-in
base class.

Simplified version of code in attached
BuiltinSetKeywordArgumentsCheckBroken.py fails at (G)
due to bug #1119418 if version < 2.4.2c1; if version >=
2.4.2c1 (G) passes thanks to that bug fix, but instead
(H) incorrectly-in-my-view fails.

[Presume similar cases would fail for xrange and the
other classes mentioned in #1119418.]

  -- David Bruce

(Tested on 2.4, 2.4.2, 2.5a2 on linux2, win32.)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1486663&group_id=5470

From noreply at sourceforge.net  Thu May 11 19:23:58 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 11 May 2006 10:23:58 -0700
Subject: [ python-Bugs-1486663 ] Over-zealous keyword-arguments check for
	built-in set class
Message-ID: <E1FeEtK-0001Gc-DN@sc8-sf-web3.sourceforge.net>

Bugs item #1486663, was opened at 2006-05-11 16:17
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1486663&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: 6
Submitted By: dib (dib_at_work)
Assigned to: Raymond Hettinger (rhettinger)
Summary: Over-zealous keyword-arguments check for built-in set class

Initial Comment:
The fix for bug #1119418 (xrange() builtin accepts
keyword arg silently) included in Python 2.4.2c1+
breaks code that passes keyword argument(s) into
classes derived from the built-in set class, even if
those derived classes explictly accept those keyword
arguments and avoid passing them down to the built-in
base class.

Simplified version of code in attached
BuiltinSetKeywordArgumentsCheckBroken.py fails at (G)
due to bug #1119418 if version < 2.4.2c1; if version >=
2.4.2c1 (G) passes thanks to that bug fix, but instead
(H) incorrectly-in-my-view fails.

[Presume similar cases would fail for xrange and the
other classes mentioned in #1119418.]

  -- David Bruce

(Tested on 2.4, 2.4.2, 2.5a2 on linux2, win32.)

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-05-11 17:23

Message:
Logged In: YES 
user_id=849994

Raymond, what to do in this case?

Note that other built-in types, such as list(), do accept
keyword arguments.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1486663&group_id=5470

From noreply at sourceforge.net  Thu May 11 23:44:52 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 11 May 2006 14:44:52 -0700
Subject: [ python-Bugs-1486897 ] OS X framework build for python 2.5 fails,
	configure is odd
Message-ID: <E1FeIxo-0002v3-Bv@sc8-sf-web3.sourceforge.net>

Bugs item #1486897, was opened at 2006-05-11 14:44
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=1486897&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: Christopher Knox (vizowl)
Assigned to: Nobody/Anonymous (nobody)
Summary: OS X framework build for python 2.5 fails, configure is odd

Initial Comment:
The OS X framework build for python 2.5 does not install a dynamic 
library at /Library/Frameworks/Python.framework/Versions/2.5/Python 
where it should. The python2.5 executible does not run because it is 
trying to load this dynamic library.

This is on an intel mac with darwin-8.6.1 and gcc4 and python2.5a2.

Also all of the extra modules (_CG extension, IDLE extra) fail to link 
because their link command is -lpython2.5 which is not what it should be 
for a framework build and even if it was correct for linking agianst a 
framework it would fil because the framework doesn't have its library 
anyway.

Finally, the configure script behaves oddly in that it works fine, but if you 
change the parameters and rerun it it will fail unless you run 'make 
distclean'

This is where it fails.

checking whether mmap with MAP_ANON(YMOUS) works... yes
configure: error: "libffi has not been ported to i686-apple-darwin8.6.1."
Failed to configure _ctypes module

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1486897&group_id=5470

From noreply at sourceforge.net  Fri May 12 04:21:43 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 11 May 2006 19:21:43 -0700
Subject: [ python-Bugs-944394 ] No examples or usage docs for urllib2
Message-ID: <200605120221.k4C2LhdU008113@sc8-sf-db2-new-b.sourceforge.net>

Bugs item #944394, was opened at 04/29/04 04:02
Message generated for change (Comment added) made by sf-robot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=944394&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: Closed
Resolution: None
Priority: 5
Submitted By: Chris Withers (fresh)
Assigned to: Nobody/Anonymous (nobody)
Summary: No examples or usage docs for urllib2

Initial Comment:
Hi there,

I'm sure I reported this before, but it's a couple of
major releases later, and there's still no usage docs
for urllib2.

The examples given are too trivial to be helpful, but
I'm guessing people are using the module so there must
be some examples out there somewhere ;-)

With a bit o fhelp from Moshez, I found the docstring
in the module source. At the very least, it'd be handy
if that appeared somewhere at:

http://docs.python.org/lib/module-urllib2.html

But really, mroe extensive and helpful documentation on
this cool new module would be very handy.

Chris

----------------------------------------------------------------------

>Comment By: SourceForge Robot (sf-robot)
Date: 05/11/06 19:21

Message:
Logged In: YES 
user_id=1312539

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 04/27/06 06:06

Message:
Logged In: YES 
user_id=849994

Chris, I concur with jjlee that suggesting examples is the
best way to get something done. Perhaps, if you're using
urllib2, you could flesh out some examples from your code?

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 04/17/06 07:26

Message:
Logged In: YES 
user_id=261020

Do you have any specific suggestions for what is unhelpful
and/or missing?

Otherwise, nothing is likely to change.

Note that a little was added at the bottom of this page in
2.4, explaining how OpenerDirector uses the handlers to open
URLs:

http://docs.python.org/lib/opener-director-objects.html

Looking at the top-level page, I guess an introduction /
overview would help?  Did you have other stuff in mind too?


----------------------------------------------------------------------

Comment By: Chris Withers (fresh)
Date: 04/17/06 07:19

Message:
Logged In: YES 
user_id=24723

I still feel there could be more.

I guess the best course, for me, would be to leave this open
but at a really low priority.

However, I probably wouldn't scream too much if the issue
was closed.

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 04/15/06 11:49

Message:
Logged In: YES 
user_id=261020

They are here: http://docs.python.org/lib/urllib2-examples.html

----------------------------------------------------------------------

Comment By: Chris Withers (fresh)
Date: 04/15/06 11:07

Message:
Logged In: YES 
user_id=24723

Where are these examples you're referring to?

I don't see any at:
http://docs.python.org/lib/module-urllib2.html

I've already commented that the existing ones in the
docstring would be a start but still don't really much help
in taking full advantage of this module.

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 04/15/06 10:34

Message:
Logged In: YES 
user_id=261020

Examples for urllib2 were added some time ago, so I suggest
this bug is closed.

----------------------------------------------------------------------

Comment By: Chris Withers (fresh)
Date: 06/01/04 01:17

Message:
Logged In: YES 
user_id=24723

I'm certainly willing, but I am totally incapable :-S

The reason I opened this issue is because it would seem that
urllib2 is better the urllib, but seems to be severely
underdocumented, and hence I don't understand how to use it
and so can't provide examples.

As I said in the original submission, including the module's
docstring in the Python module documentation would be a
start, but doesn't cover what appears to be the full
potential of a great module...

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 05/31/04 14:15

Message:
Logged In: YES 
user_id=21627

Are you willing to provide examples?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=944394&group_id=5470

From noreply at sourceforge.net  Fri May 12 07:51:43 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 11 May 2006 22:51:43 -0700
Subject: [ python-Bugs-1487105 ] 2.5 rev 45972 fails build on Mac-Intel
Message-ID: <E1FeQYx-0008DQ-1C@sc8-sf-web4-b.sourceforge.net>

Bugs item #1487105, was opened at 2006-05-12 07:51
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=1487105&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: 7
Submitted By: Alex Martelli (aleax)
Assigned to: Nobody/Anonymous (nobody)
Summary: 2.5 rev 45972 fails build on Mac-Intel

Initial Comment:
brain:~/py25 alex$ make
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes   Parser/acceler.o 
Parser/grammar1.o Parser/listnode.o Parser/node.o Parser/parser.o 
Parser/parsetok.o Parser/bitset.o Parser/metagrammar.o Parser/
firstsets.o Parser/grammar.o Parser/pgen.o Objects/obmalloc.o Python/
mysnprintf.o Parser/tokenizer_pgen.o Parser/printgrammar.o Parser/
pgenmain.o -ldl  -o Parser/pgen
/usr/bin/ld: warning Parser/printgrammar.o cputype (18, architecture 
ppc) does not match cputype (7) for specified -arch flag: i386 (file not 
loaded)
/usr/bin/ld: Undefined symbols:
__Py_printgrammar
__Py_printnonterminals
collect2: ld returned 1 exit status
make: *** [Parser/pgen] Error 1
brain:~/py25 alex$ 

This is a MacBook Pro with gcc version 4.0.1 (Apple Computer, Inc. build 
5250) -- not sure why there's an "architecture ppc" found somewhere, 
haven't looked at it in detail yet, but at any rate this breaks the make.


Alex


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1487105&group_id=5470

From noreply at sourceforge.net  Fri May 12 15:13:40 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 12 May 2006 06:13:40 -0700
Subject: [ python-Bugs-1487389 ] datetime.time and datetime.timedelta
Message-ID: <E1FeXSe-0001Nn-IU@sc8-sf-web2.sourceforge.net>

Bugs item #1487389, was opened at 2006-05-12 13: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=1487389&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: Chris Withers (fresh)
Assigned to: Nobody/Anonymous (nobody)
Summary: datetime.time and datetime.timedelta

Initial Comment:
print datetime.time(hour=0)+datetime.timedelta(hours=1) 

...gives...

TypeError: unsupported operand type(s) for +:
'datetime.time' and 'datetime.timedelta'

Which is a bit frustrating :-/

Does it really need to be this way?

Chris

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1487389&group_id=5470

From noreply at sourceforge.net  Fri May 12 15:57:57 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 12 May 2006 06:57:57 -0700
Subject: [ python-Feature Requests-1477968 ] Drop py.ico and pyc.ico
Message-ID: <E1FeY9V-0003ho-8A@sc8-sf-web3.sourceforge.net>

Feature Requests item #1477968, was opened at 2006-04-27 22:34
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1477968&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 7
Submitted By: Martin v. L??wis (loewis)
Assigned to: Martin v. L??wis (loewis)
Summary: Drop py.ico and pyc.ico

Initial Comment:
These files should be dropped from the Windows
distribution, as they duplication python_icon.exe, and
confuse tab completion.

----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-05-12 15:57

Message:
Logged In: YES 
user_id=21627

It turns out that it isn't possible to refer to the location
of the Icon table files from the Registry table, so that
cannot be done.

However, to improve tab completion, the icon files have been
moved into the DLLs dir in r45975.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1477968&group_id=5470

From noreply at sourceforge.net  Fri May 12 15:58:05 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 12 May 2006 06:58:05 -0700
Subject: [ python-Bugs-1487420 ] can't pickle slice objects
Message-ID: <E1FeY9d-0006At-31@sc8-sf-web4-b.sourceforge.net>

Bugs item #1487420, was opened at 2006-05-12 16:58
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=1487420&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: ganges master (gangesmaster)
Assigned to: Nobody/Anonymous (nobody)
Summary: can't pickle slice objects

Initial Comment:
for some reason, slices are not-picklable.
i guess someone just forgot to add support 
for those

>>> import pickle
>>> pickle.dumps(slice(1,2,3))
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "D:\Python24\Lib\pickle.py", line 1386, in dumps
    Pickler(file, protocol, bin).dump(obj)
  File "D:\Python24\Lib\pickle.py", line 231, in dump
    self.save(obj)
  File "D:\Python24\Lib\pickle.py", line 313, in save
    rv = reduce(self.proto)
  File "D:\Python24\Lib\copy_reg.py", line 69, in
_reduce_ex
    raise TypeError, "can't pickle %s objects" %
base.__name__
TypeError: can't pickle slice objects
>>>

-tomer

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1487420&group_id=5470

From noreply at sourceforge.net  Fri May 12 15:58:46 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 12 May 2006 06:58:46 -0700
Subject: [ python-Bugs-1431582 ] long path support in win32 part of
	os.listdir(posixmodule.c)
Message-ID: <E1FeYAI-0006OD-3W@sc8-sf-web4-b.sourceforge.net>

Bugs item #1431582, was opened at 2006-02-14 16:44
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1431582&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: Platform-specific
>Status: Closed
>Resolution: Fixed
Priority: 7
Submitted By: Sergey Dorofeev (fidoman)
Assigned to: Martin v. L??wis (loewis)
Summary: long path support in win32 part of os.listdir(posixmodule.c)

Initial Comment:
When passing path to os.listdir that is longer then 
MAX_PATH (what is supported in Windows API, 
http://msdn.microsoft.com/library/default.asp?
url=/library/en-us/fileio/fs/naming_a_file.asp) the 
path is truncated at position MAX_PATH=260 and 
appended with "/*.*", so underlying Windows API 
function FindFirstFileW gets garbage on input: 
original path truncated, and symbol "/" is added, 
which may not be used as path separator in long path.
I think posix_listdir should or raise error when 
getting extra long string, or pass it unchanged to 
underlying API.
Affected code is in Modules\posixmodule.c, lines 1470-
1478 (Python 2.4.2).
I think there is enough to change base when 
calculating size of allocated memory and copied block 
from fixed value of MAX_PATH to length of passed to 
function string.
And use os.sep instead of "/", of course.


----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-05-12 15:58

Message:
Logged In: YES 
user_id=21627

This has been fixed in r45973.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1431582&group_id=5470

From noreply at sourceforge.net  Fri May 12 16:06:31 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 12 May 2006 07:06:31 -0700
Subject: [ python-Feature Requests-1485576 ] Backwards compatibility support
	for Py_ssize_t
Message-ID: <E1FeYHn-0006Lx-3S@sc8-sf-web3.sourceforge.net>

Feature Requests item #1485576, was opened at 2006-05-10 15:28
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1485576&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: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Konrad Hinsen (hinsen)
Assigned to: Nobody/Anonymous (nobody)
Summary: Backwards compatibility support for Py_ssize_t

Initial Comment:
PEP353 recommends to add the following code snippet to extension 
modules to ensure compatibility with pre-2.5 interpreters:

#if PY_VERSION_HEX < 0x02050000
typedef int Py_ssize_t;
#define PY_SSIZE_T_MAX INT_MAX
#define PY_SSIZE_T_MIN INT_MIN
#endif

This is insufficient, because type definitions that use Py_ssize_t must 
also be added. Here is what works for me, though they may be more 
definitions to be included:

#if PY_VERSION_HEX < 0x02050000
typedef int Py_ssize_t;
#define PY_SSIZE_T_MAX INT_MAX
#define PY_SSIZE_T_MIN INT_MIN
typedef Py_ssize_t (*lenfunc)(PyObject *);
typedef PyObject *(*ssizeargfunc)(PyObject *, Py_ssize_t);
typedef PyObject *(*ssizessizeargfunc)(PyObject *, Py_ssize_t, 
Py_ssize_t);
typedef int(*ssizeobjargproc)(PyObject *, Py_ssize_t, PyObject *);
typedef int(*ssizessizeobjargproc)(PyObject *, Py_ssize_t, Py_ssize_t, 
PyObject *);
typedef Py_ssize_t (*readbufferproc)(PyObject *, Py_ssize_t, void **);
typedef Py_ssize_t (*writebufferproc)(PyObject *, Py_ssize_t, void **);
typedef Py_ssize_t (*segcountproc)(PyObject *, Py_ssize_t *);
typedef Py_ssize_t (*charbufferproc)(PyObject *, Py_ssize_t, char **);
#endif

However, the main problem is elsewhere. Extension modules may well 
need to use Py_ssize_t in their own data types, and may furthermore 
with to make these data types available to yet other extension 
modules. In practice, this requires the inclusion of a code block such 
as the one shown above inside header files. However, this requires a 
mechanism for avoiding redefinitions, which at the moment does not 
seem to exist. My request is to add such a mechanism to Python 2.5 
and recommend its consistent use in an update of PEP353.

Concretely, I propose that Python 2.5 should define a macro 
PY_HAS_PY_SSIZE_T, and that PEP353 should recommend the inclusion 
of the code snippet

#ifndef PY_HAS_PY_SSIZE_T
#define PY_HAS_PY_SSIZE_T
typedef int Py_ssize_t;

/* add all the other definitions here */

#endif

that contains an exhaustive set of definitions that depend on 
Py_ssize_t.


----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-05-12 16:06

Message:
Logged In: YES 
user_id=21627

Please re-read the section immediately following the #ifdef
code in PEP 353. It explains how you should avoid these
other typedefs.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1485576&group_id=5470

From noreply at sourceforge.net  Fri May 12 16:14:29 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 12 May 2006 07:14:29 -0700
Subject: [ python-Bugs-1417699 ] float/atof have become locale aware
Message-ID: <E1FeYPV-0003q6-PM@sc8-sf-web1.sourceforge.net>

Bugs item #1417699, was opened at 2006-01-29 02:04
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1417699&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: 7
Submitted By: Bernhard Herzog (bernhard)
>Assigned to: Nobody/Anonymous (nobody)
Summary: float/atof have become locale aware

Initial Comment:
The builtin float and the function string.atof have
become locale aware in Python 2.4:

Python 2.4.2 (#1, Nov 29 2005, 16:07:55) 
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import locale
>>> import string
>>> locale.setlocale(locale.LC_ALL, "de_DE")
'de_DE'
>>> float("1,5")
1.5
>>> string.atof("1,5")
1.5


This doesn't match what's specified in pep 331:

        - float() and str() stay locale-unaware.

It also doesn't match the documentation for atof:

  Convert a string to a floating point number.
  The string must have the standard syntax for a
  floating point literal in Python, optionally
  preceded by a sign ("+" or "-"). Note that this
  behaves identical to the built-in function float()
  when passed a string.

The documentation for float() doesn't state which
format is accepted by float(), though.

The reason for this behavior is ultimately, that
PyOS_ascii_strtod accepts the locale specific
convention in addition to the "C"-locale/python
convention, even though the comment in the code
preceding its definition states:

  This function behaves like the standard strtod() 
  function does in the C locale.




----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-05-12 16:14

Message:
Logged In: YES 
user_id=21627

Unassigning myself - I don't plan to work on this anytime soon.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-05-08 20:00

Message:
Logged In: YES 
user_id=849994

I grepped around and found PyOS_ascii_strtod in the
following places:

* stropmodule::atof
* cPickle::load_float (the writing of locale dependent
floats was fixed recently)
* floatobject::PyFloat_FromString
* complexobject::complex_subtype_from_string

In my opinion, all these should not tolerate localized
floats, so Gustavo, please ask the original author how to
achieve this.

----------------------------------------------------------------------

Comment By: Gustavo J. A. M. Carneiro (gustavo)
Date: 2006-05-04 11:47

Message:
Logged In: YES 
user_id=908

My comment is, is "PyOS_ascii_strtod accepting both forms"
something that is harmful and should be fixed?

I didn't exactly write the PyOS_ascii_strtod code; I only
integrated it with Python.  But if we really need to fix
this, I'll try to figure out how to make it not accept
floating points in locale aware format; if necessary I'll
ask help from  the original author of the code, Alexander
Larsson.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-05-04 06:42

Message:
Logged In: YES 
user_id=21627

It's a bug. As bernhard says, it originates from
PyOS_ascii_strtod accepting both forms, which in turn
happens because it just leaves the locale-specific decimal
point in the string, only replacing the . with the
locale-specific point. Then, the platform's strtod will
happily accept the locale-specific version. 

I'd like Gustavo Carneiro to comment.

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-17 13:19

Message:
Logged In: YES 
user_id=1188172

Martin, you checked in the patch which is mentioned in PEP
331. Is this correct behavior?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1417699&group_id=5470

From noreply at sourceforge.net  Fri May 12 16:18:46 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 12 May 2006 07:18:46 -0700
Subject: [ python-Feature Requests-1485576 ] Backwards compatibility support
	for Py_ssize_t
Message-ID: <E1FeYTe-00059Z-OB@sc8-sf-web1.sourceforge.net>

Feature Requests item #1485576, was opened at 2006-05-10 13:28
Message generated for change (Comment added) made by hinsen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1485576&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: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Konrad Hinsen (hinsen)
Assigned to: Nobody/Anonymous (nobody)
Summary: Backwards compatibility support for Py_ssize_t

Initial Comment:
PEP353 recommends to add the following code snippet to extension 
modules to ensure compatibility with pre-2.5 interpreters:

#if PY_VERSION_HEX < 0x02050000
typedef int Py_ssize_t;
#define PY_SSIZE_T_MAX INT_MAX
#define PY_SSIZE_T_MIN INT_MIN
#endif

This is insufficient, because type definitions that use Py_ssize_t must 
also be added. Here is what works for me, though they may be more 
definitions to be included:

#if PY_VERSION_HEX < 0x02050000
typedef int Py_ssize_t;
#define PY_SSIZE_T_MAX INT_MAX
#define PY_SSIZE_T_MIN INT_MIN
typedef Py_ssize_t (*lenfunc)(PyObject *);
typedef PyObject *(*ssizeargfunc)(PyObject *, Py_ssize_t);
typedef PyObject *(*ssizessizeargfunc)(PyObject *, Py_ssize_t, 
Py_ssize_t);
typedef int(*ssizeobjargproc)(PyObject *, Py_ssize_t, PyObject *);
typedef int(*ssizessizeobjargproc)(PyObject *, Py_ssize_t, Py_ssize_t, 
PyObject *);
typedef Py_ssize_t (*readbufferproc)(PyObject *, Py_ssize_t, void **);
typedef Py_ssize_t (*writebufferproc)(PyObject *, Py_ssize_t, void **);
typedef Py_ssize_t (*segcountproc)(PyObject *, Py_ssize_t *);
typedef Py_ssize_t (*charbufferproc)(PyObject *, Py_ssize_t, char **);
#endif

However, the main problem is elsewhere. Extension modules may well 
need to use Py_ssize_t in their own data types, and may furthermore 
with to make these data types available to yet other extension 
modules. In practice, this requires the inclusion of a code block such 
as the one shown above inside header files. However, this requires a 
mechanism for avoiding redefinitions, which at the moment does not 
seem to exist. My request is to add such a mechanism to Python 2.5 
and recommend its consistent use in an update of PEP353.

Concretely, I propose that Python 2.5 should define a macro 
PY_HAS_PY_SSIZE_T, and that PEP353 should recommend the inclusion 
of the code snippet

#ifndef PY_HAS_PY_SSIZE_T
#define PY_HAS_PY_SSIZE_T
typedef int Py_ssize_t;

/* add all the other definitions here */

#endif

that contains an exhaustive set of definitions that depend on 
Py_ssize_t.


----------------------------------------------------------------------

>Comment By: Konrad Hinsen (hinsen)
Date: 2006-05-12 14:18

Message:
Logged In: YES 
user_id=11850

I have read that section, but I am not yet convinced that I can avoid those 
casts with all common C compilers - and since I cannot try them all, I'd rather 
play safe and keep the casts. If they were never necessary, why were those 
typedefs introduced at all?

Anyway, it is not the additional typedefs that are the essence of my feature 
request. The main issue is that if multiple header files introduce Py_ssize_t, 
the compiler will stop with an error message.


----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-05-12 14:06

Message:
Logged In: YES 
user_id=21627

Please re-read the section immediately following the #ifdef
code in PEP 353. It explains how you should avoid these
other typedefs.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1485576&group_id=5470

From noreply at sourceforge.net  Fri May 12 16:26:23 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 12 May 2006 07:26:23 -0700
Subject: [ python-Feature Requests-1485576 ] Backwards compatibility support
	for Py_ssize_t
Message-ID: <E1FeYb1-0004EL-QR@sc8-sf-web3.sourceforge.net>

Feature Requests item #1485576, was opened at 2006-05-10 13:28
Message generated for change (Comment added) made by hinsen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1485576&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: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Konrad Hinsen (hinsen)
Assigned to: Nobody/Anonymous (nobody)
Summary: Backwards compatibility support for Py_ssize_t

Initial Comment:
PEP353 recommends to add the following code snippet to extension 
modules to ensure compatibility with pre-2.5 interpreters:

#if PY_VERSION_HEX < 0x02050000
typedef int Py_ssize_t;
#define PY_SSIZE_T_MAX INT_MAX
#define PY_SSIZE_T_MIN INT_MIN
#endif

This is insufficient, because type definitions that use Py_ssize_t must 
also be added. Here is what works for me, though they may be more 
definitions to be included:

#if PY_VERSION_HEX < 0x02050000
typedef int Py_ssize_t;
#define PY_SSIZE_T_MAX INT_MAX
#define PY_SSIZE_T_MIN INT_MIN
typedef Py_ssize_t (*lenfunc)(PyObject *);
typedef PyObject *(*ssizeargfunc)(PyObject *, Py_ssize_t);
typedef PyObject *(*ssizessizeargfunc)(PyObject *, Py_ssize_t, 
Py_ssize_t);
typedef int(*ssizeobjargproc)(PyObject *, Py_ssize_t, PyObject *);
typedef int(*ssizessizeobjargproc)(PyObject *, Py_ssize_t, Py_ssize_t, 
PyObject *);
typedef Py_ssize_t (*readbufferproc)(PyObject *, Py_ssize_t, void **);
typedef Py_ssize_t (*writebufferproc)(PyObject *, Py_ssize_t, void **);
typedef Py_ssize_t (*segcountproc)(PyObject *, Py_ssize_t *);
typedef Py_ssize_t (*charbufferproc)(PyObject *, Py_ssize_t, char **);
#endif

However, the main problem is elsewhere. Extension modules may well 
need to use Py_ssize_t in their own data types, and may furthermore 
with to make these data types available to yet other extension 
modules. In practice, this requires the inclusion of a code block such 
as the one shown above inside header files. However, this requires a 
mechanism for avoiding redefinitions, which at the moment does not 
seem to exist. My request is to add such a mechanism to Python 2.5 
and recommend its consistent use in an update of PEP353.

Concretely, I propose that Python 2.5 should define a macro 
PY_HAS_PY_SSIZE_T, and that PEP353 should recommend the inclusion 
of the code snippet

#ifndef PY_HAS_PY_SSIZE_T
#define PY_HAS_PY_SSIZE_T
typedef int Py_ssize_t;

/* add all the other definitions here */

#endif

that contains an exhaustive set of definitions that depend on 
Py_ssize_t.


----------------------------------------------------------------------

>Comment By: Konrad Hinsen (hinsen)
Date: 2006-05-12 14:26

Message:
Logged In: YES 
user_id=11850

Here is an illustration of my problem. Given the following three files:

-- foo.h -------------------------
#include <Python.h>

#if PY_VERSION_HEX < 0x02050000
typedef int Py_ssize_t;
#endif

typedef struct {
  Py_ssize_t index;
} foo;


-- bar.h -------------------------

#include <Python.h>

#if PY_VERSION_HEX < 0x02050000
typedef int Py_ssize_t;
#endif

typedef struct {
  Py_ssize_t index;
} bar;


-- foobar.c ----------------------

#include "foo.h"
#include "bar.h"

foo a;
bar b;

int main(int argc, char **argv) {
  return 0;
}

----------------------------------

I get from gcc:

gcc foobar.c 
In file included from foobar.c:1:
foo.h:1:20: error: Python.h: No such file or directory
In file included from foobar.c:2:
bar.h:4: error: redefinition of typedef 'Py_ssize_t'
foo.h:4: error: previous declaration of 'Py_ssize_t' was here

I see no solution to this problem that would work in the most general case in 
which all three files are part of different packages written by different 
authors, i.e. in the absence of a coordination.


----------------------------------------------------------------------

Comment By: Konrad Hinsen (hinsen)
Date: 2006-05-12 14:18

Message:
Logged In: YES 
user_id=11850

I have read that section, but I am not yet convinced that I can avoid those 
casts with all common C compilers - and since I cannot try them all, I'd rather 
play safe and keep the casts. If they were never necessary, why were those 
typedefs introduced at all?

Anyway, it is not the additional typedefs that are the essence of my feature 
request. The main issue is that if multiple header files introduce Py_ssize_t, 
the compiler will stop with an error message.


----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-05-12 14:06

Message:
Logged In: YES 
user_id=21627

Please re-read the section immediately following the #ifdef
code in PEP 353. It explains how you should avoid these
other typedefs.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1485576&group_id=5470

From noreply at sourceforge.net  Fri May 12 16:34:26 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 12 May 2006 07:34:26 -0700
Subject: [ python-Feature Requests-1485576 ] Backwards compatibility support
	for Py_ssize_t
Message-ID: <E1FeYio-0005kR-8S@sc8-sf-web2.sourceforge.net>

Feature Requests item #1485576, was opened at 2006-05-10 13:28
Message generated for change (Comment added) made by hinsen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1485576&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: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Konrad Hinsen (hinsen)
Assigned to: Nobody/Anonymous (nobody)
Summary: Backwards compatibility support for Py_ssize_t

Initial Comment:
PEP353 recommends to add the following code snippet to extension 
modules to ensure compatibility with pre-2.5 interpreters:

#if PY_VERSION_HEX < 0x02050000
typedef int Py_ssize_t;
#define PY_SSIZE_T_MAX INT_MAX
#define PY_SSIZE_T_MIN INT_MIN
#endif

This is insufficient, because type definitions that use Py_ssize_t must 
also be added. Here is what works for me, though they may be more 
definitions to be included:

#if PY_VERSION_HEX < 0x02050000
typedef int Py_ssize_t;
#define PY_SSIZE_T_MAX INT_MAX
#define PY_SSIZE_T_MIN INT_MIN
typedef Py_ssize_t (*lenfunc)(PyObject *);
typedef PyObject *(*ssizeargfunc)(PyObject *, Py_ssize_t);
typedef PyObject *(*ssizessizeargfunc)(PyObject *, Py_ssize_t, 
Py_ssize_t);
typedef int(*ssizeobjargproc)(PyObject *, Py_ssize_t, PyObject *);
typedef int(*ssizessizeobjargproc)(PyObject *, Py_ssize_t, Py_ssize_t, 
PyObject *);
typedef Py_ssize_t (*readbufferproc)(PyObject *, Py_ssize_t, void **);
typedef Py_ssize_t (*writebufferproc)(PyObject *, Py_ssize_t, void **);
typedef Py_ssize_t (*segcountproc)(PyObject *, Py_ssize_t *);
typedef Py_ssize_t (*charbufferproc)(PyObject *, Py_ssize_t, char **);
#endif

However, the main problem is elsewhere. Extension modules may well 
need to use Py_ssize_t in their own data types, and may furthermore 
with to make these data types available to yet other extension 
modules. In practice, this requires the inclusion of a code block such 
as the one shown above inside header files. However, this requires a 
mechanism for avoiding redefinitions, which at the moment does not 
seem to exist. My request is to add such a mechanism to Python 2.5 
and recommend its consistent use in an update of PEP353.

Concretely, I propose that Python 2.5 should define a macro 
PY_HAS_PY_SSIZE_T, and that PEP353 should recommend the inclusion 
of the code snippet

#ifndef PY_HAS_PY_SSIZE_T
#define PY_HAS_PY_SSIZE_T
typedef int Py_ssize_t;

/* add all the other definitions here */

#endif

that contains an exhaustive set of definitions that depend on 
Py_ssize_t.


----------------------------------------------------------------------

>Comment By: Konrad Hinsen (hinsen)
Date: 2006-05-12 14:34

Message:
Logged In: YES 
user_id=11850

Oops, I forgot the -I option, but that doesn't really make a difference.

For Python 2.5:

gcc -I /usr/local/include/python2.5 foobar.c 

--> no error message

For Python 2.4:

gcc -I /Library/Frameworks/Python.framework/Versions/2.4/include/
python2.4 foobar.c 
In file included from /Library/Frameworks/Python.framework/Versions/2.4/
include/python2.4/Python.h:55,
                 from foo.h:1,
                 from foobar.c:1:
/Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/
pyport.h:396: warning: 'struct winsize' declared inside parameter list
/Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/
pyport.h:397: warning: 'struct winsize' declared inside parameter list
In file included from foobar.c:2:
bar.h:4: error: redefinition of typedef 'Py_ssize_t'
foo.h:4: error: previous declaration of 'Py_ssize_t' was here


----------------------------------------------------------------------

Comment By: Konrad Hinsen (hinsen)
Date: 2006-05-12 14:26

Message:
Logged In: YES 
user_id=11850

Here is an illustration of my problem. Given the following three files:

-- foo.h -------------------------
#include <Python.h>

#if PY_VERSION_HEX < 0x02050000
typedef int Py_ssize_t;
#endif

typedef struct {
  Py_ssize_t index;
} foo;


-- bar.h -------------------------

#include <Python.h>

#if PY_VERSION_HEX < 0x02050000
typedef int Py_ssize_t;
#endif

typedef struct {
  Py_ssize_t index;
} bar;


-- foobar.c ----------------------

#include "foo.h"
#include "bar.h"

foo a;
bar b;

int main(int argc, char **argv) {
  return 0;
}

----------------------------------

I get from gcc:

gcc foobar.c 
In file included from foobar.c:1:
foo.h:1:20: error: Python.h: No such file or directory
In file included from foobar.c:2:
bar.h:4: error: redefinition of typedef 'Py_ssize_t'
foo.h:4: error: previous declaration of 'Py_ssize_t' was here

I see no solution to this problem that would work in the most general case in 
which all three files are part of different packages written by different 
authors, i.e. in the absence of a coordination.


----------------------------------------------------------------------

Comment By: Konrad Hinsen (hinsen)
Date: 2006-05-12 14:18

Message:
Logged In: YES 
user_id=11850

I have read that section, but I am not yet convinced that I can avoid those 
casts with all common C compilers - and since I cannot try them all, I'd rather 
play safe and keep the casts. If they were never necessary, why were those 
typedefs introduced at all?

Anyway, it is not the additional typedefs that are the essence of my feature 
request. The main issue is that if multiple header files introduce Py_ssize_t, 
the compiler will stop with an error message.


----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-05-12 14:06

Message:
Logged In: YES 
user_id=21627

Please re-read the section immediately following the #ifdef
code in PEP 353. It explains how you should avoid these
other typedefs.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1485576&group_id=5470

From noreply at sourceforge.net  Fri May 12 17:32:42 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 12 May 2006 08:32:42 -0700
Subject: [ python-Bugs-1487481 ] Could BIND_FIRST be removed on HP-UX?
Message-ID: <E1FeZdC-0007D2-H7@sc8-sf-web4-b.sourceforge.net>

Bugs item #1487481, was opened at 2006-05-12 17:32
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=1487481&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: Tkinter
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: G?ran Uddeborg (goeran)
Assigned to: Martin v. L??wis (loewis)
Summary: Could BIND_FIRST be removed on HP-UX?

Initial Comment:
I'm trying to build Python 2.4.3 on HP-UX 11.  I need
tkinter, so I have first built Tcl and Tk 8.4.13.

During the build, the python interpreter crashes.  When
running the setup.py script, just after making the
_tkinter.sl module, it crashes with a memory fault.

I've tried to investigate this, and it seems that
malloc and friends gets confused by the dynamic
loading.  I've filed a support request with HP about this.

One observation I made is that this malloc bug seems to
be connected with the use of BIND_FIRST in
dynload_hpux.c.  If I just remove this flag (in two
places) it appears as if Python works normally.

I'm hesitant if this is a good idea.  BIND_FIRST is
there as an explicit, non-default, flag.  Somebody must
have choosen to do so for some reason.  What was that
reason?  And is it still valid?  If not, maybe the flag
could be removed, and this problem in HP-UX be avoided?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1487481&group_id=5470

From noreply at sourceforge.net  Fri May 12 17:36:53 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 12 May 2006 08:36:53 -0700
Subject: [ python-Bugs-1487481 ] Could BIND_FIRST be removed on HP-UX?
Message-ID: <E1FeZhF-0007Xg-Rs@sc8-sf-web1.sourceforge.net>

Bugs item #1487481, was opened at 2006-05-12 17:32
Message generated for change (Settings changed) made by goeran
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1487481&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: G?ran Uddeborg (goeran)
Assigned to: Martin v. L??wis (loewis)
Summary: Could BIND_FIRST be removed on HP-UX?

Initial Comment:
I'm trying to build Python 2.4.3 on HP-UX 11.  I need
tkinter, so I have first built Tcl and Tk 8.4.13.

During the build, the python interpreter crashes.  When
running the setup.py script, just after making the
_tkinter.sl module, it crashes with a memory fault.

I've tried to investigate this, and it seems that
malloc and friends gets confused by the dynamic
loading.  I've filed a support request with HP about this.

One observation I made is that this malloc bug seems to
be connected with the use of BIND_FIRST in
dynload_hpux.c.  If I just remove this flag (in two
places) it appears as if Python works normally.

I'm hesitant if this is a good idea.  BIND_FIRST is
there as an explicit, non-default, flag.  Somebody must
have choosen to do so for some reason.  What was that
reason?  And is it still valid?  If not, maybe the flag
could be removed, and this problem in HP-UX be avoided?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1487481&group_id=5470

From noreply at sourceforge.net  Fri May 12 18:15:47 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 12 May 2006 09:15:47 -0700
Subject: [ python-Feature Requests-1487389 ] datetime.time and
	datetime.timedelta
Message-ID: <E1FeaIt-0002zF-Sx@sc8-sf-web4-b.sourceforge.net>

Feature Requests item #1487389, was opened at 2006-05-12 09:13
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1487389&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: Chris Withers (fresh)
Assigned to: Nobody/Anonymous (nobody)
Summary: datetime.time and datetime.timedelta

Initial Comment:
print datetime.time(hour=0)+datetime.timedelta(hours=1) 

...gives...

TypeError: unsupported operand type(s) for +:
'datetime.time' and 'datetime.timedelta'

Which is a bit frustrating :-/

Does it really need to be this way?

Chris

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2006-05-12 12:15

Message:
Logged In: YES 
user_id=31435

Since the lack of arithmetic on `time` objects is both
intended and documented, this isn't "a bug".  I moved this
to the Feature Requests tracker.

The problem with arithmetic on time objects is that it's not
obvious what to do in case of overflow or underflow:  wrap
around or raise OverflowError?  Either way violates _some_
reasonable expectation.  Embed your time in a `datetime`
object and then you can decide what you want to do.  For
example, if you want to wrap around,

>>> print (datetime.combine(date.today(), time(hour=0)) -
timedelta(hours=1)).time()
23:00:00


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1487389&group_id=5470

From noreply at sourceforge.net  Fri May 12 22:32:34 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 12 May 2006 13:32:34 -0700
Subject: [ python-Feature Requests-1485576 ] Backwards compatibility support
	for Py_ssize_t
Message-ID: <E1FeeJO-0007Ph-GL@sc8-sf-web3.sourceforge.net>

Feature Requests item #1485576, was opened at 2006-05-10 15:28
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1485576&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: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Konrad Hinsen (hinsen)
Assigned to: Nobody/Anonymous (nobody)
Summary: Backwards compatibility support for Py_ssize_t

Initial Comment:
PEP353 recommends to add the following code snippet to extension 
modules to ensure compatibility with pre-2.5 interpreters:

#if PY_VERSION_HEX < 0x02050000
typedef int Py_ssize_t;
#define PY_SSIZE_T_MAX INT_MAX
#define PY_SSIZE_T_MIN INT_MIN
#endif

This is insufficient, because type definitions that use Py_ssize_t must 
also be added. Here is what works for me, though they may be more 
definitions to be included:

#if PY_VERSION_HEX < 0x02050000
typedef int Py_ssize_t;
#define PY_SSIZE_T_MAX INT_MAX
#define PY_SSIZE_T_MIN INT_MIN
typedef Py_ssize_t (*lenfunc)(PyObject *);
typedef PyObject *(*ssizeargfunc)(PyObject *, Py_ssize_t);
typedef PyObject *(*ssizessizeargfunc)(PyObject *, Py_ssize_t, 
Py_ssize_t);
typedef int(*ssizeobjargproc)(PyObject *, Py_ssize_t, PyObject *);
typedef int(*ssizessizeobjargproc)(PyObject *, Py_ssize_t, Py_ssize_t, 
PyObject *);
typedef Py_ssize_t (*readbufferproc)(PyObject *, Py_ssize_t, void **);
typedef Py_ssize_t (*writebufferproc)(PyObject *, Py_ssize_t, void **);
typedef Py_ssize_t (*segcountproc)(PyObject *, Py_ssize_t *);
typedef Py_ssize_t (*charbufferproc)(PyObject *, Py_ssize_t, char **);
#endif

However, the main problem is elsewhere. Extension modules may well 
need to use Py_ssize_t in their own data types, and may furthermore 
with to make these data types available to yet other extension 
modules. In practice, this requires the inclusion of a code block such 
as the one shown above inside header files. However, this requires a 
mechanism for avoiding redefinitions, which at the moment does not 
seem to exist. My request is to add such a mechanism to Python 2.5 
and recommend its consistent use in an update of PEP353.

Concretely, I propose that Python 2.5 should define a macro 
PY_HAS_PY_SSIZE_T, and that PEP353 should recommend the inclusion 
of the code snippet

#ifndef PY_HAS_PY_SSIZE_T
#define PY_HAS_PY_SSIZE_T
typedef int Py_ssize_t;

/* add all the other definitions here */

#endif

that contains an exhaustive set of definitions that depend on 
Py_ssize_t.


----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-05-12 22:32

Message:
Logged In: YES 
user_id=21627

I understand your request, and I sympathize with it
(although I would call the macro Py_ssize_t_defined).

However, I find it equally important that the other issue
gets understood, as well. The macros are not necessary for
portable code, and they never were.

They were introduced for convenience only, so that you can
have the actual type name for the self parameter (e.g.
FooObject* instead of PyObject*). If the signatures are
corrected to have PyObject* as their first parameter, the
casts *should* become unnecessary. If they are then still
required, that indicates a serious programming error.

The evilness of these casts comes from the fact that they
can silence warnings that would point to severe type errors
if the cast wouldn't silence them. For example, if the
parameter order or the number is wrong for one of these
functions, the compiler won't notice because of the cast.
The cast is only there to convert the first parameter
(self), yet it can manage to convert any other parameter, as
well. 

So getting these function pointers type correct not only
increases portabiltiy in the presence of Py_ssize_t, but
also improves correctness and readability of the code.

----------------------------------------------------------------------

Comment By: Konrad Hinsen (hinsen)
Date: 2006-05-12 16:34

Message:
Logged In: YES 
user_id=11850

Oops, I forgot the -I option, but that doesn't really make a difference.

For Python 2.5:

gcc -I /usr/local/include/python2.5 foobar.c 

--> no error message

For Python 2.4:

gcc -I /Library/Frameworks/Python.framework/Versions/2.4/include/
python2.4 foobar.c 
In file included from /Library/Frameworks/Python.framework/Versions/2.4/
include/python2.4/Python.h:55,
                 from foo.h:1,
                 from foobar.c:1:
/Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/
pyport.h:396: warning: 'struct winsize' declared inside parameter list
/Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/
pyport.h:397: warning: 'struct winsize' declared inside parameter list
In file included from foobar.c:2:
bar.h:4: error: redefinition of typedef 'Py_ssize_t'
foo.h:4: error: previous declaration of 'Py_ssize_t' was here


----------------------------------------------------------------------

Comment By: Konrad Hinsen (hinsen)
Date: 2006-05-12 16:26

Message:
Logged In: YES 
user_id=11850

Here is an illustration of my problem. Given the following three files:

-- foo.h -------------------------
#include <Python.h>

#if PY_VERSION_HEX < 0x02050000
typedef int Py_ssize_t;
#endif

typedef struct {
  Py_ssize_t index;
} foo;


-- bar.h -------------------------

#include <Python.h>

#if PY_VERSION_HEX < 0x02050000
typedef int Py_ssize_t;
#endif

typedef struct {
  Py_ssize_t index;
} bar;


-- foobar.c ----------------------

#include "foo.h"
#include "bar.h"

foo a;
bar b;

int main(int argc, char **argv) {
  return 0;
}

----------------------------------

I get from gcc:

gcc foobar.c 
In file included from foobar.c:1:
foo.h:1:20: error: Python.h: No such file or directory
In file included from foobar.c:2:
bar.h:4: error: redefinition of typedef 'Py_ssize_t'
foo.h:4: error: previous declaration of 'Py_ssize_t' was here

I see no solution to this problem that would work in the most general case in 
which all three files are part of different packages written by different 
authors, i.e. in the absence of a coordination.


----------------------------------------------------------------------

Comment By: Konrad Hinsen (hinsen)
Date: 2006-05-12 16:18

Message:
Logged In: YES 
user_id=11850

I have read that section, but I am not yet convinced that I can avoid those 
casts with all common C compilers - and since I cannot try them all, I'd rather 
play safe and keep the casts. If they were never necessary, why were those 
typedefs introduced at all?

Anyway, it is not the additional typedefs that are the essence of my feature 
request. The main issue is that if multiple header files introduce Py_ssize_t, 
the compiler will stop with an error message.


----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-05-12 16:06

Message:
Logged In: YES 
user_id=21627

Please re-read the section immediately following the #ifdef
code in PEP 353. It explains how you should avoid these
other typedefs.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1485576&group_id=5470

From noreply at sourceforge.net  Sat May 13 00:28:27 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 12 May 2006 15:28:27 -0700
Subject: [ python-Bugs-1467619 ] Header.decode_header eats up spaces
Message-ID: <E1Feg7X-0000s1-GC@sc8-sf-web2.sourceforge.net>

Bugs item #1467619, was opened at 2006-04-10 12:33
Message generated for change (Comment added) made by alexanderweb
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467619&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: Mathieu Goutelle (mgoutell)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: Header.decode_header eats up spaces

Initial Comment:
The Header.decode_header function eats up spaces in
non-encoded part of a header.

See the following source:
# -*- coding: iso-8859-1 -*-
from email.Header import Header, decode_header
h = Header('Essai ', None)
h.append('????', 'iso-8859-1')
print h
print decode_header(h)

This prints:
Essai =?iso-8859-1?q?=E9=E8?=
[('Test', None), ('\xe9\xe8', 'iso-8859-1')]

This should print:
Essai =?iso-8859-1?q?=E9=E8?=
[('Test ', None), ('\xe9\xe8', 'iso-8859-1')]
       ^ This space disappears

This appears in Python 2.3 but the source code of the
function didn't change in 2.4 so the same problem
should still exist. Bug "[ 1372770 ] email.Header
should preserve original FWS" may be linked to that one
although I'm not sure this is exactly the same.

This patch (not extensively tested though) seems to
solve this problem:

--- /usr/lib/python2.3/email/Header.py  2005-09-05
00:20:03.000000000 +0200
+++ Header.py   2006-04-10 12:27:27.000000000 +0200
@@ -90,7 +90,7 @@
             continue
         parts = ecre.split(line)
         while parts:
-            unenc = parts.pop(0).strip()
+            unenc = parts.pop(0).rstrip()
             if unenc:
                 # Should we continue a long line?
                 if decoded and decoded[-1][1] is None:


----------------------------------------------------------------------

Comment By: Alexander Schremmer (alexanderweb)
Date: 2006-05-13 00:28

Message:
Logged In: YES 
user_id=254738

I can confirm this bug and have been bitten by it as well.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467619&group_id=5470

From noreply at sourceforge.net  Sat May 13 13:59:33 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 13 May 2006 04:59:33 -0700
Subject: [ python-Bugs-1417699 ] float/atof have become locale aware
Message-ID: <E1FesmT-0001GG-Nt@sc8-sf-web4-b.sourceforge.net>

Bugs item #1417699, was opened at 2006-01-29 01:04
Message generated for change (Comment added) made by gustavo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1417699&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: 7
Submitted By: Bernhard Herzog (bernhard)
Assigned to: Nobody/Anonymous (nobody)
Summary: float/atof have become locale aware

Initial Comment:
The builtin float and the function string.atof have
become locale aware in Python 2.4:

Python 2.4.2 (#1, Nov 29 2005, 16:07:55) 
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import locale
>>> import string
>>> locale.setlocale(locale.LC_ALL, "de_DE")
'de_DE'
>>> float("1,5")
1.5
>>> string.atof("1,5")
1.5


This doesn't match what's specified in pep 331:

        - float() and str() stay locale-unaware.

It also doesn't match the documentation for atof:

  Convert a string to a floating point number.
  The string must have the standard syntax for a
  floating point literal in Python, optionally
  preceded by a sign ("+" or "-"). Note that this
  behaves identical to the built-in function float()
  when passed a string.

The documentation for float() doesn't state which
format is accepted by float(), though.

The reason for this behavior is ultimately, that
PyOS_ascii_strtod accepts the locale specific
convention in addition to the "C"-locale/python
convention, even though the comment in the code
preceding its definition states:

  This function behaves like the standard strtod() 
  function does in the C locale.




----------------------------------------------------------------------

Comment By: Gustavo J. A. M. Carneiro (gustavo)
Date: 2006-05-13 12:59

Message:
Logged In: YES 
user_id=908

I'm quite busy at this moment, but I'll send a patch soon,
promise.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-05-12 15:14

Message:
Logged In: YES 
user_id=21627

Unassigning myself - I don't plan to work on this anytime soon.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-05-08 19:00

Message:
Logged In: YES 
user_id=849994

I grepped around and found PyOS_ascii_strtod in the
following places:

* stropmodule::atof
* cPickle::load_float (the writing of locale dependent
floats was fixed recently)
* floatobject::PyFloat_FromString
* complexobject::complex_subtype_from_string

In my opinion, all these should not tolerate localized
floats, so Gustavo, please ask the original author how to
achieve this.

----------------------------------------------------------------------

Comment By: Gustavo J. A. M. Carneiro (gustavo)
Date: 2006-05-04 10:47

Message:
Logged In: YES 
user_id=908

My comment is, is "PyOS_ascii_strtod accepting both forms"
something that is harmful and should be fixed?

I didn't exactly write the PyOS_ascii_strtod code; I only
integrated it with Python.  But if we really need to fix
this, I'll try to figure out how to make it not accept
floating points in locale aware format; if necessary I'll
ask help from  the original author of the code, Alexander
Larsson.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-05-04 05:42

Message:
Logged In: YES 
user_id=21627

It's a bug. As bernhard says, it originates from
PyOS_ascii_strtod accepting both forms, which in turn
happens because it just leaves the locale-specific decimal
point in the string, only replacing the . with the
locale-specific point. Then, the platform's strtod will
happily accept the locale-specific version. 

I'd like Gustavo Carneiro to comment.

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-17 12:19

Message:
Logged In: YES 
user_id=1188172

Martin, you checked in the patch which is mentioned in PEP
331. Is this correct behavior?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1417699&group_id=5470

From noreply at sourceforge.net  Sat May 13 17:49:33 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 13 May 2006 08:49:33 -0700
Subject: [ python-Feature Requests-1487389 ] datetime.time and
	datetime.timedelta
Message-ID: <E1FewN3-0001Cy-HE@sc8-sf-web4-b.sourceforge.net>

Feature Requests item #1487389, was opened at 2006-05-12 13:13
Message generated for change (Comment added) made by fresh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1487389&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: Chris Withers (fresh)
Assigned to: Nobody/Anonymous (nobody)
Summary: datetime.time and datetime.timedelta

Initial Comment:
print datetime.time(hour=0)+datetime.timedelta(hours=1) 

...gives...

TypeError: unsupported operand type(s) for +:
'datetime.time' and 'datetime.timedelta'

Which is a bit frustrating :-/

Does it really need to be this way?

Chris

----------------------------------------------------------------------

>Comment By: Chris Withers (fresh)
Date: 2006-05-13 15:49

Message:
Logged In: YES 
user_id=24723

Well, I think the OverflowError is perfectly correct, and
lets the software author handle that situation in any way
they want.

That said, you could add a keyword option to the
datetime.time constructor to allow it either to wrap round,
or raise OverflowError, with the overflow being the default.

If I resulted up patches for these, how would I get them
into a python release?

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-05-12 16:15

Message:
Logged In: YES 
user_id=31435

Since the lack of arithmetic on `time` objects is both
intended and documented, this isn't "a bug".  I moved this
to the Feature Requests tracker.

The problem with arithmetic on time objects is that it's not
obvious what to do in case of overflow or underflow:  wrap
around or raise OverflowError?  Either way violates _some_
reasonable expectation.  Embed your time in a `datetime`
object and then you can decide what you want to do.  For
example, if you want to wrap around,

>>> print (datetime.combine(date.today(), time(hour=0)) -
timedelta(hours=1)).time()
23:00:00


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1487389&group_id=5470

From noreply at sourceforge.net  Sat May 13 17:51:06 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 13 May 2006 08:51:06 -0700
Subject: [ python-Bugs-944394 ] No examples or usage docs for urllib2
Message-ID: <E1FewOY-0001pu-Ff@sc8-sf-web4-b.sourceforge.net>

Bugs item #944394, was opened at 2004-04-29 11:02
Message generated for change (Settings changed) made by fresh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=944394&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: Chris Withers (fresh)
Assigned to: Nobody/Anonymous (nobody)
Summary: No examples or usage docs for urllib2

Initial Comment:
Hi there,

I'm sure I reported this before, but it's a couple of
major releases later, and there's still no usage docs
for urllib2.

The examples given are too trivial to be helpful, but
I'm guessing people are using the module so there must
be some examples out there somewhere ;-)

With a bit o fhelp from Moshez, I found the docstring
in the module source. At the very least, it'd be handy
if that appeared somewhere at:

http://docs.python.org/lib/module-urllib2.html

But really, mroe extensive and helpful documentation on
this cool new module would be very handy.

Chris

----------------------------------------------------------------------

>Comment By: Chris Withers (fresh)
Date: 2006-05-13 15:51

Message:
Logged In: YES 
user_id=24723

wtf?

----------------------------------------------------------------------

Comment By: SourceForge Robot (sf-robot)
Date: 2006-05-12 02:21

Message:
Logged In: YES 
user_id=1312539

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-04-27 13:06

Message:
Logged In: YES 
user_id=849994

Chris, I concur with jjlee that suggesting examples is the
best way to get something done. Perhaps, if you're using
urllib2, you could flesh out some examples from your code?

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2006-04-17 14:26

Message:
Logged In: YES 
user_id=261020

Do you have any specific suggestions for what is unhelpful
and/or missing?

Otherwise, nothing is likely to change.

Note that a little was added at the bottom of this page in
2.4, explaining how OpenerDirector uses the handlers to open
URLs:

http://docs.python.org/lib/opener-director-objects.html

Looking at the top-level page, I guess an introduction /
overview would help?  Did you have other stuff in mind too?


----------------------------------------------------------------------

Comment By: Chris Withers (fresh)
Date: 2006-04-17 14:19

Message:
Logged In: YES 
user_id=24723

I still feel there could be more.

I guess the best course, for me, would be to leave this open
but at a really low priority.

However, I probably wouldn't scream too much if the issue
was closed.

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2006-04-15 18:49

Message:
Logged In: YES 
user_id=261020

They are here: http://docs.python.org/lib/urllib2-examples.html

----------------------------------------------------------------------

Comment By: Chris Withers (fresh)
Date: 2006-04-15 18:07

Message:
Logged In: YES 
user_id=24723

Where are these examples you're referring to?

I don't see any at:
http://docs.python.org/lib/module-urllib2.html

I've already commented that the existing ones in the
docstring would be a start but still don't really much help
in taking full advantage of this module.

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2006-04-15 17:34

Message:
Logged In: YES 
user_id=261020

Examples for urllib2 were added some time ago, so I suggest
this bug is closed.

----------------------------------------------------------------------

Comment By: Chris Withers (fresh)
Date: 2004-06-01 08:17

Message:
Logged In: YES 
user_id=24723

I'm certainly willing, but I am totally incapable :-S

The reason I opened this issue is because it would seem that
urllib2 is better the urllib, but seems to be severely
underdocumented, and hence I don't understand how to use it
and so can't provide examples.

As I said in the original submission, including the module's
docstring in the Python module documentation would be a
start, but doesn't cover what appears to be the full
potential of a great module...

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2004-05-31 21:15

Message:
Logged In: YES 
user_id=21627

Are you willing to provide examples?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=944394&group_id=5470

From noreply at sourceforge.net  Sat May 13 18:25:28 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 13 May 2006 09:25:28 -0700
Subject: [ python-Bugs-1487966 ] SystemError with conditional expression in
	assignment
Message-ID: <E1Fewvo-0006xk-EA@sc8-sf-web4-b.sourceforge.net>

Bugs item #1487966, was opened at 2006-05-13 18:25
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=1487966&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: ?iga Seilnacht (zseil)
Assigned to: Nobody/Anonymous (nobody)
Summary: SystemError with conditional expression in assignment

Initial Comment:
When a conditional expression appears on the left
side of an assignment, SystemError is raised instead
of SyntaxError. Example:

Python 2.5a2 (trunk:45989M, May 13 2006, 15:40:42)
[MSC v.1310 32 bit (Intel)] on win32

>>> a if True else b = 3
SystemError: unexpected expression in assignment 5 (line 1)


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1487966&group_id=5470

From noreply at sourceforge.net  Sat May 13 18:33:14 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 13 May 2006 09:33:14 -0700
Subject: [ python-Bugs-944394 ] No examples or usage docs for urllib2
Message-ID: <E1Fex3K-00018W-16@sc8-sf-web1.sourceforge.net>

Bugs item #944394, was opened at 2004-04-29 13:02
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=944394&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: Closed
>Resolution: Works For Me
Priority: 5
Submitted By: Chris Withers (fresh)
Assigned to: Nobody/Anonymous (nobody)
Summary: No examples or usage docs for urllib2

Initial Comment:
Hi there,

I'm sure I reported this before, but it's a couple of
major releases later, and there's still no usage docs
for urllib2.

The examples given are too trivial to be helpful, but
I'm guessing people are using the module so there must
be some examples out there somewhere ;-)

With a bit o fhelp from Moshez, I found the docstring
in the module source. At the very least, it'd be handy
if that appeared somewhere at:

http://docs.python.org/lib/module-urllib2.html

But really, mroe extensive and helpful documentation on
this cool new module would be very handy.

Chris

----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-05-13 18:33

Message:
Logged In: YES 
user_id=21627

fresh, you haven't responded to jjlee's questions from
2006-04-17 16:26, so it is unclear what precisely it is that
you want. In absence of a specific problem description, I'm
closing this as "works for me".

----------------------------------------------------------------------

Comment By: Chris Withers (fresh)
Date: 2006-05-13 17:51

Message:
Logged In: YES 
user_id=24723

wtf?

----------------------------------------------------------------------

Comment By: SourceForge Robot (sf-robot)
Date: 2006-05-12 04:21

Message:
Logged In: YES 
user_id=1312539

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-04-27 15:06

Message:
Logged In: YES 
user_id=849994

Chris, I concur with jjlee that suggesting examples is the
best way to get something done. Perhaps, if you're using
urllib2, you could flesh out some examples from your code?

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2006-04-17 16:26

Message:
Logged In: YES 
user_id=261020

Do you have any specific suggestions for what is unhelpful
and/or missing?

Otherwise, nothing is likely to change.

Note that a little was added at the bottom of this page in
2.4, explaining how OpenerDirector uses the handlers to open
URLs:

http://docs.python.org/lib/opener-director-objects.html

Looking at the top-level page, I guess an introduction /
overview would help?  Did you have other stuff in mind too?


----------------------------------------------------------------------

Comment By: Chris Withers (fresh)
Date: 2006-04-17 16:19

Message:
Logged In: YES 
user_id=24723

I still feel there could be more.

I guess the best course, for me, would be to leave this open
but at a really low priority.

However, I probably wouldn't scream too much if the issue
was closed.

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2006-04-15 20:49

Message:
Logged In: YES 
user_id=261020

They are here: http://docs.python.org/lib/urllib2-examples.html

----------------------------------------------------------------------

Comment By: Chris Withers (fresh)
Date: 2006-04-15 20:07

Message:
Logged In: YES 
user_id=24723

Where are these examples you're referring to?

I don't see any at:
http://docs.python.org/lib/module-urllib2.html

I've already commented that the existing ones in the
docstring would be a start but still don't really much help
in taking full advantage of this module.

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2006-04-15 19:34

Message:
Logged In: YES 
user_id=261020

Examples for urllib2 were added some time ago, so I suggest
this bug is closed.

----------------------------------------------------------------------

Comment By: Chris Withers (fresh)
Date: 2004-06-01 10:17

Message:
Logged In: YES 
user_id=24723

I'm certainly willing, but I am totally incapable :-S

The reason I opened this issue is because it would seem that
urllib2 is better the urllib, but seems to be severely
underdocumented, and hence I don't understand how to use it
and so can't provide examples.

As I said in the original submission, including the module's
docstring in the Python module documentation would be a
start, but doesn't cover what appears to be the full
potential of a great module...

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2004-05-31 23:15

Message:
Logged In: YES 
user_id=21627

Are you willing to provide examples?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=944394&group_id=5470

From noreply at sourceforge.net  Sat May 13 18:38:20 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 13 May 2006 09:38:20 -0700
Subject: [ python-Bugs-1487481 ] Could BIND_FIRST be removed on HP-UX?
Message-ID: <E1Fex8G-00038r-I8@sc8-sf-web1.sourceforge.net>

Bugs item #1487481, was opened at 2006-05-12 17:32
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1487481&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: G?ran Uddeborg (goeran)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: Could BIND_FIRST be removed on HP-UX?

Initial Comment:
I'm trying to build Python 2.4.3 on HP-UX 11.  I need
tkinter, so I have first built Tcl and Tk 8.4.13.

During the build, the python interpreter crashes.  When
running the setup.py script, just after making the
_tkinter.sl module, it crashes with a memory fault.

I've tried to investigate this, and it seems that
malloc and friends gets confused by the dynamic
loading.  I've filed a support request with HP about this.

One observation I made is that this malloc bug seems to
be connected with the use of BIND_FIRST in
dynload_hpux.c.  If I just remove this flag (in two
places) it appears as if Python works normally.

I'm hesitant if this is a good idea.  BIND_FIRST is
there as an explicit, non-default, flag.  Somebody must
have choosen to do so for some reason.  What was that
reason?  And is it still valid?  If not, maybe the flag
could be removed, and this problem in HP-UX be avoided?

----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-05-13 18:38

Message:
Logged In: YES 
user_id=21627

BIND_FIRST was added with this commit:

------------------------------------------------------------------------
r7068 | guido | 1996-12-06 00:15:35 +0100 (Fr, 06 Dez 1996)
| 2 lines
Ge??nderte Pfade:
   M /python/trunk/Python/importdl.c

Some extra flags that an HPUX user wants me to add.

------------------------------------------------------------------------

Guido, do you have any records on which user that was
and why he wanted these flags to be added?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1487481&group_id=5470

From noreply at sourceforge.net  Sat May 13 20:09:18 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 13 May 2006 11:09:18 -0700
Subject: [ python-Bugs-944394 ] No examples or usage docs for urllib2
Message-ID: <E1FeyYI-0000CS-Eu@sc8-sf-web3.sourceforge.net>

Bugs item #944394, was opened at 2004-04-29 12:02
Message generated for change (Comment added) made by jjlee
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=944394&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: Closed
Resolution: Works For Me
Priority: 5
Submitted By: Chris Withers (fresh)
Assigned to: Nobody/Anonymous (nobody)
Summary: No examples or usage docs for urllib2

Initial Comment:
Hi there,

I'm sure I reported this before, but it's a couple of
major releases later, and there's still no usage docs
for urllib2.

The examples given are too trivial to be helpful, but
I'm guessing people are using the module so there must
be some examples out there somewhere ;-)

With a bit o fhelp from Moshez, I found the docstring
in the module source. At the very least, it'd be handy
if that appeared somewhere at:

http://docs.python.org/lib/module-urllib2.html

But really, mroe extensive and helpful documentation on
this cool new module would be very handy.

Chris

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2006-05-13 19:09

Message:
Logged In: YES 
user_id=261020

Is this helpful, Chris?

http://svn.python.org/view/python/trunk/Doc/howto/urllib2.rst?view=markup


----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-05-13 17:33

Message:
Logged In: YES 
user_id=21627

fresh, you haven't responded to jjlee's questions from
2006-04-17 16:26, so it is unclear what precisely it is that
you want. In absence of a specific problem description, I'm
closing this as "works for me".

----------------------------------------------------------------------

Comment By: Chris Withers (fresh)
Date: 2006-05-13 16:51

Message:
Logged In: YES 
user_id=24723

wtf?

----------------------------------------------------------------------

Comment By: SourceForge Robot (sf-robot)
Date: 2006-05-12 03:21

Message:
Logged In: YES 
user_id=1312539

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-04-27 14:06

Message:
Logged In: YES 
user_id=849994

Chris, I concur with jjlee that suggesting examples is the
best way to get something done. Perhaps, if you're using
urllib2, you could flesh out some examples from your code?

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2006-04-17 15:26

Message:
Logged In: YES 
user_id=261020

Do you have any specific suggestions for what is unhelpful
and/or missing?

Otherwise, nothing is likely to change.

Note that a little was added at the bottom of this page in
2.4, explaining how OpenerDirector uses the handlers to open
URLs:

http://docs.python.org/lib/opener-director-objects.html

Looking at the top-level page, I guess an introduction /
overview would help?  Did you have other stuff in mind too?


----------------------------------------------------------------------

Comment By: Chris Withers (fresh)
Date: 2006-04-17 15:19

Message:
Logged In: YES 
user_id=24723

I still feel there could be more.

I guess the best course, for me, would be to leave this open
but at a really low priority.

However, I probably wouldn't scream too much if the issue
was closed.

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2006-04-15 19:49

Message:
Logged In: YES 
user_id=261020

They are here: http://docs.python.org/lib/urllib2-examples.html

----------------------------------------------------------------------

Comment By: Chris Withers (fresh)
Date: 2006-04-15 19:07

Message:
Logged In: YES 
user_id=24723

Where are these examples you're referring to?

I don't see any at:
http://docs.python.org/lib/module-urllib2.html

I've already commented that the existing ones in the
docstring would be a start but still don't really much help
in taking full advantage of this module.

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2006-04-15 18:34

Message:
Logged In: YES 
user_id=261020

Examples for urllib2 were added some time ago, so I suggest
this bug is closed.

----------------------------------------------------------------------

Comment By: Chris Withers (fresh)
Date: 2004-06-01 09:17

Message:
Logged In: YES 
user_id=24723

I'm certainly willing, but I am totally incapable :-S

The reason I opened this issue is because it would seem that
urllib2 is better the urllib, but seems to be severely
underdocumented, and hence I don't understand how to use it
and so can't provide examples.

As I said in the original submission, including the module's
docstring in the Python module documentation would be a
start, but doesn't cover what appears to be the full
potential of a great module...

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2004-05-31 22:15

Message:
Logged In: YES 
user_id=21627

Are you willing to provide examples?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=944394&group_id=5470

From noreply at sourceforge.net  Sat May 13 22:50:29 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 13 May 2006 13:50:29 -0700
Subject: [ python-Bugs-1487966 ] SystemError with conditional expression in
	assignment
Message-ID: <E1Ff14H-0001kT-JH@sc8-sf-web2.sourceforge.net>

Bugs item #1487966, was opened at 2006-05-13 18:25
Message generated for change (Comment added) made by zseil
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1487966&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: ?iga Seilnacht (zseil)
Assigned to: Nobody/Anonymous (nobody)
Summary: SystemError with conditional expression in assignment

Initial Comment:
When a conditional expression appears on the left
side of an assignment, SystemError is raised instead
of SyntaxError. Example:

Python 2.5a2 (trunk:45989M, May 13 2006, 15:40:42)
[MSC v.1310 32 bit (Intel)] on win32

>>> a if True else b = 3
SystemError: unexpected expression in assignment 5 (line 1)


----------------------------------------------------------------------

>Comment By: ?iga Seilnacht (zseil)
Date: 2006-05-13 22:50

Message:
Logged In: YES 
user_id=1326842

Attaching a patch. Most of the changes
in test_syntax are due to error renumbering.
All tests passed with this patch applied.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1487966&group_id=5470

From noreply at sourceforge.net  Sun May 14 19:42:50 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 14 May 2006 10:42:50 -0700
Subject: [ python-Feature Requests-1080727 ] Add encoding to DocFileSuite
Message-ID: <E1FfKcE-0003WY-PH@sc8-sf-web2.sourceforge.net>

Feature Requests item #1080727, was opened at 2004-12-08 01:47
Message generated for change (Comment added) made by quiver
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1080727&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: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Bjorn Tillenius (bjoti)
Assigned to: Jim Fulton (dcjim)
Summary: Add encoding to DocFileSuite

Initial Comment:
If one writes doctests within documentation strings of classes and 
functions, it's possible to use non-ASCII characters since one can 
specify the encoding used in the source file.

But if one wants to combine the documentation and testing, by 
writing a text file, and thus use DocFileSuite, it's not possible to use 
non-ASCII characters in the tests. This is because there's no way 
of specifying which encoding the text file uses. Instead one has to 
\-quote all non-ASCII characters, and that makes the tests harder 
to read IMHO.

----------------------------------------------------------------------

>Comment By: George Yoshida (quiver)
Date: 2006-05-15 02:42

Message:
Logged In: YES 
user_id=671362

Updated the patch for the trunk.
Documentation is also included.

If there is no objection, I'll commit it before 2.5 a3 
rolled out.

----------------------------------------------------------------------

Comment By: Jim Fulton (dcjim)
Date: 2005-11-15 07:50

Message:
Logged In: YES 
user_id=73023

The patch looks good to me.  I haven't looked at the tests,
but I assume that they are good too.  I will look at them. :)

I'm also going to add PEP 263-style encoding specification.

Thanks!

----------------------------------------------------------------------

Comment By: Bjorn Tillenius (bjoti)
Date: 2005-09-14 05:12

Message:
Logged In: YES 
user_id=1032069

Attaching new version of the patch that will apply cleanly against latest CVS

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2005-09-14 03:59

Message:
Logged In: YES 
user_id=31435

Ed, can you make time to review this patch?  If not, please 
unassign it again.

----------------------------------------------------------------------

Comment By: Bjorn Tillenius (bjoti)
Date: 2004-12-19 03:05

Message:
Logged In: YES 
user_id=1032069

Uploaded new patch, which adds the possibility to specify an encoding to 
testfile as well, since I assume this is desirable.

----------------------------------------------------------------------

Comment By: Bjorn Tillenius (bjoti)
Date: 2004-12-18 23:08

Message:
Logged In: YES 
user_id=1032069

Added patch for Tim to review.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-12-15 12:09

Message:
Logged In: YES 
user_id=31435

Unassigned myself -- can't make time to work on it.  I'll be 
happy to review a patch (code/tests/docs) if one appears.  I 
approve of the idea <wink>.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1080727&group_id=5470

From noreply at sourceforge.net  Mon May 15 04:06:24 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 14 May 2006 19:06:24 -0700
Subject: [ python-Bugs-1324799 ] Curses module doesn't install on Solaris 2.8
Message-ID: <E1FfSTY-000101-Ro@sc8-sf-web4-b.sourceforge.net>

Bugs item #1324799, was opened at 2005-10-12 07:21
Message generated for change (Comment added) made by enchanter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1324799&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: Andrew Koenig (arkoenig)
Assigned to: A.M. Kuchling (akuchling)
Summary: Curses module doesn't install on Solaris 2.8

Initial Comment:
During installation, the following happens:

building '_curses' extension
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -
fno-strict-aliasing -I. -I/tmp/build-gnu20746/Python-
2.4.2/./Include -I/usr/gnu/include -I/usr/local/include -
I/tmp/build-gnu20746/Python-2.4.2/Include -I/tmp/build-
gnu20746/Python-2.4.2 -c /tmp/build-gnu20746/Python-
2.4.2/Modules/_cursesmodule.c -o build/temp.solaris-2.8-
sun4u-2.4/_cursesmodule.o
/tmp/build-gnu20746/Python-
2.4.2/Modules/_cursesmodule.c: In 
function 'PyCursesWindow_GetStr':
/tmp/build-gnu20746/Python-
2.4.2/Modules/_cursesmodule.c:822: warning: implicit 
declaration of function 'mvwgetnstr'
gcc -shared build/temp.solaris-2.8-sun4u-
2.4/_cursesmodule.o -L/usr/gnu/lib -L/usr/local/lib -lcurses -
ltermcap -o build/lib.solaris-2.8-sun4u-2.4/_curses.so
*** WARNING: renaming "_curses" since importing it 
failed: ld.so.1: ./python: fatal: relocation error: file 
build/lib.solaris-2.8-sun4u-2.4/_curses.so: symbol 
mvwgetnstr: referenced symbol not found
building '_curses_panel' extension
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -
fno-strict-aliasing -I. -I/tmp/build-gnu20746/Python-
2.4.2/./Include -I/usr/gnu/include -I/usr/local/include -
I/tmp/build-gnu20746/Python-2.4.2/Include -I/tmp/build-
gnu20746/Python-2.4.2 -c /tmp/build-gnu20746/Python-
2.4.2/Modules/_curses_panel.c -o build/temp.solaris-2.8-
sun4u-2.4/_curses_panel.o
gcc -shared build/temp.solaris-2.8-sun4u-
2.4/_curses_panel.o -L/usr/gnu/lib -L/usr/local/lib -lpanel -
lcurses -ltermcap -o build/lib.solaris-2.8-sun4u-
2.4/_curses_panel.so
*** WARNING: renaming "_curses_panel" since importing 
it failed: No module named _curses

----------------------------------------------------------------------

Comment By: Tim Mooney (enchanter)
Date: 2006-05-14 21:06

Message:
Logged In: YES 
user_id=36222

First, your patch does fix the problem.

Next, Solaris 8+ *does* have mvwgetnwstr, the problem is
that it's in the X/Open version of the curses library, not
the (old, stinky, backwards-compatible) default version of
libcurses.

Solaris 10's man pages do a much better job of explaining
the differences, on 10 one can look at

  man -s 3xcurses libcurses

vs.

  man libcurses

If you want to compile and link against the X/Open version
of the curses library, you need to have

 -I/usr/xpg4/include

in CPPFLAGS and CFLAGS, and either

 -L/usr/xpg4/lib

or

 -L/usr/xpg4/lib/64

(depending on whether you're compiling for ILP32 or LP64).
/usr/xpg4/lib and /usr/xpg4/lib/64 are also not in the
default loader search path, so you either need to modify the
loader search path (man crle) or your also need a
-R/usr/xpg4/lib or -R/usr/xpg4/lib/64 in LDFLAGS too.

Because of the way the _cursesmodule is currently written,
though, it assumes that if __sun is defined as a
preprocessor symbol, STRICT_SYSV_CURSES should be defined,
which actually causes problems if you try build with with
newer X/Open curses.

It should be possible to support building against either
curses implementation on Solaris, but for now your patch at
least makes _cursesmodule compile with the default version.

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2005-11-22 08:45

Message:
Logged In: YES 
user_id=11375

One use of mvwgetnwstr in the module is replaced by a manual
emulation of the function, if STRICT_SYSV_CURSES is true,
but another use isn't replaced; I suspect this is the problem.

I've attached a patch that ensures that mvwgetnstr() is only
used when STRICT_SYSV_CURSES is undefined.  Please let me
know if this fixes the compilation problem.


----------------------------------------------------------------------

Comment By: Nelson Arzola (narzola)
Date: 2005-10-29 03:01

Message:
Logged In: YES 
user_id=39023

I would like to add that this problem also exists under
Solaris 2.10.  For some reason, mvwgetnstr is not defined
under Solaris 10.  When I use nm to get the symbols out of
/usr/lib/libcurses.so.1, I do not find it.

When I replace the two references in
/dsk/data0/build/Python-2.4.2/Modules/_cursesmodule.c from
mvwgetnstr to mvwgetnwstr, I was able to compile the module
and pass the appropriate tests.

Since I don't use curses, I really don't have a good way to
test this.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1324799&group_id=5470

From noreply at sourceforge.net  Mon May 15 04:20:47 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 14 May 2006 19:20:47 -0700
Subject: [ python-Bugs-1199282 ] subprocess _active.remove(self) self not in
	list _active
Message-ID: <200605150220.k4F2Kltm000999@sc8-sf-db2-new-b.sourceforge.net>

Bugs item #1199282, was opened at 05/10/05 11:24
Message generated for change (Comment added) made by sf-robot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1199282&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: cheops (atila-cheops)
Assigned to: Peter ?
strand (astrand)
Summary: subprocess _active.remove(self) self not in list _active

Initial Comment:
I start a subprocess in a seperate thread (25 concurrent 
threads)
in some of the threads the following error occurs
 
Exception in thread Thread-4:
Traceback (most recent call last):
  File "C:\Python24\lib\threading.py", line 442, in 
__bootstrap
    self.run()
  File "upgrade.py", line 45, in run
    returncode = p.wait()
  File "C:\Python24\lib\subprocess.py", line 765, in wait
    _active.remove(self)
ValueError: list.remove(x): x not in list
 
this is the code that starts the subprocess and where I 
wait for the result
 
p = subprocess.Popen('command', \
                             stdin=None, 
stdout=subprocess.PIPE, \
                             stderr=subprocess.STDOUT, 
universal_newlines=True)
returncode = p.wait()
errormessage = p.stdout.readlines()

----------------------------------------------------------------------

>Comment By: SourceForge Robot (sf-robot)
Date: 05/14/06 19:20

Message:
Logged In: YES 
user_id=1312539

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 04/30/06 12:52

Message:
Logged In: YES 
user_id=849994

The error causing "_active.remove(self)" call was removed
from wait() with patch 1467770, so I think this is fixed.

----------------------------------------------------------------------

Comment By: cheops (atila-cheops)
Date: 04/11/06 13:10

Message:
Logged In: YES 
user_id=1276121

there are 2 definitions of the function poll, one for 
windows and one for POSIX systems
in the windows version _deadlock is not used
in the POSIX version _deadlock is used

see also modification made by loewis in committed version 
45234

----------------------------------------------------------------------

Comment By: HVB bei TUP (hvb_tup)
Date: 04/11/06 00:21

Message:
Logged In: YES 
user_id=1434251

I looked at the patch #1467770 you mentioned and 
downloaded the patch.

Is it correct that _deadlock variable is used in the 
definition of poll but it is not in the argument list?


----------------------------------------------------------------------

Comment By: cheops (atila-cheops)
Date: 04/10/06 07:57

Message:
Logged In: YES 
user_id=1276121

see patch #1467770

----------------------------------------------------------------------

Comment By: Tristan Faujour (tfaujour)
Date: 03/29/06 05:50

Message:
Logged In: YES 
user_id=1488657

> Simply list operations such as remove() and append() are
> thread safe,

OK, my apologies... I did not know.

I did some more tests. On Linux, I found lots of:

  File "./subprocess.py", line 428, in call
    return Popen(*args, **kwargs).wait()
  File "./subprocess.py", line 1023, in wait
    pid, sts = os.waitpid(self.pid, 0)
OSError: [Errno 10] No child processes

The try...except solution does not handle this (since we are
in the "posix" section).

In my opinion, the call to _cleanup() in Popen.__init__() is
useless (it just checks if older processes have stopped when
a new one is started. I cannot see why it could be
mandatory) and it is the root of this bug.

I commented it out (line 506) and retried my tests on Linux
& Windows plateforms: I had no exception at all.



----------------------------------------------------------------------

Comment By: Peter ?
strand (astrand)
Date: 03/28/06 21:11

Message:
Logged In: YES 
user_id=344921

>I think accesses to _active should be serialized in a
>thread-safe way. _active could be a Queue (from the Queue
>module) for example

Simply list operations such as remove() and append() are
thread safe, so there should be no need for a Queue. Also, a
Queue cannot be used since the subprocess module needs to be
compatible with Python 2.2. 

----------------------------------------------------------------------

Comment By: Tristan Faujour (tfaujour)
Date: 03/28/06 15:17

Message:
Logged In: YES 
user_id=1488657

I am running into the same problem on a Windows 2k/XP
plateform with a multi-threaded application. It occurs randomly.

It has never appened (yet) on a Linux plateform.

I think accesses to _active should be serialized in a
thread-safe way. _active could be a Queue (from the Queue
module) for example.


----------------------------------------------------------------------

Comment By: HVB bei TUP (hvb_tup)
Date: 01/25/06 00:10

Message:
Logged In: YES 
user_id=1434251

Wouldn't it be best to completely remove any references 
to "_active" and "_cleanup"?

----------------------------------------------------------------------

Comment By: cheops (atila-cheops)
Date: 01/24/06 23:08

Message:
Logged In: YES 
user_id=1276121

As suggested by astrand
adding a try ... except clause in the file subprocess.py did
the job
I had to add that try ... except clause in 2 places
if you look in the file there are 2 instances were
list.remove(x) occurs unprotected.

try:
 list.remove(x)
except:
 pass

I have worked with 2.4.0, 2.4.1 and 2.4.2 and all three
needed the patch.
Hope this helps.

----------------------------------------------------------------------

Comment By: HVB bei TUP (hvb_tup)
Date: 01/23/06 08:34

Message:
Logged In: YES 
user_id=1434251

BTW: In my case, I call python.exe from a Windows service.

----------------------------------------------------------------------

Comment By: HVB bei TUP (hvb_tup)
Date: 01/23/06 08:30

Message:
Logged In: YES 
user_id=1434251

I have a similar problem.
Python 2.4.1 under MS Windows 2003,
Multi-Threaded application (about concurrent 10 threads).

In my case the same error occurs during _cleanup called 
from __init__ :

  
File "E:\lisa_ins\ewu\coop\reporting\python\tup_lisa\util\t
hreadutil.py", line 582, in callSubProcess
    creationflags = creationflags
  File "C:\Python24\lib\subprocess.py", line 506, in 
__init__
    _cleanup()
  File "C:\Python24\lib\subprocess.py", line 414, in 
_cleanup
    inst.poll()
  File "C:\Python24\lib\subprocess.py", line 755, in poll
    _active.remove(self)
ValueError: list.remove(x): x not in list

Is there a work-around?


----------------------------------------------------------------------

Comment By: cheops (atila-cheops)
Date: 09/19/05 02:29

Message:
Logged In: YES 
user_id=1276121

I noticed this bug under windows
to reproduce the bug, I attached the script I use, but this 
needs input, I tried with a simpler example (pinging a number 
of host concurrently) but that did not cause the bug.

----------------------------------------------------------------------

Comment By: Peter ?
strand (astrand)
Date: 06/23/05 09:03

Message:
Logged In: YES 
user_id=344921

I believe it should be sufficient to add a try...except
clause around _active.remove(). Can you upload a complete
example that triggers the bug? Have you noticed this bug on
Windows, UNIX or both platforms?


----------------------------------------------------------------------

Comment By: cheops (atila-cheops)
Date: 05/12/05 03:17

Message:
Logged In: YES 
user_id=1276121

this might be related to bug 1183780

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1199282&group_id=5470

From noreply at sourceforge.net  Mon May 15 08:23:51 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 14 May 2006 23:23:51 -0700
Subject: [ python-Bugs-1487105 ] 2.5 rev 45972 fails build on Mac-Intel
Message-ID: <E1FfWUh-0005yq-Vo@sc8-sf-web3.sourceforge.net>

Bugs item #1487105, was opened at 2006-05-11 22:51
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1487105&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: 7
Submitted By: Alex Martelli (aleax)
>Assigned to: Alex Martelli (aleax)
Summary: 2.5 rev 45972 fails build on Mac-Intel

Initial Comment:
brain:~/py25 alex$ make
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes   Parser/acceler.o 
Parser/grammar1.o Parser/listnode.o Parser/node.o Parser/parser.o 
Parser/parsetok.o Parser/bitset.o Parser/metagrammar.o Parser/
firstsets.o Parser/grammar.o Parser/pgen.o Objects/obmalloc.o Python/
mysnprintf.o Parser/tokenizer_pgen.o Parser/printgrammar.o Parser/
pgenmain.o -ldl  -o Parser/pgen
/usr/bin/ld: warning Parser/printgrammar.o cputype (18, architecture 
ppc) does not match cputype (7) for specified -arch flag: i386 (file not 
loaded)
/usr/bin/ld: Undefined symbols:
__Py_printgrammar
__Py_printnonterminals
collect2: ld returned 1 exit status
make: *** [Parser/pgen] Error 1
brain:~/py25 alex$ 

This is a MacBook Pro with gcc version 4.0.1 (Apple Computer, Inc. build 
5250) -- not sure why there's an "architecture ppc" found somewhere, 
haven't looked at it in detail yet, but at any rate this breaks the make.


Alex


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-05-14 23:23

Message:
Logged In: YES 
user_id=33168

Alex, can you try with a current checkout?  It looks like
Ronald checked in fixes for x86 at 45997.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1487105&group_id=5470

From noreply at sourceforge.net  Mon May 15 08:25:06 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 14 May 2006 23:25:06 -0700
Subject: [ python-Bugs-1486897 ] OS X framework build for python 2.5 fails,
	configure is odd
Message-ID: <E1FfWVu-0004v3-CU@sc8-sf-web1.sourceforge.net>

Bugs item #1486897, was opened at 2006-05-11 14:44
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1486897&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: Christopher Knox (vizowl)
Assigned to: Nobody/Anonymous (nobody)
Summary: OS X framework build for python 2.5 fails, configure is odd

Initial Comment:
The OS X framework build for python 2.5 does not install a dynamic 
library at /Library/Frameworks/Python.framework/Versions/2.5/Python 
where it should. The python2.5 executible does not run because it is 
trying to load this dynamic library.

This is on an intel mac with darwin-8.6.1 and gcc4 and python2.5a2.

Also all of the extra modules (_CG extension, IDLE extra) fail to link 
because their link command is -lpython2.5 which is not what it should be 
for a framework build and even if it was correct for linking agianst a 
framework it would fil because the framework doesn't have its library 
anyway.

Finally, the configure script behaves oddly in that it works fine, but if you 
change the parameters and rerun it it will fail unless you run 'make 
distclean'

This is where it fails.

checking whether mmap with MAP_ANON(YMOUS) works... yes
configure: error: "libffi has not been ported to i686-apple-darwin8.6.1."
Failed to configure _ctypes module

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-05-14 23:25

Message:
Logged In: YES 
user_id=33168

Christopher can you try with a current checkout?  Ronald
checked in lots of changes which I think include x86 support
at svn rev 45997.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1486897&group_id=5470

From noreply at sourceforge.net  Mon May 15 08:25:22 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 14 May 2006 23:25:22 -0700
Subject: [ python-Bugs-1488634 ] tarfile.TarFile.open can might incorrectly
	raise ValueError
Message-ID: <E1FfWWA-00050z-FF@sc8-sf-web1.sourceforge.net>

Bugs item #1488634, was opened at 2006-05-15 16:25
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=1488634&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: Andrew Bennetts (spiv)
Assigned to: Nobody/Anonymous (nobody)
Summary: tarfile.TarFile.open can might incorrectly raise ValueError

Initial Comment:
tarfile.TarFile.open, if passed a fileobj argument for
a valid plain tar or tar.gz file, might fail to open
the file, and instead unexpectedly raise "ValueError:
no support for external file objects".

"open" iterates over TarFile.OPEN_METH, which is a
dictionary, to try find a method that works for a given
file.  If the internal, undefined, ordering of that
dict returns the "bz2" key before the right one for a
given file, and the fileobj argument is passed, TarFile
will attempt to call bz2open with the fileobj method,
which then raises "ValueError: no support for external
file objects", which then is not caught.

The end result is that it's possible to pass a valid
tar or tar.gz file to TarFile.open in the fileobj
argument, but get a ValueError from bz2open instead of
a TarFile object.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1488634&group_id=5470

From noreply at sourceforge.net  Mon May 15 09:04:58 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 15 May 2006 00:04:58 -0700
Subject: [ python-Bugs-1487966 ] SystemError with conditional expression in
	assignment
Message-ID: <E1FfX8U-0005CT-Qw@sc8-sf-web1.sourceforge.net>

Bugs item #1487966, was opened at 2006-05-13 09:25
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1487966&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: Python 2.5
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: ?iga Seilnacht (zseil)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: SystemError with conditional expression in assignment

Initial Comment:
When a conditional expression appears on the left
side of an assignment, SystemError is raised instead
of SyntaxError. Example:

Python 2.5a2 (trunk:45989M, May 13 2006, 15:40:42)
[MSC v.1310 32 bit (Intel)] on win32

>>> a if True else b = 3
SystemError: unexpected expression in assignment 5 (line 1)


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-05-15 00:04

Message:
Logged In: YES 
user_id=33168

Thanks for the patch!  

Committed revision 46000.


----------------------------------------------------------------------

Comment By: ?iga Seilnacht (zseil)
Date: 2006-05-13 13:50

Message:
Logged In: YES 
user_id=1326842

Attaching a patch. Most of the changes
in test_syntax are due to error renumbering.
All tests passed with this patch applied.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1487966&group_id=5470

From noreply at sourceforge.net  Mon May 15 10:26:39 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 15 May 2006 01:26:39 -0700
Subject: [ python-Bugs-1483133 ] gen_iternext: Assertion `f->f_back != ((void
	*)0)' failed
Message-ID: <E1FfYPX-00005V-1y@sc8-sf-web3.sourceforge.net>

Bugs item #1483133, was opened at 2006-05-07 00:09
Message generated for change (Comment added) made by svensoho
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1483133&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: 6
Submitted By: svensoho (svensoho)
Assigned to: Nobody/Anonymous (nobody)
>Summary: gen_iternext: Assertion `f->f_back != ((void *)0)' failed

Initial Comment:
Seems to be similar bug as http://sourceforge.net/
tracker/index.php?
func=detail&aid=1257960&group_id=5470&atid=105470 
(fixed)

Couldn't trigger with same script but with C 
application. Same source modification helps (at 
Objects/genobject.c:53)

----------------------------------------------------------------------

>Comment By: svensoho (svensoho)
Date: 2006-05-15 11:26

Message:
Logged In: YES 
user_id=1518209




----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1483133&group_id=5470

From noreply at sourceforge.net  Mon May 15 11:08:07 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 15 May 2006 02:08:07 -0700
Subject: [ python-Bugs-1488717 ] appended file on Windows reads arbitrary data
Message-ID: <E1FfZ3f-0006XF-AG@sc8-sf-web3.sourceforge.net>

Bugs item #1488717, was opened at 2006-05-15 18: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=1488717&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: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: muimi (muimi)
Assigned to: Nobody/Anonymous (nobody)
Summary: appended file on Windows reads arbitrary data

Initial Comment:
checked with versions 2.3 & 2.4.2 on Windows 2000 & XP

reading an appended file without resetting its
current position causes reading/writing of arbitrary data.
this appears to be related to the MS Visual Studio C
library.

def bug(filename):
    af=open(filename,'a+')
    af.write('\nlast line?')
    print af.tell()
    d=af.read() # this causes a read/write problem
    print len(d), af.tell()
    af.close()

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1488717&group_id=5470

From noreply at sourceforge.net  Mon May 15 13:09:35 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 15 May 2006 04:09:35 -0700
Subject: [ python-Bugs-1488779 ] appended file on Windows reads arbitrary data
Message-ID: <E1FfaxD-0005Qm-76@sc8-sf-web4-b.sourceforge.net>

Bugs item #1488779, was opened at 2006-05-15 20:09
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=1488779&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: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: muimi (muimi)
Assigned to: Nobody/Anonymous (nobody)
Summary: appended file on Windows reads arbitrary data

Initial Comment:
checked with versions 2.3 & 2.4.2 on Windows 2000 & XP

reading an appended file without resetting its
current position causes reading/writing of arbitrary data.
this appears to be related to the MS Visual Studio C
library.

def bug(filename):
    af=open(filename,'a+')
    af.write('\nlast line?')
    print af.tell()
    d=af.read() # this causes a read/write problem
    print len(d), af.tell()
    af.close()

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1488779&group_id=5470

From noreply at sourceforge.net  Mon May 15 16:20:02 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 15 May 2006 07:20:02 -0700
Subject: [ python-Bugs-1488634 ] tarfile.TarFile.open can might incorrectly
	raise ValueError
Message-ID: <E1FfdvW-00034Q-9W@sc8-sf-web2.sourceforge.net>

Bugs item #1488634, was opened at 2006-05-15 08:25
Message generated for change (Comment added) made by gustaebel
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1488634&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: Andrew Bennetts (spiv)
Assigned to: Nobody/Anonymous (nobody)
Summary: tarfile.TarFile.open can might incorrectly raise ValueError

Initial Comment:
tarfile.TarFile.open, if passed a fileobj argument for
a valid plain tar or tar.gz file, might fail to open
the file, and instead unexpectedly raise "ValueError:
no support for external file objects".

"open" iterates over TarFile.OPEN_METH, which is a
dictionary, to try find a method that works for a given
file.  If the internal, undefined, ordering of that
dict returns the "bz2" key before the right one for a
given file, and the fileobj argument is passed, TarFile
will attempt to call bz2open with the fileobj method,
which then raises "ValueError: no support for external
file objects", which then is not caught.

The end result is that it's possible to pass a valid
tar or tar.gz file to TarFile.open in the fileobj
argument, but get a ValueError from bz2open instead of
a TarFile object.


----------------------------------------------------------------------

Comment By: Lars Gust?bel (gustaebel)
Date: 2006-05-15 16:19

Message:
Logged In: YES 
user_id=642936

I just submitted patch #1488881 that would solve your
problem as a side-effect. Thanks for your report.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1488634&group_id=5470

From noreply at sourceforge.net  Mon May 15 17:06:21 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 15 May 2006 08:06:21 -0700
Subject: [ python-Bugs-1488906 ] endless loop in PyCFunction_Fini()
Message-ID: <E1Ffedm-0005LO-J1@sc8-sf-web4-b.sourceforge.net>

Bugs item #1488906, was opened at 2006-05-15 17: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=1488906&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: Matejcik (spektrum)
Assigned to: Nobody/Anonymous (nobody)
Summary: endless loop in PyCFunction_Fini()

Initial Comment:
see https://bugzilla.novell.com/show_bug.cgi?id=171066

Basically, under some circumstances not yet determined,
PyCFunction_Fini() goes into an endless loop over a
cyclic linked list.

void
PyCFunction_Fini(void)
{
    while (free_list) {
        PyCFunctionObject *v = free_list;
        free_list = (PyCFunctionObject *)(v->m_self);
        PyObject_GC_Del(v);
    }
}

it looks like it's sufficient to do
v->m_self = NULL;
or something.
However, for one, i'm not sure if this wouldn't break
something, and for two, free_list should never be
cyclic, right?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1488906&group_id=5470

From noreply at sourceforge.net  Mon May 15 17:26:28 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 15 May 2006 08:26:28 -0700
Subject: [ python-Bugs-1488915 ] Multiple dots in relative import statement
	raise SyntaxError
Message-ID: <E1Ffexo-0000A3-Sh@sc8-sf-web2.sourceforge.net>

Bugs item #1488915, was opened at 2006-05-15 17:26
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=1488915&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: ?iga Seilnacht (zseil)
Assigned to: Nobody/Anonymous (nobody)
Summary: Multiple dots in relative import statement raise SyntaxError

Initial Comment:
When a relative import statement contains more than
one period and no module name, SyntaxError is raised.
Example:

from  .  import  spam       # this works
from  ..spam  import  eggs  # this works
from  ..  import  eggs      # this raises SyntaxError

The problem is in the following line in Grammar/Grammar:

import_from: ('from' ('.'* dotted_name | '.')

According to Guido's mail:
http://mail.python.org/pipermail/python-dev/2003-December/041065.html
that line should be:

import_from: ('from' ('.'* dotted_name | '.'+)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1488915&group_id=5470

From noreply at sourceforge.net  Mon May 15 18:10:09 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 15 May 2006 09:10:09 -0700
Subject: [ python-Bugs-1488934 ] file.write + closed pipe = no error
Message-ID: <E1Fffe5-00077R-Eb@sc8-sf-web3.sourceforge.net>

Bugs item #1488934, was opened at 2006-05-15 12:10
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=1488934&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: Erik Demaine (edemaine)
Assigned to: Nobody/Anonymous (nobody)
Summary: file.write + closed pipe = no error

Initial Comment:
I am writing a Python script on Linux that gets called
via ssh (ssh hostname script.py) and I would like it to
know when its stdout gets closed because the ssh
connection gets killed.  I assumed that it would
suffice to write to stdout, and that I would get an
error if stdout was no longer connected to anything. 
This is not the case, however.  I believe it is because
of incorrect error checking in Objects/fileobject.c's
file_write.

Consider this example:

while True:
__print 'Hello'
__time.sleep (1)

If this program is run via ssh and then the ssh
connection dies, the program continues running forever
(or at least, over 10 hours).  No exceptions are thrown.

In contrast, this example does die as soon as the ssh
connection dies (within one second):

while True:
__os.write (1, 'Hello')
__time.sleep (1)

I claim that this is because os.write does proper error
checking, but file.write seems not to.  I was surprised
to find this intricacy in fwrite().  Consider the
attached C program, test.c.  (Warning: If you run it,
it will create a file /tmp/hello, and it will keep
running until you kill it.)  While the ssh connection
remains open, fwrite() reports a length of 6 bytes
written, ferror() reports no error, and errno remains
0.  Once the ssh connection dies, fwrite() still
reports a length of 6 bytes written (surprise!), but
ferror(stdout) reports an error, and errno changes to 5
(EIO).  So apparently one cannot tell from the return
value of fwrite() alone whether the write actually
succeeded; it seems necessary to call ferror() to
determine whether the write caused an error.

I think the only change necessary is on line 2443 of
file_write() in Objects/fileobject.c (in svn version
46003):

2441        n2 = fwrite(s, 1, n, f->f_fp);
2442        Py_END_ALLOW_THREADS
2443        if (n2 != n) {
2444                PyErr_SetFromErrno(PyExc_IOError);
2445                clearerr(f->f_fp);

I am not totally sure whether the "n2 != n" condition
should be changed to "n2 != n || ferror (f->f_fp)" or
simply "ferror (f->f_fp)", but I believe that the
condition should be changed to one of these
possibilities.  The current behavior is wrong.

Incidentally, you'll notice that the C code has to turn
off signal SIGPIPE (like Python does) in order to not
die right away.  However, I could not get Python to die
by re-enabling SIGPIPE.  I tried "signal.signal
(signal.SIGPIPE, signal.SIG_DFL)" and "signal.signal
(signal.SIGPIPE, lambda x, y: sys.exit ())" and neither
one caused death of the script when the ssh connection
died.  Perhaps I'm not using the signal module correctly?

I am on Linux 2.6.11 on a two-CPU Intel Pentium 4, and
I am running the latest Subversion version of Python,
but my guess is that this error transcends most if not
all versions of Python.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1488934&group_id=5470

From noreply at sourceforge.net  Mon May 15 18:26:30 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 15 May 2006 09:26:30 -0700
Subject: [ python-Bugs-1488934 ] file.write + closed pipe = no error
Message-ID: <E1Ffftu-0002Y5-5N@sc8-sf-web2.sourceforge.net>

Bugs item #1488934, was opened at 2006-05-15 12:10
Message generated for change (Comment added) made by edemaine
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1488934&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: Erik Demaine (edemaine)
Assigned to: Nobody/Anonymous (nobody)
Summary: file.write + closed pipe = no error

Initial Comment:
I am writing a Python script on Linux that gets called
via ssh (ssh hostname script.py) and I would like it to
know when its stdout gets closed because the ssh
connection gets killed.  I assumed that it would
suffice to write to stdout, and that I would get an
error if stdout was no longer connected to anything. 
This is not the case, however.  I believe it is because
of incorrect error checking in Objects/fileobject.c's
file_write.

Consider this example:

while True:
__print 'Hello'
__time.sleep (1)

If this program is run via ssh and then the ssh
connection dies, the program continues running forever
(or at least, over 10 hours).  No exceptions are thrown.

In contrast, this example does die as soon as the ssh
connection dies (within one second):

while True:
__os.write (1, 'Hello')
__time.sleep (1)

I claim that this is because os.write does proper error
checking, but file.write seems not to.  I was surprised
to find this intricacy in fwrite().  Consider the
attached C program, test.c.  (Warning: If you run it,
it will create a file /tmp/hello, and it will keep
running until you kill it.)  While the ssh connection
remains open, fwrite() reports a length of 6 bytes
written, ferror() reports no error, and errno remains
0.  Once the ssh connection dies, fwrite() still
reports a length of 6 bytes written (surprise!), but
ferror(stdout) reports an error, and errno changes to 5
(EIO).  So apparently one cannot tell from the return
value of fwrite() alone whether the write actually
succeeded; it seems necessary to call ferror() to
determine whether the write caused an error.

I think the only change necessary is on line 2443 of
file_write() in Objects/fileobject.c (in svn version
46003):

2441        n2 = fwrite(s, 1, n, f->f_fp);
2442        Py_END_ALLOW_THREADS
2443        if (n2 != n) {
2444                PyErr_SetFromErrno(PyExc_IOError);
2445                clearerr(f->f_fp);

I am not totally sure whether the "n2 != n" condition
should be changed to "n2 != n || ferror (f->f_fp)" or
simply "ferror (f->f_fp)", but I believe that the
condition should be changed to one of these
possibilities.  The current behavior is wrong.

Incidentally, you'll notice that the C code has to turn
off signal SIGPIPE (like Python does) in order to not
die right away.  However, I could not get Python to die
by re-enabling SIGPIPE.  I tried "signal.signal
(signal.SIGPIPE, signal.SIG_DFL)" and "signal.signal
(signal.SIGPIPE, lambda x, y: sys.exit ())" and neither
one caused death of the script when the ssh connection
died.  Perhaps I'm not using the signal module correctly?

I am on Linux 2.6.11 on a two-CPU Intel Pentium 4, and
I am running the latest Subversion version of Python,
but my guess is that this error transcends most if not
all versions of Python.

----------------------------------------------------------------------

>Comment By: Erik Demaine (edemaine)
Date: 2006-05-15 12:26

Message:
Logged In: YES 
user_id=265183

One more thing: fwrite() is used in a couple of other
places, and I think the same comment applies to them.  They are:

- file_writelines() in Objects/fileobject.c
- w_string() in Python/marshal.c doesn't seem to have any
error checking?  (At least no ferror() call in marhsal.c...)
- string_print() in Objects/stringobject.c doesn't seem to
have any error checking (but I'm not quite sure what this
means in Python land).
- flush_data() in Modules/_hotshot.c
- array_tofile() in Modules/arraymodule.c
- write_file() in Modules/cPickle.c
- putshort(), putlong(), writeheader(), writetab() [and the
functions that call them] in Modules/rgbimgmodule.c
- svc_writefile() in Modules/svmodule.c

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1488934&group_id=5470

From noreply at sourceforge.net  Mon May 15 18:27:38 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 15 May 2006 09:27:38 -0700
Subject: [ python-Bugs-1488943 ] difflib.Differ() doesn't always add hints for
	tab characters
Message-ID: <E1Fffv0-00030j-Ld@sc8-sf-web2.sourceforge.net>

Bugs item #1488943, was opened at 2006-05-16 00:27
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=1488943&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: Henry (henryl)
Assigned to: Nobody/Anonymous (nobody)
Summary: difflib.Differ() doesn't always add hints for tab characters

Initial Comment:
The difflib.Differ() object doesn't always add a hint
for added tab characters.

eg:
import difflib
differ = difflib.Differ()
for change in differ.compare(["\tI am a buggy"],
["\t\tI am a bug"]):
	print repr(change)

Should return

'- \tI am a buggy'
'? \t          --\n'
'+ \t\tI am a bug'
'? +\n'

but actually returns (no hint for the added tab)

'- \tI am a buggy'
'? \t          --\n'
'+ \t\tI am a bug'

sys.version reports
2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit
(Intel)]

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1488943&group_id=5470

From noreply at sourceforge.net  Mon May 15 18:58:26 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 15 May 2006 09:58:26 -0700
Subject: [ python-Bugs-1488717 ] appended file on Windows reads arbitrary data
Message-ID: <E1FfgOo-0005fY-N9@sc8-sf-web4-b.sourceforge.net>

Bugs item #1488717, was opened at 2006-05-15 05:08
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1488717&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: Not a Bug
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: muimi (muimi)
Assigned to: Nobody/Anonymous (nobody)
Summary: appended file on Windows reads arbitrary data

Initial Comment:
checked with versions 2.3 & 2.4.2 on Windows 2000 & XP

reading an appended file without resetting its
current position causes reading/writing of arbitrary data.
this appears to be related to the MS Visual Studio C
library.

def bug(filename):
    af=open(filename,'a+')
    af.write('\nlast line?')
    print af.tell()
    d=af.read() # this causes a read/write problem
    print len(d), af.tell()
    af.close()

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2006-05-15 12:58

Message:
Logged In: YES 
user_id=31435

Yes, and this is inherited from the platform C library,
which conforms to the C standard in this respect:  all
behavior is undefined if you read after write, or write
after read, without a file-positioning operation (typically
a seek) between them.  So don't do that.  Closing as not-a-bug.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1488717&group_id=5470

From noreply at sourceforge.net  Mon May 15 19:13:13 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 15 May 2006 10:13:13 -0700
Subject: [ python-Bugs-1486897 ] OS X framework build for python 2.5 fails,
	configure is odd
Message-ID: <E1Ffgd7-0006FP-5M@sc8-sf-web3.sourceforge.net>

Bugs item #1486897, was opened at 2006-05-11 14:44
Message generated for change (Comment added) made by vizowl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1486897&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: Christopher Knox (vizowl)
Assigned to: Nobody/Anonymous (nobody)
Summary: OS X framework build for python 2.5 fails, configure is odd

Initial Comment:
The OS X framework build for python 2.5 does not install a dynamic 
library at /Library/Frameworks/Python.framework/Versions/2.5/Python 
where it should. The python2.5 executible does not run because it is 
trying to load this dynamic library.

This is on an intel mac with darwin-8.6.1 and gcc4 and python2.5a2.

Also all of the extra modules (_CG extension, IDLE extra) fail to link 
because their link command is -lpython2.5 which is not what it should be 
for a framework build and even if it was correct for linking agianst a 
framework it would fil because the framework doesn't have its library 
anyway.

Finally, the configure script behaves oddly in that it works fine, but if you 
change the parameters and rerun it it will fail unless you run 'make 
distclean'

This is where it fails.

checking whether mmap with MAP_ANON(YMOUS) works... yes
configure: error: "libffi has not been ported to i686-apple-darwin8.6.1."
Failed to configure _ctypes module

----------------------------------------------------------------------

>Comment By: Christopher Knox (vizowl)
Date: 2006-05-15 10:13

Message:
Logged In: YES 
user_id=1346203

Hi Neal,

I checked out rev 46003 (the HEAD at the time) in a clean directory and used: 

./configure --enable-profiling --enable-shared --enable-framework --
enable-universalsdk

Unfortunately it failed in the same way it has the same problems in that it is 
linking with the flag -lpython2.5 when it should be a framework linking. I 
have attached the build log from after having built it once so you only see the 
linking.

However, it does appear that the issue raised in bug # 1487105 is solved. It 
compiled fine on an intel mac it just has linking problems.

Also I get exactly the same problem on a G5

Chris

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-05-14 23:25

Message:
Logged In: YES 
user_id=33168

Christopher can you try with a current checkout?  Ronald
checked in lots of changes which I think include x86 support
at svn rev 45997.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1486897&group_id=5470

From noreply at sourceforge.net  Mon May 15 20:46:50 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 15 May 2006 11:46:50 -0700
Subject: [ python-Bugs-1489051 ] keyword and topic help broken in Pythonwin IDE
Message-ID: <E1Ffi5i-0007QG-Fk@sc8-sf-web4-b.sourceforge.net>

Bugs item #1489051, was opened at 2006-05-15 18:46
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=1489051&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: BartlebyScrivener (bscrivener)
Assigned to: Nobody/Anonymous (nobody)
Summary: keyword and topic help broken in Pythonwin IDE

Initial Comment:
Using ActivePython 2.4.3 on Windows XP

While in the Pythonwin IDE, if I seek keyword help by
issuing the following command:

>>>help ('while')

I get:

Sorry, topic and keyword documentation is not available
because the Python HTML documentation files could not
be found.  If you have installed them, please set the
environment variable PYTHONDOCS to
indicate their location.

My PYTHONDOCS variable is set to:

c:\python24\Doc\Python-Docs-2.4.2\ref

which appears to be correct (ie the help html files are
installed
there).

Searching this group, I found someone else complaining
about the same behavior with no clear resolution.

http://tinyurl.com/pblev

See also

http://tinyurl.com/mbokp

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1489051&group_id=5470

From noreply at sourceforge.net  Mon May 15 21:26:28 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 15 May 2006 12:26:28 -0700
Subject: [ python-Bugs-1488779 ] appended file on Windows reads arbitrary data
Message-ID: <E1Ffii4-0001MG-3C@sc8-sf-web1.sourceforge.net>

Bugs item #1488779, was opened at 2006-05-15 11:09
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1488779&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: Platform-specific
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: muimi (muimi)
Assigned to: Nobody/Anonymous (nobody)
Summary: appended file on Windows reads arbitrary data

Initial Comment:
checked with versions 2.3 & 2.4.2 on Windows 2000 & XP

reading an appended file without resetting its
current position causes reading/writing of arbitrary data.
this appears to be related to the MS Visual Studio C
library.

def bug(filename):
    af=open(filename,'a+')
    af.write('\nlast line?')
    print af.tell()
    d=af.read() # this causes a read/write problem
    print len(d), af.tell()
    af.close()

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-05-15 19:26

Message:
Logged In: YES 
user_id=849994

Dupe of #1488717.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1488779&group_id=5470

From noreply at sourceforge.net  Mon May 15 21:31:47 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 15 May 2006 12:31:47 -0700
Subject: [ python-Bugs-1488634 ] tarfile.TarFile.open can might incorrectly
	raise ValueError
Message-ID: <E1FfinD-00032t-SV@sc8-sf-web1.sourceforge.net>

Bugs item #1488634, was opened at 2006-05-15 06:25
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1488634&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: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Andrew Bennetts (spiv)
Assigned to: Nobody/Anonymous (nobody)
Summary: tarfile.TarFile.open can might incorrectly raise ValueError

Initial Comment:
tarfile.TarFile.open, if passed a fileobj argument for
a valid plain tar or tar.gz file, might fail to open
the file, and instead unexpectedly raise "ValueError:
no support for external file objects".

"open" iterates over TarFile.OPEN_METH, which is a
dictionary, to try find a method that works for a given
file.  If the internal, undefined, ordering of that
dict returns the "bz2" key before the right one for a
given file, and the fileobj argument is passed, TarFile
will attempt to call bz2open with the fileobj method,
which then raises "ValueError: no support for external
file objects", which then is not caught.

The end result is that it's possible to pass a valid
tar or tar.gz file to TarFile.open in the fileobj
argument, but get a ValueError from bz2open instead of
a TarFile object.


----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-05-15 19:31

Message:
Logged In: YES 
user_id=849994

Fixed with commit of said patch.

----------------------------------------------------------------------

Comment By: Lars Gust?bel (gustaebel)
Date: 2006-05-15 14:19

Message:
Logged In: YES 
user_id=642936

I just submitted patch #1488881 that would solve your
problem as a side-effect. Thanks for your report.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1488634&group_id=5470

From noreply at sourceforge.net  Tue May 16 03:52:18 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 15 May 2006 18:52:18 -0700
Subject: [ python-Bugs-1489246 ] 2.4.3 fails to find Tcl/Tk on Solaris 10
	x86_64 
Message-ID: <E1FfojS-0006I8-S7@sc8-sf-web3.sourceforge.net>

Bugs item #1489246, was opened at 2006-05-15 20:52
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=1489246&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.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Mooney (enchanter)
Assigned to: Nobody/Anonymous (nobody)
Summary: 2.4.3 fails to find Tcl/Tk on Solaris 10 x86_64 

Initial Comment:
First, I'm a complete python newbie, but I have lots of
experience with other languages and I'm very
experienced at building software on UNIX platforms.

I've built 64 bit (LP64) versions of Tcl 8.4.13 and Tk
8.4.13 with the Sun Studio 11 compiler.  They're
installed under /local, with the libraries in
/local/lib/64 , since the Solaris convention is to use
lib/64 for ELF64 libraries.

I can configure and compile Python 2.4.3 as an LP64
executable, but setup.py fails to find Tcl/Tk.  I'm
suspicious (but not certain) that the problem is that
the calls to self.compiler.find_library_file in
setup.py aren't finding any of the locally installed
libraries because find_library_file isn't searching the
"64" subdirectory under lib.

I've been through the README, and looked at the URL for
the FAQ mentioned in the README (though I don't see a
"section 3" of the FAQ).  Most of the suggestions in
the README in the Solaris section are geared toward
what to do when python can't find your shared libraries
*at run time*.  That's not the problem here.  I have my
loader set up (via crle with the -64 option) to search
all of the necessary locally-installed directories that
contain ELF64 libraries.  The problem is that Python's
setup can't find the libraries in the first place.

Suggestions?  If I already knew Python, I could
probably figure out how to subclass "compiler" to
always search the "/64" version of a library directory
when I'm on Solaris and the compiler flags contain a
certain set of characters (better yet would be to
actually compile something to an object file and test
whether it's ELF64).  Unfortunately, I'm not at that
level yet.

This instance is specific to Solaris, but the general
problem applies to other multi-ABI platforms too, like
IRIX, HP-UX, etc.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1489246&group_id=5470

From noreply at sourceforge.net  Tue May 16 09:14:07 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 16 May 2006 00:14:07 -0700
Subject: [ python-Bugs-1483133 ] gen_iternext: Assertion `f->f_back != ((void
	*)0)' failed
Message-ID: <E1Fftks-00027s-JE@sc8-sf-web1.sourceforge.net>

Bugs item #1483133, was opened at 2006-05-06 21:09
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1483133&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: 6
Submitted By: svensoho (svensoho)
>Assigned to: Phillip J. Eby (pje)
Summary: gen_iternext: Assertion `f->f_back != ((void *)0)' failed

Initial Comment:
Seems to be similar bug as http://sourceforge.net/
tracker/index.php?
func=detail&aid=1257960&group_id=5470&atid=105470 
(fixed)

Couldn't trigger with same script but with C 
application. Same source modification helps (at 
Objects/genobject.c:53)

----------------------------------------------------------------------

Comment By: svensoho (svensoho)
Date: 2006-05-15 08:26

Message:
Logged In: YES 
user_id=1518209




----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1483133&group_id=5470

From noreply at sourceforge.net  Tue May 16 09:24:52 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 16 May 2006 00:24:52 -0700
Subject: [ python-Bugs-1488915 ] Multiple dots in relative import statement
	raise SyntaxError
Message-ID: <E1FftvI-0001ro-OC@sc8-sf-web3.sourceforge.net>

Bugs item #1488915, was opened at 2006-05-15 15:26
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1488915&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: ?iga Seilnacht (zseil)
>Assigned to: Thomas Wouters (twouters)
Summary: Multiple dots in relative import statement raise SyntaxError

Initial Comment:
When a relative import statement contains more than
one period and no module name, SyntaxError is raised.
Example:

from  .  import  spam       # this works
from  ..spam  import  eggs  # this works
from  ..  import  eggs      # this raises SyntaxError

The problem is in the following line in Grammar/Grammar:

import_from: ('from' ('.'* dotted_name | '.')

According to Guido's mail:
http://mail.python.org/pipermail/python-dev/2003-December/041065.html
that line should be:

import_from: ('from' ('.'* dotted_name | '.'+)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1488915&group_id=5470

From noreply at sourceforge.net  Tue May 16 09:25:17 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 16 May 2006 00:25:17 -0700
Subject: [ python-Bugs-1488915 ] Multiple dots in relative import statement
	raise SyntaxError
Message-ID: <E1Fftvh-00021h-60@sc8-sf-web3.sourceforge.net>

Bugs item #1488915, was opened at 2006-05-15 15:26
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1488915&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: ?iga Seilnacht (zseil)
Assigned to: Thomas Wouters (twouters)
Summary: Multiple dots in relative import statement raise SyntaxError

Initial Comment:
When a relative import statement contains more than
one period and no module name, SyntaxError is raised.
Example:

from  .  import  spam       # this works
from  ..spam  import  eggs  # this works
from  ..  import  eggs      # this raises SyntaxError

The problem is in the following line in Grammar/Grammar:

import_from: ('from' ('.'* dotted_name | '.')

According to Guido's mail:
http://mail.python.org/pipermail/python-dev/2003-December/041065.html
that line should be:

import_from: ('from' ('.'* dotted_name | '.'+)

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-05-16 07:25

Message:
Logged In: YES 
user_id=849994

Assigned to Thomas. It doesn't seem as simple as adding the
"+" in Grammar.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1488915&group_id=5470

From noreply at sourceforge.net  Tue May 16 15:18:06 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 16 May 2006 06:18:06 -0700
Subject: [ python-Bugs-1488943 ] difflib.Differ() doesn't always add hints for
	tab characters
Message-ID: <E1FfzR8-0002Jy-N3@sc8-sf-web4-b.sourceforge.net>

Bugs item #1488943, was opened at 2006-05-16 00:27
Message generated for change (Comment added) made by henryl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1488943&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: Henry (henryl)
Assigned to: Nobody/Anonymous (nobody)
Summary: difflib.Differ() doesn't always add hints for tab characters

Initial Comment:
The difflib.Differ() object doesn't always add a hint
for added tab characters.

eg:
import difflib
differ = difflib.Differ()
for change in differ.compare(["\tI am a buggy"],
["\t\tI am a bug"]):
	print repr(change)

Should return

'- \tI am a buggy'
'? \t          --\n'
'+ \t\tI am a bug'
'? +\n'

but actually returns (no hint for the added tab)

'- \tI am a buggy'
'? \t          --\n'
'+ \t\tI am a bug'

sys.version reports
2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit
(Intel)]

----------------------------------------------------------------------

>Comment By: Henry (henryl)
Date: 2006-05-16 21:18

Message:
Logged In: YES 
user_id=1083163

Patch to lib/test/test_difflib.py attached.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1488943&group_id=5470

From noreply at sourceforge.net  Tue May 16 15:19:40 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 16 May 2006 06:19:40 -0700
Subject: [ python-Bugs-1488943 ] difflib.Differ() doesn't always add hints for
	tab characters
Message-ID: <E1FfzSe-0007nf-RL@sc8-sf-web3.sourceforge.net>

Bugs item #1488943, was opened at 2006-05-16 00:27
Message generated for change (Comment added) made by henryl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1488943&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: Henry (henryl)
Assigned to: Nobody/Anonymous (nobody)
Summary: difflib.Differ() doesn't always add hints for tab characters

Initial Comment:
The difflib.Differ() object doesn't always add a hint
for added tab characters.

eg:
import difflib
differ = difflib.Differ()
for change in differ.compare(["\tI am a buggy"],
["\t\tI am a bug"]):
	print repr(change)

Should return

'- \tI am a buggy'
'? \t          --\n'
'+ \t\tI am a bug'
'? +\n'

but actually returns (no hint for the added tab)

'- \tI am a buggy'
'? \t          --\n'
'+ \t\tI am a bug'

sys.version reports
2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit
(Intel)]

----------------------------------------------------------------------

>Comment By: Henry (henryl)
Date: 2006-05-16 21:19

Message:
Logged In: YES 
user_id=1083163

Try again (this time selecting check box)...

----------------------------------------------------------------------

Comment By: Henry (henryl)
Date: 2006-05-16 21:18

Message:
Logged In: YES 
user_id=1083163

Patch to lib/test/test_difflib.py attached.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1488943&group_id=5470

From noreply at sourceforge.net  Tue May 16 15:21:55 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 16 May 2006 06:21:55 -0700
Subject: [ python-Bugs-1488943 ] difflib.Differ() doesn't always add hints for
	tab characters
Message-ID: <E1FfzUp-0002zl-Kx@sc8-sf-web2.sourceforge.net>

Bugs item #1488943, was opened at 2006-05-16 00:27
Message generated for change (Comment added) made by henryl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1488943&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: Henry (henryl)
Assigned to: Nobody/Anonymous (nobody)
Summary: difflib.Differ() doesn't always add hints for tab characters

Initial Comment:
The difflib.Differ() object doesn't always add a hint
for added tab characters.

eg:
import difflib
differ = difflib.Differ()
for change in differ.compare(["\tI am a buggy"],
["\t\tI am a bug"]):
	print repr(change)

Should return

'- \tI am a buggy'
'? \t          --\n'
'+ \t\tI am a bug'
'? +\n'

but actually returns (no hint for the added tab)

'- \tI am a buggy'
'? \t          --\n'
'+ \t\tI am a bug'

sys.version reports
2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit
(Intel)]

----------------------------------------------------------------------

>Comment By: Henry (henryl)
Date: 2006-05-16 21:21

Message:
Logged In: YES 
user_id=1083163

Fix attached. Note that this also modifies the doctest for
Differ._qformat, as the doctest version actually exhibited
the bug (the added tab character wasn't hinted).

----------------------------------------------------------------------

Comment By: Henry (henryl)
Date: 2006-05-16 21:19

Message:
Logged In: YES 
user_id=1083163

Try again (this time selecting check box)...

----------------------------------------------------------------------

Comment By: Henry (henryl)
Date: 2006-05-16 21:18

Message:
Logged In: YES 
user_id=1083163

Patch to lib/test/test_difflib.py attached.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1488943&group_id=5470

From noreply at sourceforge.net  Tue May 16 17:49:49 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 16 May 2006 08:49:49 -0700
Subject: [ python-Bugs-1489648 ] time module missing from global mod index
Message-ID: <E1Fg1nx-0003ST-L2@sc8-sf-web4-b.sourceforge.net>

Bugs item #1489648, was opened at 2006-05-16 10: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=1489648&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: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Nobody/Anonymous (nobody)
Summary: time module missing from global mod index

Initial Comment:
The time module is not listed in the latest dev global
module index:

http://docs.python.org/dev/modindex.html

Skip


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1489648&group_id=5470

From noreply at sourceforge.net  Tue May 16 18:35:41 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 16 May 2006 09:35:41 -0700
Subject: [ python-Bugs-1417699 ] float/atof have become locale aware
Message-ID: <E1Fg2WL-0006YA-19@sc8-sf-web1.sourceforge.net>

Bugs item #1417699, was opened at 2006-01-29 01:04
Message generated for change (Comment added) made by gustavo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1417699&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: 7
Submitted By: Bernhard Herzog (bernhard)
Assigned to: Nobody/Anonymous (nobody)
Summary: float/atof have become locale aware

Initial Comment:
The builtin float and the function string.atof have
become locale aware in Python 2.4:

Python 2.4.2 (#1, Nov 29 2005, 16:07:55) 
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import locale
>>> import string
>>> locale.setlocale(locale.LC_ALL, "de_DE")
'de_DE'
>>> float("1,5")
1.5
>>> string.atof("1,5")
1.5


This doesn't match what's specified in pep 331:

        - float() and str() stay locale-unaware.

It also doesn't match the documentation for atof:

  Convert a string to a floating point number.
  The string must have the standard syntax for a
  floating point literal in Python, optionally
  preceded by a sign ("+" or "-"). Note that this
  behaves identical to the built-in function float()
  when passed a string.

The documentation for float() doesn't state which
format is accepted by float(), though.

The reason for this behavior is ultimately, that
PyOS_ascii_strtod accepts the locale specific
convention in addition to the "C"-locale/python
convention, even though the comment in the code
preceding its definition states:

  This function behaves like the standard strtod() 
  function does in the C locale.




----------------------------------------------------------------------

Comment By: Gustavo J. A. M. Carneiro (gustavo)
Date: 2006-05-16 17:35

Message:
Logged In: YES 
user_id=908

It seems I can't upload files?!
I have put the patch to fix this problem, including unit
test, here: http://www.gnome.org/~gjc/python-1417699.diff

----------------------------------------------------------------------

Comment By: Gustavo J. A. M. Carneiro (gustavo)
Date: 2006-05-13 12:59

Message:
Logged In: YES 
user_id=908

I'm quite busy at this moment, but I'll send a patch soon,
promise.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-05-12 15:14

Message:
Logged In: YES 
user_id=21627

Unassigning myself - I don't plan to work on this anytime soon.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-05-08 19:00

Message:
Logged In: YES 
user_id=849994

I grepped around and found PyOS_ascii_strtod in the
following places:

* stropmodule::atof
* cPickle::load_float (the writing of locale dependent
floats was fixed recently)
* floatobject::PyFloat_FromString
* complexobject::complex_subtype_from_string

In my opinion, all these should not tolerate localized
floats, so Gustavo, please ask the original author how to
achieve this.

----------------------------------------------------------------------

Comment By: Gustavo J. A. M. Carneiro (gustavo)
Date: 2006-05-04 10:47

Message:
Logged In: YES 
user_id=908

My comment is, is "PyOS_ascii_strtod accepting both forms"
something that is harmful and should be fixed?

I didn't exactly write the PyOS_ascii_strtod code; I only
integrated it with Python.  But if we really need to fix
this, I'll try to figure out how to make it not accept
floating points in locale aware format; if necessary I'll
ask help from  the original author of the code, Alexander
Larsson.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-05-04 05:42

Message:
Logged In: YES 
user_id=21627

It's a bug. As bernhard says, it originates from
PyOS_ascii_strtod accepting both forms, which in turn
happens because it just leaves the locale-specific decimal
point in the string, only replacing the . with the
locale-specific point. Then, the platform's strtod will
happily accept the locale-specific version. 

I'd like Gustavo Carneiro to comment.

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-17 12:19

Message:
Logged In: YES 
user_id=1188172

Martin, you checked in the patch which is mentioned in PEP
331. Is this correct behavior?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1417699&group_id=5470

From noreply at sourceforge.net  Tue May 16 20:44:42 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 16 May 2006 11:44:42 -0700
Subject: [ python-Bugs-1489648 ] time module missing from global mod index
Message-ID: <E1Fg4XC-0008T3-8o@sc8-sf-web3.sourceforge.net>

Bugs item #1489648, was opened at 2006-05-17 00:49
Message generated for change (Comment added) made by quiver
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1489648&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: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: time module missing from global mod index

Initial Comment:
The time module is not listed in the latest dev global
module index:

http://docs.python.org/dev/modindex.html

Skip


----------------------------------------------------------------------

>Comment By: George Yoshida (quiver)
Date: 2006-05-17 03:44

Message:
Logged In: YES 
user_id=671362

Same as bug #1109523

I can't reproduce this in my local environment but Fred
should know the reason.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1489648&group_id=5470

From noreply at sourceforge.net  Thu May 18 02:53:48 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 17 May 2006 17:53:48 -0700
Subject: [ python-Bugs-1326406 ] pdb breaks programs which import from __main__
Message-ID: <E1FgWlw-00051f-Rg@sc8-sf-web1.sourceforge.net>

Bugs item #1326406, was opened at 2005-10-13 21:23
Message generated for change (Comment added) made by isandler
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1326406&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: Ilya Sandler (isandler)
Assigned to: Nobody/Anonymous (nobody)
Summary: pdb breaks programs which import from __main__

Initial Comment:
The following example illustrates the problem:

  bagira:~/python/dist/src/Lib> cat tt/xx
  hello=None
  import yy
  print "in xx:yy imported"

  bagira:~/python/dist/src/Lib> cat tt/yy.py
  from __main__ import hello
  print "in yy: yy imported "

this works by itself:

  bagira:~/python/dist/src/Lib> ../python tt/xx
  in yy: yy imported 
  in xx:yy imported

But breaks under pdb

 bagira:~/python/dist/src/Lib> ../python -m pdb tt/xx 
 > /home/ilya/python/dist/src/Lib/tt/xx(1)?()
 -> hello=None
  (Pdb) c
  Traceback (most recent call last):
   File "/home/ilya/python/dist/src/Lib/pdb.py", line
1057, in main
    pdb._runscript(mainpyfile)
   File "/home/ilya/python/dist/src/Lib/pdb.py", line
982, in       _runscript
     self.run(statement, globals=globals_, locals=locals_)
   File "/home/ilya/python/dist/src/Lib/bdb.py", line
367, in run
     exec cmd in globals, locals
   File "<string>", line 1, in ?
   File "tt/xx", line 2, in ?
     import yy
   File "/home/ilya/python/dist/src/Lib/tt/yy.py", line
1, in ?
     from __main__ import hello
 ImportError: cannot import name hello
 Uncaught exception. Entering post mortem debugging
 Running 'cont' or 'step' will restart the program
  > /home/ilya/python/dist/src/Lib/tt/yy.py(1)?()
 -> from __main__ import hello




----------------------------------------------------------------------

>Comment By: Ilya Sandler (isandler)
Date: 2006-05-17 17:53

Message:
Logged In: YES 
user_id=971153

I have submitted a patch #1429539 for this


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1326406&group_id=5470

From noreply at sourceforge.net  Thu May 18 06:31:54 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 17 May 2006 21:31:54 -0700
Subject: [ python-Bugs-1490688 ] %g incorrect conversion
Message-ID: <E1FgaB0-0008Ti-NT@sc8-sf-web2.sourceforge.net>

Bugs item #1490688, was opened at 2006-05-18 04:31
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=1490688&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: paul rubin (phr)
Assigned to: Nobody/Anonymous (nobody)
Summary: %g incorrect conversion

Initial Comment:
According to
http://docs.python.org/lib/typesseq-strings.html

%g is the same as %f or %e depending on the exponent. 
Test:

Python 2.4.1 (#1, May 16 2005, 15:19:29)
[GCC 4.0.0 20050512 (Red Hat 4.0.0-5)] on linux2

>>> x=.123999
>>> '%.4f'%x
'0.1240'
>>> '%.4g'%x
'0.124'
>>>

These are not the same.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1490688&group_id=5470

From noreply at sourceforge.net  Thu May 18 09:01:55 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 18 May 2006 00:01:55 -0700
Subject: [ python-Bugs-1462152 ] Python does not check for POSIX compliant
	open() modes
Message-ID: <E1FgcWB-0008CV-S0@sc8-sf-web1.sourceforge.net>

Bugs item #1462152, was opened at 2006-03-31 15:02
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462152&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: Matt Fleming (splitscreen)
Assigned to: Georg Brandl (gbrandl)
Summary: Python does not check for POSIX compliant open() modes

Initial Comment:
Python does not check for POSIX-compliant modes when
passing them to open() and fopen().

According to the POSIX standard all modes should start
with either an 'a', 'r' or 'w'.

This patch implements this check in the
check_the_mode() function of fileobject.c and a test
has been modified in the test_file.py test.

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-05-18 07:01

Message:
Logged In: YES 
user_id=849994

Corrected and committed in rev. 46037.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-05-10 02:16

Message:
Logged In: YES 
user_id=31435

You're right, I reviewed the older patch.  One of the same
comments, though, plus a new one:

1. The docs should state that this requirement is new in
Python 2.5; in LaTeX, something like

\versionchanged[Restriction on first letter of mode string
introduced]{2.5}

2. We can never assume that allocating memory will work:   after

    newmode = PyMem_MALLOC(strlen(mode) + 3);

you must guard against `newmode` being NULL (and raise an
exception it if is; e.g., call PyErr_NoMemory()).

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-04-28 09:55

Message:
Logged In: YES 
user_id=849994

Tim: Did you review file-modes.diff which is really the
latest patch? (There's no test in it either, but I'll add
one when I check it in)

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-04-24 01:19

Message:
Logged In: YES 
user_id=31435

This is still ;-) fine with me.  There doesn't seem to be a
test in fileobject2.diff.  WRT the docs, "must either be"
should say "must be one of" instead ("either" is proper for
two choices, but there are three).  It should state that
this requirement is new in Python 2.5; in LaTeX, something like

\versionchanged[Restriction on first letter of mode string
introduced]{2.5}

----------------------------------------------------------------------

Comment By: Matt Fleming (splitscreen)
Date: 2006-04-12 10:14

Message:
Logged In: YES 
user_id=1126061

Yeah, your patch looks much better.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-04-06 08:15

Message:
Logged In: YES 
user_id=849994

splitscreen: your patch was incomplete and could have
overwritten memory.

tim_one: Attaching new patch implementing what I proposed in
my comment below.

----------------------------------------------------------------------

Comment By: Matt Fleming (splitscreen)
Date: 2006-04-01 21:59

Message:
Logged In: YES 
user_id=1126061

Ok, uploading latest patch, not quite sure I've hit the mark
here.

Please review.


----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-04-01 20:43

Message:
Logged In: YES 
user_id=849994

Yes, I want to remove 'U' from the mode since it's at this
point already recognized by Python, and it's not meaningful
to the underlying C library.

----------------------------------------------------------------------

Comment By: Matt Fleming (splitscreen)
Date: 2006-04-01 19:32

Message:
Logged In: YES 
user_id=1126061

Ignore my question, it's for "universal newlines", right? 

Have I understood your proposal correctly in that you want
to remove the 'U' from the mode? 

----------------------------------------------------------------------

Comment By: Matt Fleming (splitscreen)
Date: 2006-04-01 14:14

Message:
Logged In: YES 
user_id=1126061

That seems sensible. What does a mode containing 'U' mean
anyway?

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-04-01 07:08

Message:
Logged In: YES 
user_id=849994

Instead of this patch, I'd rather like check_the_mode to

* remove any 'U' from the mode string
* if 'U' was found:
  * error out if the new string begins with 'w' or 'a'
  * add a 'r' and 'b' if it isn't already given
* if not:
  * error out if the string doesn't begin with 'w', 'r', 'a'

What do you think of it?

----------------------------------------------------------------------

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

Message:
Logged In: YES 
user_id=31435

There's a small danger of backward-incompatibility here,
since platforms are free to support any goofy mode
characters they like, and Python just passes on whatever the
user typed.  I understand that some MS compilers in debug
mode raise internal exceptions, but that's an MS bug and the
workaround is dead easy ("don't do that").

All that said, I'm in favor of this patch ;-).  However, if
it goes in two things are needed:

1. The error message should be more informative, like

   PyErr_Format(PyExc_ValueError, "mode argument must "
     "begin with 'w', 'r', or 'a', not '%.200s'", mode);

2. The Python docs should change to match (i.e., the
   manual should document this new restriction on mode
   strings).

WRT the test case, it's more natural to write, e.g.,

    TESTFN in s

than

    s.find(TESTFN) != -1

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462152&group_id=5470

From noreply at sourceforge.net  Thu May 18 09:20:40 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 18 May 2006 00:20:40 -0700
Subject: [ python-Bugs-1490688 ] %g incorrect conversion
Message-ID: <E1FgcoK-0000Ii-Q8@sc8-sf-web3.sourceforge.net>

Bugs item #1490688, was opened at 2006-05-18 04:31
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1490688&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: paul rubin (phr)
Assigned to: Nobody/Anonymous (nobody)
Summary: %g incorrect conversion

Initial Comment:
According to
http://docs.python.org/lib/typesseq-strings.html

%g is the same as %f or %e depending on the exponent. 
Test:

Python 2.4.1 (#1, May 16 2005, 15:19:29)
[GCC 4.0.0 20050512 (Red Hat 4.0.0-5)] on linux2

>>> x=.123999
>>> '%.4f'%x
'0.1240'
>>> '%.4g'%x
'0.124'
>>>

These are not the same.


----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-05-18 07:20

Message:
Logged In: YES 
user_id=849994

The conversion is actually correct, but the docs aren't.
Committed a fix in rev. 46038.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1490688&group_id=5470

From noreply at sourceforge.net  Thu May 18 09:27:39 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 18 May 2006 00:27:39 -0700
Subject: [ python-Bugs-1474677 ] non-keyword argument following keyword
Message-ID: <E1Fgcv5-00044W-OT@sc8-sf-web4-b.sourceforge.net>

Bugs item #1474677, was opened at 2006-04-22 16:11
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1474677&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: George Yoshida (quiver)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: non-keyword argument following keyword

Initial Comment:
  def foo(a,b=None):pass
  foo(b=1,2)

With Python 2.5(compiled as of 2006-04-23), this code
runs without any error.

In older Python(although I didn't check every version
of it), I get
  File "foo.py", line 2
    foo(b=1,2)
SyntaxError: non-keyword arg after keyword arg


----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-04-29 13:51

Message:
Logged In: YES 
user_id=849994

Patch attached.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-25 05:48

Message:
Logged In: YES 
user_id=33168

Confirmed 2.5 behaviour and regression from 2.[34].

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-25 05:47

Message:
Logged In: YES 
user_id=33168

Jeremy, could you look at this?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1474677&group_id=5470

From noreply at sourceforge.net  Thu May 18 09:27:51 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 18 May 2006 00:27:51 -0700
Subject: [ python-Bugs-1474677 ] non-keyword argument following keyword
Message-ID: <E1FgcvH-00049F-LB@sc8-sf-web4-b.sourceforge.net>

Bugs item #1474677, was opened at 2006-04-22 16:11
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1474677&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: Python 2.5
Status: Open
Resolution: None
>Priority: 7
Submitted By: George Yoshida (quiver)
Assigned to: Neal Norwitz (nnorwitz)
Summary: non-keyword argument following keyword

Initial Comment:
  def foo(a,b=None):pass
  foo(b=1,2)

With Python 2.5(compiled as of 2006-04-23), this code
runs without any error.

In older Python(although I didn't check every version
of it), I get
  File "foo.py", line 2
    foo(b=1,2)
SyntaxError: non-keyword arg after keyword arg


----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-04-29 13:51

Message:
Logged In: YES 
user_id=849994

Patch attached.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-25 05:48

Message:
Logged In: YES 
user_id=33168

Confirmed 2.5 behaviour and regression from 2.[34].

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-25 05:47

Message:
Logged In: YES 
user_id=33168

Jeremy, could you look at this?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1474677&group_id=5470

From noreply at sourceforge.net  Thu May 18 15:22:13 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 18 May 2006 06:22:13 -0700
Subject: [ python-Bugs-1490929 ] urllib.retrieve's reporthook called with
	non-helpful value
Message-ID: <E1FgiSD-0001O9-Co@sc8-sf-web3.sourceforge.net>

Bugs item #1490929, was opened at 2006-05-18 10:22
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=1490929&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: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Sidnei da Silva (dreamcatcher)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib.retrieve's reporthook called with non-helpful value

Initial Comment:
Seems like the 'reporthook', when provided to the
'retrieve' function of urllib will be called with
(blocknumber, blocksize, totalsize).

However, the call to read() might return *less* than
'blocksize' bytes (I believe), so it should imho be
called with len(block) as the second argument instead.
Or maybe add a fourth argument 'readbytes'.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1490929&group_id=5470

From noreply at sourceforge.net  Fri May 19 00:51:16 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 18 May 2006 15:51:16 -0700
Subject: [ python-Bugs-1487481 ] Could BIND_FIRST be removed on HP-UX?
Message-ID: <E1FgrKu-00024b-DS@sc8-sf-web3.sourceforge.net>

Bugs item #1487481, was opened at 2006-05-12 11:32
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1487481&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: G?ran Uddeborg (goeran)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Could BIND_FIRST be removed on HP-UX?

Initial Comment:
I'm trying to build Python 2.4.3 on HP-UX 11.  I need
tkinter, so I have first built Tcl and Tk 8.4.13.

During the build, the python interpreter crashes.  When
running the setup.py script, just after making the
_tkinter.sl module, it crashes with a memory fault.

I've tried to investigate this, and it seems that
malloc and friends gets confused by the dynamic
loading.  I've filed a support request with HP about this.

One observation I made is that this malloc bug seems to
be connected with the use of BIND_FIRST in
dynload_hpux.c.  If I just remove this flag (in two
places) it appears as if Python works normally.

I'm hesitant if this is a good idea.  BIND_FIRST is
there as an explicit, non-default, flag.  Somebody must
have choosen to do so for some reason.  What was that
reason?  And is it still valid?  If not, maybe the flag
could be removed, and this problem in HP-UX be avoided?

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2006-05-18 18:51

Message:
Logged In: YES 
user_id=6380

Sorry, I don't have access to email that old any more.

HP-UX is quite different now than it was then.

It would make more sense to ask an HP-UX expert.  I'll ask
Peter Kropf, who helped Elemental with the HP-UX port.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-05-13 12:38

Message:
Logged In: YES 
user_id=21627

BIND_FIRST was added with this commit:

------------------------------------------------------------------------
r7068 | guido | 1996-12-06 00:15:35 +0100 (Fr, 06 Dez 1996)
| 2 lines
Ge??nderte Pfade:
   M /python/trunk/Python/importdl.c

Some extra flags that an HPUX user wants me to add.

------------------------------------------------------------------------

Guido, do you have any records on which user that was
and why he wanted these flags to be added?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1487481&group_id=5470

From noreply at sourceforge.net  Fri May 19 07:45:29 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 18 May 2006 22:45:29 -0700
Subject: [ python-Bugs-1487481 ] Could BIND_FIRST be removed on HP-UX?
Message-ID: <E1Fgxnl-0001DW-BN@sc8-sf-web3.sourceforge.net>

Bugs item #1487481, was opened at 2006-05-12 11:32
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1487481&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: G?ran Uddeborg (goeran)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Could BIND_FIRST be removed on HP-UX?

Initial Comment:
I'm trying to build Python 2.4.3 on HP-UX 11.  I need
tkinter, so I have first built Tcl and Tk 8.4.13.

During the build, the python interpreter crashes.  When
running the setup.py script, just after making the
_tkinter.sl module, it crashes with a memory fault.

I've tried to investigate this, and it seems that
malloc and friends gets confused by the dynamic
loading.  I've filed a support request with HP about this.

One observation I made is that this malloc bug seems to
be connected with the use of BIND_FIRST in
dynload_hpux.c.  If I just remove this flag (in two
places) it appears as if Python works normally.

I'm hesitant if this is a good idea.  BIND_FIRST is
there as an explicit, non-default, flag.  Somebody must
have choosen to do so for some reason.  What was that
reason?  And is it still valid?  If not, maybe the flag
could be removed, and this problem in HP-UX be avoided?

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2006-05-19 01:45

Message:
Logged In: YES 
user_id=6380

Peter Kropf wrote:

"""
BIND_FIRST causes the dynamic loader to place the newly
loaded shared
library symbol table at the head of the lookup order. This
causes
symbol lookups from that time forward to check the newly
loaded symbol
table before everything else. I can see this causing interesting
things to happen to a program if a shared library contains
symbol
names that are the same as those of, let's say, the C
runtime library.

>From what I remember of Python and HP-UX, I'd guess that
this was
added for an extension module. I don't think that it would
be from the
standard Python libraries but rather for a user's custom
extension.
"""

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2006-05-18 18:51

Message:
Logged In: YES 
user_id=6380

Sorry, I don't have access to email that old any more.

HP-UX is quite different now than it was then.

It would make more sense to ask an HP-UX expert.  I'll ask
Peter Kropf, who helped Elemental with the HP-UX port.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-05-13 12:38

Message:
Logged In: YES 
user_id=21627

BIND_FIRST was added with this commit:

------------------------------------------------------------------------
r7068 | guido | 1996-12-06 00:15:35 +0100 (Fr, 06 Dez 1996)
| 2 lines
Ge??nderte Pfade:
   M /python/trunk/Python/importdl.c

Some extra flags that an HPUX user wants me to add.

------------------------------------------------------------------------

Guido, do you have any records on which user that was
and why he wanted these flags to be added?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1487481&group_id=5470

From noreply at sourceforge.net  Fri May 19 08:44:17 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 18 May 2006 23:44:17 -0700
Subject: [ python-Bugs-1474677 ] non-keyword argument following keyword
Message-ID: <E1Fgyid-00065P-K4@sc8-sf-web4-b.sourceforge.net>

Bugs item #1474677, was opened at 2006-04-22 09:11
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1474677&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 7
Submitted By: George Yoshida (quiver)
Assigned to: Neal Norwitz (nnorwitz)
Summary: non-keyword argument following keyword

Initial Comment:
  def foo(a,b=None):pass
  foo(b=1,2)

With Python 2.5(compiled as of 2006-04-23), this code
runs without any error.

In older Python(although I didn't check every version
of it), I get
  File "foo.py", line 2
    foo(b=1,2)
SyntaxError: non-keyword arg after keyword arg


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-05-18 23:44

Message:
Logged In: YES 
user_id=33168

Thanks!  I modified the patch a bit.  seen_kw wasn't
necessary since nkeywords works just as well.

Committed revision 46045.


----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-04-29 06:51

Message:
Logged In: YES 
user_id=849994

Patch attached.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-24 22:48

Message:
Logged In: YES 
user_id=33168

Confirmed 2.5 behaviour and regression from 2.[34].

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-24 22:47

Message:
Logged In: YES 
user_id=33168

Jeremy, could you look at this?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1474677&group_id=5470

From noreply at sourceforge.net  Fri May 19 09:02:08 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 19 May 2006 00:02:08 -0700
Subject: [ python-Bugs-1481770 ] hpux ia64 shared lib ext should be ".so"
Message-ID: <E1Fgyzw-0003Gb-4g@sc8-sf-web2.sourceforge.net>

Bugs item #1481770, was opened at 2006-05-04 04:43
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1481770&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: Accepted
Priority: 5
Submitted By: David Everly (deckrider)
Assigned to: Neal Norwitz (nnorwitz)
Summary: hpux ia64 shared lib ext should be ".so"

Initial Comment:
On hpux ia64, the shared library extension should be
".so".  This is currently problematic in that other
add-on python modules (such as those for subversion)
correctly detect the host_os/host_cpu and build
_module.so, which is not seen by python built using ".sl".

According to
http://devresource.hp.com/drc/resources/portguideipf/index.jsp#dynlinkfac


"Shared library names

Since dynamic linking APIs operate on shared libraries,
it is also important to note that the shared library
naming scheme on Linux is lib*.so; whereas, on HP-UX
11i Version 1.5 the naming scheme is lib*.sl for PA and
lib*.so on IPF. Also APIs may reside in different
libraries files on Linux and HP-UX, so you may need to
dynamically load a different shared library name on
HP-UX and Linux."

To translate this quote, PA=hppa and IPF=ia64.


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-05-19 00:02

Message:
Logged In: YES 
user_id=33168

Thanks!  I fixed 2.5.  If someone whats to backport to 2.4,
feel free.

Committed revision 46046.


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-05-10 00:17

Message:
Logged In: YES 
user_id=33168

It looked fine to me too.  I wish you didn't have to set the
extension more than once.  That's not a problem with this
patch though.  I'll try to get around to checking this in
unless someone beats me to it.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-05-09 21:50

Message:
Logged In: YES 
user_id=21627

The patch looks fine to me. FYI, we include configure output
in the source repository so that people can build from the
source repository without requiring them to run autoconf
first. Patching configure.in only is the right thing to do;
whoever commits the patch will regenerate configure before
commiting it.

----------------------------------------------------------------------

Comment By: David Everly (deckrider)
Date: 2006-05-08 21:11

Message:
Logged In: YES 
user_id=1113403

I tested against hpux ia64 today, and found that the
original patch required correction.  Here is the result.

----------------------------------------------------------------------

Comment By: David Everly (deckrider)
Date: 2006-05-07 06:22

Message:
Logged In: YES 
user_id=1113403

Here is a patch against
http://svn.python.org/projects/python/branches/release24-maint

I don't have many evironments to test against, and only
Linux right now (will test on HPUX ia64 tomorrow and report
back).

----------------------------------------------------------------------

Comment By: David Everly (deckrider)
Date: 2006-05-05 05:07

Message:
Logged In: YES 
user_id=1113403

The patch I'm using now only works on hppa/ia64 and isn't
anything that can coexist nicely in the source package on
other hardware/os combinations.

I've looked at
http://svn.python.org/projects/python/branches/release24-maint/

I'm accustomed to a system using autoconf/libtool/automake
(recent versions) and never committing the output of those
tools, but only running them at source package generation time.

I say this, only to point out that I'm not understanding the
principles behind what I see in subversion.  I see
configure, and also configure.in.  Which should be patched?
 And if I don't patch configure, what is the process for
regenerating it (and with what versions of automake,
autoconf, and libtool?).

Also, the most recent libtool already correctly determines
shared library extension.

So I could probably provide a patch, but would need to
understand the environment better in order to do so.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-05-05 00:02

Message:
Logged In: YES 
user_id=33168

Do you think you could work on a patch to address this issue?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1481770&group_id=5470

From noreply at sourceforge.net  Fri May 19 09:55:00 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 19 May 2006 00:55:00 -0700
Subject: [ python-Bugs-1491431 ] glob_to_re problems
Message-ID: <E1Fgzp6-0003qG-80@sc8-sf-web1.sourceforge.net>

Bugs item #1491431, was opened at 2006-05-19 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=1491431&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: Wayne Davison (wayned)
Assigned to: Nobody/Anonymous (nobody)
Summary: glob_to_re problems

Initial Comment:
The regex substitution in distutils.filelist.glob_to_re
fails to do the right thing in a couple cases:

1. it fails to translate a dot after an even number of
backslashes.

2. it fails to translate multiple dots in row.

For example:

foo\\*   ->  foo\\.*$
foo????  ->  foo[^/].[^/].$

The following substitution fixes these problems:

 re.sub(r'((?<!\\)(\\\\)*)\.', r'\1[^/]', re_pattern)

This allows the dot to be preceeded by an even number
of backslashes (including 0) and it utilizes a negative
look-behind assertion so that adjacent dots are handled.

This problem is present in the svn code, and appears to
be identical in versions 2.4.2 and 2.3.5 (the only two
versions I had around to check).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1491431&group_id=5470

From noreply at sourceforge.net  Fri May 19 11:49:11 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 19 May 2006 02:49:11 -0700
Subject: [ python-Bugs-1491468 ] argvemulator doesn't work on intel mac
Message-ID: <E1Fh1bb-000763-Sd@sc8-sf-web2.sourceforge.net>

Bugs item #1491468, was opened at 2006-05-19 11: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=1491468&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Macintosh
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Jack Jansen (jackjansen)
Summary: argvemulator doesn't work on intel mac

Initial Comment:
According to a report on macpython-sig the argvemulator module doesn't 
work on intel macs due to endianness issues.

This seems to be a problem in aepack/aetypes.

The attached version of argvemulator should fix the problem by not using 
aepack and friends and was written by has.

I know to little of AppleEvents and the aepack module to actually fix this 
at this point in time.

I propose to replace argvemulator by the attached version.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1491468&group_id=5470

From noreply at sourceforge.net  Fri May 19 12:24:25 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 19 May 2006 03:24:25 -0700
Subject: [ python-Feature Requests-1491485 ] str.startswith/endswith could
	take a tuple?
Message-ID: <E1Fh29h-0003Rv-4N@sc8-sf-web5.sourceforge.net>

Feature Requests item #1491485, was opened at 2006-05-19 10:24
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1491485&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: Tom Lynn (tlynn)
Assigned to: Nobody/Anonymous (nobody)
Summary: str.startswith/endswith could take a tuple?

Initial Comment:
In the same way that exceptions can have a tuple of 
types specified and isinstance can take a tuple of 
types, str.startswith and endswith could take a tuple 
of possible prefixes/suffixes.

One use-case::
    if filename.endswith(('jpg', 'gif', 'png')):
         # ...
vs:
    if (filename.endswith('jpg') or filename.endswith
('gif') or
        filename.endswith('png')):
        #...

Obviously it's not a huge improvement in clarity, but 
it does seem to be an improvement to me.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1491485&group_id=5470

From noreply at sourceforge.net  Fri May 19 12:37:26 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 19 May 2006 03:37:26 -0700
Subject: [ python-Bugs-1404925 ] subprocess.Popen inside thread locks the
	thread in some case
Message-ID: <E1Fh2MI-0000d8-HW@sc8-sf-web5.sourceforge.net>

Bugs item #1404925, was opened at 2006-01-13 16:05
Message generated for change (Comment added) made by ragnark
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1404925&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: Threads
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Toon Verstraelen (tovrstra)
Assigned to: Peter ?
strand (astrand)
Summary: subprocess.Popen inside thread locks the thread in some case

Initial Comment:
The bug can be verified with the example program
attached to this bugs. Two files are attached:
my_thread.py and main.py

When main.py is executed the thread hangs on
subprocess.Popen, while my_thread.py, which is imported
by main.py runs without problems. In fact both should
do exactly the same since main.py doesn nothing but
importing my_thread.

My python version:

Python 2.4.2 (#1, Oct 17 2005, 09:05:20)
[GCC 3.3.6 (Gentoo 3.3.6, ssp-3.3.6-1.0, pie-8.7.8)] on
linux2

If any more info is required, 

----------------------------------------------------------------------

Comment By: Ragnar Kj?rstad (ragnark)
Date: 2006-05-19 10:37

Message:
Logged In: YES 
user_id=10550

I too have verified that the testprograms (with an
additional sleep) cause a deadlock, and that moving the
import statement out of os._execvp solves the problem.


However, there is a more generic problem. If fork() is
executed while any locks are held by other threads than the
one executing fork, it will deadlock the new process.

E.g, if you have a process with 2 threads. The first one is
doing work that requires locking. This could be imports, but
also anything else that uses other locks.

The second thread does a fork. If this is accidently done
while thread 1 held the lock, it will deadlock if the new
process needs the same lock.

Now, the most common use of fork is of course to do exec
right afterwards, in which case it doesn't really matter,
but it's not the only use of fork. 

See the rationalie in the manpage of pthread_atfork for
details.
(http://www.opengroup.org/onlinepubs/009695399/functions/pthread_atfork.html)



----------------------------------------------------------------------

Comment By: Yair Chuchem (bigorilla)
Date: 2006-05-09 12:30

Message:
Logged In: YES 
user_id=232571

this thread explains why this happens and how to solve it:
http://groups.google.com/group/comp.lang.python/browse_thread/thread/5fae8a453c95ae89/42f5c9f9215dbb1e#42f5c9f9215dbb1e
I implemented the fix locally at mine:
at os.py, _execvpe, first line:
remove the "from errno import ...",
add a global "import errno" at the start
and change stuff imported from errno from "X" to "errno.X"


----------------------------------------------------------------------

Comment By: Ralf Schmitt (titty)
Date: 2006-01-13 17:41

Message:
Logged In: YES 
user_id=17929

glibc version 2.3.5.
If I add a time.sleep(1) at the end of my_thread.py I can
also reproduce this error reliably on ubuntu.


----------------------------------------------------------------------

Comment By: Toon Verstraelen (tovrstra)
Date: 2006-01-13 16:58

Message:
Logged In: YES 
user_id=970944

What version of glibc do you have on your ubuntu system? I
have glibc-2.3.5-r2, where r2 stands for second patch
revision from the gentoo distribution. In my case I can not
interrupt 'python main.py'. I have to use ctrl-z and then
'kill %1'.

----------------------------------------------------------------------

Comment By: Ralf Schmitt (titty)
Date: 2006-01-13 16:30

Message:
Logged In: YES 
user_id=17929

I cannot reproduce this error on ubuntu linux using python
2.4.2.
However, I am able to reproduce it using python 2.4.2
running on FreeBSD 4.11.

Stopping the program with ctrl-c results in the following
output:

ralf at stronzo:~/tmp$ python main.py 
before Popen
^CException in thread Thread-1:
Traceback (most recent call last):
  File "/usr/local/lib/python2.4/threading.py", line 442, in
__bootstrap
    self.run()
  File "/home/ralf/tmp/my_thread.py", line 7, in run
    sp = Popen(["ls", "-al"], stdout=PIPE, stderr=STDOUT)
  File "/usr/local/lib/python2.4/subprocess.py", line 542,
in __init__
    errread, errwrite)
  File "/usr/local/lib/python2.4/subprocess.py", line 970,
in _execute_child
    data = os.read(errpipe_read, 1048576) # Exceptions
limited to 1 MB
OSError: [Errno 4] Interrupted system call

Error in atexit._run_exitfuncs:
Traceback (most recent call last):
  File "/usr/local/lib/python2.4/atexit.py", line 24, in
_run_exitfuncs
    func(*targs, **kargs)
  File "/usr/local/lib/python2.4/threading.py", line 632, in
__exitfunc
    t.join()
  File "/usr/local/lib/python2.4/threading.py", line 539, in
join
    self.__block.wait()
  File "/usr/local/lib/python2.4/threading.py", line 203, in
wait
    waiter.acquire()
KeyboardInterrupt
Error in sys.exitfunc:
Traceback (most recent call last):
  File "/usr/local/lib/python2.4/atexit.py", line 24, in
_run_exitfuncs
    func(*targs, **kargs)
  File "/usr/local/lib/python2.4/threading.py", line 632, in
__exitfunc
    t.join()
  File "/usr/local/lib/python2.4/threading.py", line 539, in
join
    self.__block.wait()
  File "/usr/local/lib/python2.4/threading.py", line 203, in
wait
    waiter.acquire()
KeyboardInterrupt
ralf at stronzo:~/tmp$


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1404925&group_id=5470

From noreply at sourceforge.net  Fri May 19 12:38:08 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 19 May 2006 03:38:08 -0700
Subject: [ python-Bugs-1487105 ] 2.5 rev 45972 fails build on Mac-Intel
Message-ID: <E1Fh2My-0000wn-59@sc8-sf-web5.sourceforge.net>

Bugs item #1487105, was opened at 2006-05-12 07:51
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1487105&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: 7
Submitted By: Alex Martelli (aleax)
Assigned to: Alex Martelli (aleax)
Summary: 2.5 rev 45972 fails build on Mac-Intel

Initial Comment:
brain:~/py25 alex$ make
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes   Parser/acceler.o 
Parser/grammar1.o Parser/listnode.o Parser/node.o Parser/parser.o 
Parser/parsetok.o Parser/bitset.o Parser/metagrammar.o Parser/
firstsets.o Parser/grammar.o Parser/pgen.o Objects/obmalloc.o Python/
mysnprintf.o Parser/tokenizer_pgen.o Parser/printgrammar.o Parser/
pgenmain.o -ldl  -o Parser/pgen
/usr/bin/ld: warning Parser/printgrammar.o cputype (18, architecture 
ppc) does not match cputype (7) for specified -arch flag: i386 (file not 
loaded)
/usr/bin/ld: Undefined symbols:
__Py_printgrammar
__Py_printnonterminals
collect2: ld returned 1 exit status
make: *** [Parser/pgen] Error 1
brain:~/py25 alex$ 

This is a MacBook Pro with gcc version 4.0.1 (Apple Computer, Inc. build 
5250) -- not sure why there's an "architecture ppc" found somewhere, 
haven't looked at it in detail yet, but at any rate this breaks the make.


Alex


----------------------------------------------------------------------

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-05-19 12:38

Message:
Logged In: YES 
user_id=580910

It seems to work for me (current trunk). Feel free to assign this to me if it 
doesn't work for you.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-05-15 08:23

Message:
Logged In: YES 
user_id=33168

Alex, can you try with a current checkout?  It looks like
Ronald checked in fixes for x86 at 45997.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1487105&group_id=5470

From noreply at sourceforge.net  Fri May 19 13:48:04 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 19 May 2006 04:48:04 -0700
Subject: [ python-Bugs-1489246 ] 2.4.3 fails to find Tcl/Tk on Solaris 10
	x86_64 
Message-ID: <E1Fh3Se-00082O-Mo@sc8-sf-web1.sourceforge.net>

Bugs item #1489246, was opened at 2006-05-16 03:52
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1489246&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.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Mooney (enchanter)
Assigned to: Nobody/Anonymous (nobody)
Summary: 2.4.3 fails to find Tcl/Tk on Solaris 10 x86_64 

Initial Comment:
First, I'm a complete python newbie, but I have lots of
experience with other languages and I'm very
experienced at building software on UNIX platforms.

I've built 64 bit (LP64) versions of Tcl 8.4.13 and Tk
8.4.13 with the Sun Studio 11 compiler.  They're
installed under /local, with the libraries in
/local/lib/64 , since the Solaris convention is to use
lib/64 for ELF64 libraries.

I can configure and compile Python 2.4.3 as an LP64
executable, but setup.py fails to find Tcl/Tk.  I'm
suspicious (but not certain) that the problem is that
the calls to self.compiler.find_library_file in
setup.py aren't finding any of the locally installed
libraries because find_library_file isn't searching the
"64" subdirectory under lib.

I've been through the README, and looked at the URL for
the FAQ mentioned in the README (though I don't see a
"section 3" of the FAQ).  Most of the suggestions in
the README in the Solaris section are geared toward
what to do when python can't find your shared libraries
*at run time*.  That's not the problem here.  I have my
loader set up (via crle with the -64 option) to search
all of the necessary locally-installed directories that
contain ELF64 libraries.  The problem is that Python's
setup can't find the libraries in the first place.

Suggestions?  If I already knew Python, I could
probably figure out how to subclass "compiler" to
always search the "/64" version of a library directory
when I'm on Solaris and the compiler flags contain a
certain set of characters (better yet would be to
actually compile something to an object file and test
whether it's ELF64).  Unfortunately, I'm not at that
level yet.

This instance is specific to Solaris, but the general
problem applies to other multi-ABI platforms too, like
IRIX, HP-UX, etc.

----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-05-19 13:48

Message:
Logged In: YES 
user_id=21627

The easiest work-around should be to edit Modules/Setup,
enabling the entire _tkinter block, with all libraries and
paths needed.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1489246&group_id=5470

From noreply at sourceforge.net  Fri May 19 15:04:58 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 19 May 2006 06:04:58 -0700
Subject: [ python-Bugs-1491574 ] distutils adds (unwanted) -xcode=pic32 in the
	compile comman
Message-ID: <E1Fh4f4-0004cx-Hl@sc8-sf-web2.sourceforge.net>

Bugs item #1491574, was opened at 2006-05-19 15:04
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1491574&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: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Toon Knapen (tknapen)
Assigned to: Nobody/Anonymous (nobody)
Summary: distutils adds (unwanted) -xcode=pic32 in the compile comman

Initial Comment:
After configuring, making and make installing the
svn-trunk version with sunstudio11 on a Solaris 9 box,
an extra '-xcode=pic32' argument is added to the
compile-command when I try to install numarray using
the setup.py that comes with numarray.

To configure python I first executed:

export CC=cc
export CFLAGS="-xarch=v9" # to force 64bit compilation
export EXTRA_CFLAGS="-xarch=v9" # 
export CXX=CC
export CXXFLAGS="-xarch=v9"
export F77=f77
export FFLAGS="-xarch=v9"
export LDFLAGS="-xarch=v9"

Note that EXTRA_CFLAGS needs to be defined too,
otherwise python itself will not be compiled with the
-xarch=v9 option.

Afterwards I want to install numarray using the
setup.py (`python setup.py install` command). During
compilation of numarray I can however see that
distutils is adding -xcode=pic32 on the command-line.
Afterwards distutils is not able to link because there
now is a mix of 32bit and 64bit code.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1491574&group_id=5470

From noreply at sourceforge.net  Fri May 19 17:51:20 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 19 May 2006 08:51:20 -0700
Subject: [ python-Bugs-1491688 ] Pickle & schizofrenic classes don't match
Message-ID: <E1Fh7G4-0002vL-7s@sc8-sf-web3.sourceforge.net>

Bugs item #1491688, was opened at 2006-05-19 17:51
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=1491688&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: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Nobody/Anonymous (nobody)
Summary: Pickle & schizofrenic classes don't match

Initial Comment:
The attached scripts causes infinite recursion on the C level resulting in a 
crash.

The script defines a subclass of object that throws an exception in its 
__reduce__ method.

This method is then uses as the value of a slot on a subclass of float. This 
subclass also defines a __class__ property that returns the __class__ of the 
value in its sole slot.

Finally an instance of the subclass of float is pickled. This results in 
infinite recursion. The problem goes away when __reduce__ doesn't raise 
an exception or when the __class__ property is removed.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1491688&group_id=5470

From noreply at sourceforge.net  Fri May 19 18:24:18 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 19 May 2006 09:24:18 -0700
Subject: [ python-Bugs-1491688 ] Pickle & schizofrenic classes don't match
Message-ID: <E1Fh7ly-0003LD-G7@sc8-sf-web1.sourceforge.net>

Bugs item #1491688, was opened at 2006-05-19 17:51
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1491688&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: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Nobody/Anonymous (nobody)
Summary: Pickle & schizofrenic classes don't match

Initial Comment:
The attached scripts causes infinite recursion on the C level resulting in a 
crash.

The script defines a subclass of object that throws an exception in its 
__reduce__ method.

This method is then uses as the value of a slot on a subclass of float. This 
subclass also defines a __class__ property that returns the __class__ of the 
value in its sole slot.

Finally an instance of the subclass of float is pickled. This results in 
infinite recursion. The problem goes away when __reduce__ doesn't raise 
an exception or when the __class__ property is removed.



----------------------------------------------------------------------

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-05-19 18:24

Message:
Logged In: YES 
user_id=580910

I forgot to mention that this patch is present in 2.3.5 upto the current SVN head.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1491688&group_id=5470

From noreply at sourceforge.net  Fri May 19 19:35:58 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 19 May 2006 10:35:58 -0700
Subject: [ python-Bugs-1491688 ] Pickle & schizofrenic classes don't match
Message-ID: <E1Fh8tK-0007Xe-5Q@sc8-sf-web1.sourceforge.net>

Bugs item #1491688, was opened at 2006-05-19 17:51
Message generated for change (Comment added) made by zseil
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1491688&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: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Nobody/Anonymous (nobody)
Summary: Pickle & schizofrenic classes don't match

Initial Comment:
The attached scripts causes infinite recursion on the C level resulting in a 
crash.

The script defines a subclass of object that throws an exception in its 
__reduce__ method.

This method is then uses as the value of a slot on a subclass of float. This 
subclass also defines a __class__ property that returns the __class__ of the 
value in its sole slot.

Finally an instance of the subclass of float is pickled. This results in 
infinite recursion. The problem goes away when __reduce__ doesn't raise 
an exception or when the __class__ property is removed.



----------------------------------------------------------------------

Comment By: ?iga Seilnacht (zseil)
Date: 2006-05-19 19:35

Message:
Logged In: YES 
user_id=1326842

This is a duplicate of bug #931877.
Patch #1462488 should fix it.

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-05-19 18:24

Message:
Logged In: YES 
user_id=580910

I forgot to mention that this patch is present in 2.3.5 upto the current SVN head.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1491688&group_id=5470

From noreply at sourceforge.net  Fri May 19 20:00:16 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 19 May 2006 11:00:16 -0700
Subject: [ python-Bugs-1491688 ] Pickle & schizofrenic classes don't match
Message-ID: <E1Fh9Gq-0001n2-El@sc8-sf-web4-b.sourceforge.net>

Bugs item #1491688, was opened at 2006-05-19 17:51
Message generated for change (Comment added) made by zseil
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1491688&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: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Nobody/Anonymous (nobody)
Summary: Pickle & schizofrenic classes don't match

Initial Comment:
The attached scripts causes infinite recursion on the C level resulting in a 
crash.

The script defines a subclass of object that throws an exception in its 
__reduce__ method.

This method is then uses as the value of a slot on a subclass of float. This 
subclass also defines a __class__ property that returns the __class__ of the 
value in its sole slot.

Finally an instance of the subclass of float is pickled. This results in 
infinite recursion. The problem goes away when __reduce__ doesn't raise 
an exception or when the __class__ property is removed.



----------------------------------------------------------------------

Comment By: ?iga Seilnacht (zseil)
Date: 2006-05-19 20:00

Message:
Logged In: YES 
user_id=1326842

This is a duplicate of bug #931877.
Patch #1462488 should fix it.

----------------------------------------------------------------------

Comment By: ?iga Seilnacht (zseil)
Date: 2006-05-19 19:35

Message:
Logged In: YES 
user_id=1326842

This is a duplicate of bug #931877.
Patch #1462488 should fix it.

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-05-19 18:24

Message:
Logged In: YES 
user_id=580910

I forgot to mention that this patch is present in 2.3.5 upto the current SVN head.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1491688&group_id=5470

From noreply at sourceforge.net  Fri May 19 20:29:32 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 19 May 2006 11:29:32 -0700
Subject: [ python-Bugs-1491688 ] Pickle & schizofrenic classes don't match
Message-ID: <E1Fh9jA-0005rn-3Y@sc8-sf-web4-b.sourceforge.net>

Bugs item #1491688, was opened at 2006-05-19 17:51
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1491688&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: Extension Modules
Group: Python 2.4
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Nobody/Anonymous (nobody)
Summary: Pickle & schizofrenic classes don't match

Initial Comment:
The attached scripts causes infinite recursion on the C level resulting in a 
crash.

The script defines a subclass of object that throws an exception in its 
__reduce__ method.

This method is then uses as the value of a slot on a subclass of float. This 
subclass also defines a __class__ property that returns the __class__ of the 
value in its sole slot.

Finally an instance of the subclass of float is pickled. This results in 
infinite recursion. The problem goes away when __reduce__ doesn't raise 
an exception or when the __class__ property is removed.



----------------------------------------------------------------------

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-05-19 20:29

Message:
Logged In: YES 
user_id=580910

That's indeed the same problem as this. 

I'm closing this bug.

----------------------------------------------------------------------

Comment By: ?iga Seilnacht (zseil)
Date: 2006-05-19 20:00

Message:
Logged In: YES 
user_id=1326842

This is a duplicate of bug #931877.
Patch #1462488 should fix it.

----------------------------------------------------------------------

Comment By: ?iga Seilnacht (zseil)
Date: 2006-05-19 19:35

Message:
Logged In: YES 
user_id=1326842

This is a duplicate of bug #931877.
Patch #1462488 should fix it.

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-05-19 18:24

Message:
Logged In: YES 
user_id=580910

I forgot to mention that this patch is present in 2.3.5 upto the current SVN head.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1491688&group_id=5470

From noreply at sourceforge.net  Fri May 19 20:32:03 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 19 May 2006 11:32:03 -0700
Subject: [ python-Bugs-1491468 ] argvemulator doesn't work on intel mac
Message-ID: <E1Fh9lb-0006kR-SC@sc8-sf-web4-b.sourceforge.net>

Bugs item #1491468, was opened at 2006-05-19 11:49
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1491468&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Macintosh
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Jack Jansen (jackjansen)
Summary: argvemulator doesn't work on intel mac

Initial Comment:
According to a report on macpython-sig the argvemulator module doesn't 
work on intel macs due to endianness issues.

This seems to be a problem in aepack/aetypes.

The attached version of argvemulator should fix the problem by not using 
aepack and friends and was written by has.

I know to little of AppleEvents and the aepack module to actually fix this 
at this point in time.

I propose to replace argvemulator by the attached version.

----------------------------------------------------------------------

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-05-19 20:32

Message:
Logged In: YES 
user_id=580910

The new version seems to be not entirely equivalent to the current version, I was 
using argvemulator in the .app wrapper for IDLE and that now behaves 
differently: before it opened quite slowly (maybe just due to my machine), now it 
doesn't make progress until the first time you quit IDLE.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1491468&group_id=5470

From noreply at sourceforge.net  Fri May 19 22:02:53 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 19 May 2006 13:02:53 -0700
Subject: [ python-Bugs-1486663 ] Over-zealous keyword-arguments check for
	built-in set class
Message-ID: <E1FhBBV-0004aE-Vn@sc8-sf-web4-b.sourceforge.net>

Bugs item #1486663, was opened at 2006-05-11 18:17
Message generated for change (Comment added) made by zseil
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1486663&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: 6
Submitted By: dib (dib_at_work)
Assigned to: Raymond Hettinger (rhettinger)
Summary: Over-zealous keyword-arguments check for built-in set class

Initial Comment:
The fix for bug #1119418 (xrange() builtin accepts
keyword arg silently) included in Python 2.4.2c1+
breaks code that passes keyword argument(s) into
classes derived from the built-in set class, even if
those derived classes explictly accept those keyword
arguments and avoid passing them down to the built-in
base class.

Simplified version of code in attached
BuiltinSetKeywordArgumentsCheckBroken.py fails at (G)
due to bug #1119418 if version < 2.4.2c1; if version >=
2.4.2c1 (G) passes thanks to that bug fix, but instead
(H) incorrectly-in-my-view fails.

[Presume similar cases would fail for xrange and the
other classes mentioned in #1119418.]

  -- David Bruce

(Tested on 2.4, 2.4.2, 2.5a2 on linux2, win32.)

----------------------------------------------------------------------

Comment By: ?iga Seilnacht (zseil)
Date: 2006-05-19 22:02

Message:
Logged In: YES 
user_id=1326842

This bug was introduced as part of the fix for bug #1119418.

It also affects collections.deque.

Can't the _PyArg_NoKeywords check simply be moved
to set_init and deque_init as it was done for
zipimport.zipimporter?

array.array doesn't need to be changed, since it
already does all of its initialization in its
__new__ method.

The rest of the types changed in that fix should not
be affected, since they are immutable.
 

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-05-11 19:23

Message:
Logged In: YES 
user_id=849994

Raymond, what to do in this case?

Note that other built-in types, such as list(), do accept
keyword arguments.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1486663&group_id=5470

From noreply at sourceforge.net  Fri May 19 22:26:18 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 19 May 2006 13:26:18 -0700
Subject: [ python-Bugs-1479099 ] 'compile' built-in function failures when
	missing EOL
Message-ID: <E1FhBYA-00072w-5W@sc8-sf-web3.sourceforge.net>

Bugs item #1479099, was opened at 2006-04-30 00:00
Message generated for change (Comment added) made by zseil
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1479099&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Ori Peleg (oripel)
Assigned to: Nobody/Anonymous (nobody)
Summary: 'compile' built-in function failures when missing EOL

Initial Comment:
The 'compile' built-in function sometimes fails when
given a source string that doesn't end in an EOL.

The following example crashes Python 2.3, 2.4, and 2.5a1:

prompt> ./python2.5 -c "compile('def foo(x):\n
pass\n#abc', 'blah.py', 'exec')"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "blah.py", line 3
    #abc
      ^
SyntaxError: invalid syntax

Attached is a patch to Lib/test/test_compile.py with a
test for this.

----------------------------------------------------------------------

Comment By: ?iga Seilnacht (zseil)
Date: 2006-05-19 22:26

Message:
Logged In: YES 
user_id=1326842

This is a documented limitation of compile. The docs
say "the input must be terminated by at least one
newline character". See:
http://docs.python.org/lib/built-in-funcs.html#l2h-16

I would say that this is a bug in the trace module
(compare trace.find_executable_module and
py_compile.compile).

----------------------------------------------------------------------

Comment By: Ori Peleg (oripel)
Date: 2006-04-30 00:07

Message:
Logged In: YES 
user_id=1131251

The case that led me to this was calling
'trace.find_executable_linenos' on source files with this
condition.

See also
https://opensvn.csie.org/traccgi/testoob/trac.cgi/ticket/206

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1479099&group_id=5470

From noreply at sourceforge.net  Fri May 19 22:58:47 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 19 May 2006 13:58:47 -0700
Subject: [ python-Feature Requests-1491485 ] str.startswith/endswith could
	take a tuple?
Message-ID: <E1FhC3b-0002hv-Gj@sc8-sf-web3.sourceforge.net>

Feature Requests item #1491485, was opened at 2006-05-19 05:24
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1491485&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: Tom Lynn (tlynn)
Assigned to: Nobody/Anonymous (nobody)
Summary: str.startswith/endswith could take a tuple?

Initial Comment:
In the same way that exceptions can have a tuple of 
types specified and isinstance can take a tuple of 
types, str.startswith and endswith could take a tuple 
of possible prefixes/suffixes.

One use-case::
    if filename.endswith(('jpg', 'gif', 'png')):
         # ...
vs:
    if (filename.endswith('jpg') or filename.endswith
('gif') or
        filename.endswith('png')):
        #...

Obviously it's not a huge improvement in clarity, but 
it does seem to be an improvement to me.


----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2006-05-19 15:58

Message:
Logged In: YES 
user_id=80475

FWIW, in Py2.5, this would be written:

   if any(filename.startswith(s) for s in suffixes):
      . . .

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1491485&group_id=5470

From noreply at sourceforge.net  Fri May 19 22:59:23 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 19 May 2006 13:59:23 -0700
Subject: [ python-Feature Requests-1474577 ] feature requests for logging lib
Message-ID: <E1FhC4B-0002yO-Oj@sc8-sf-web3.sourceforge.net>

Feature Requests item #1474577, was opened at 2006-04-22 04:50
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1474577&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: blaize rhodes (blaize)
>Assigned to: Vinay Sajip (vsajip)
Summary: feature requests for logging lib

Initial Comment:


The logger module interface is a bit broken, I reckon.
 My problems specifically are:
 
	i) It's hard to get access to the LogRecord classes
for customization.
	ii) the semantics of the debug, log, info, etc calls
is a bit strange/confusing...



Here are my proposed fixes:

a)  Add a method 
   Logger.setLogRecordClass( myLogRecordSubClass )

which sets the class that is instantiated in the
makeRecord() fn/method (yes there are two of them).

This would make customizing the LogRecord easier... 
Otherwise (I believe) in order to subclass the
LogRecord you also have to overload the Logger and
possibly the root makeRecord() function as well?  This
bloke's writen up his approach to this (it's doable but
not as nice as it should be).
 
http://qix.it/~ludoo/archive/2004/05/python_logging_customization.html

Another problem is that LogRecords are instantiated in
Logger._log so it's difficult to customize __init__
behaviour for the LogRecord (and I argue that this is a
useful thing)..  

b) A second problem is that the semantics of the log,
info, debug, etc fns is a bit broken.  Currently the
defn looks like this:

  def debug(self, msg, *args, **kwargs):

this suggests to me that a call like this is OK...

  logger.debug("here we go %(foo)s", foo = 'bar')

but it's not.  This is discussed further here...

http://groups.google.com.au/group/comp.lang.python/browse_thread/thread/322919fcac0113ec/98ceaf6fc0c56881?lnk=st&q=python+logging+keywords&rnum=1#98ceaf6fc0c56881

Instead kwargs are used for customizing the behaviour
of the debug method (e.g. exc_info, and extra).  This
seems i) a bit incongrous with its definition and
therefore confusing, and ii) a bit of a hack (it's not
completely insane though when you think about what's
happening under the hood).  Instead I propose using a
couple of calls along the lines of printf/fprintf.  In
my world we'd have a simple printf-style function... 

  def debug(self, msg, *args):  

and a more complex, more easily customizable
fprintf-style one

  def x_debug(self, log_record, msg, *args):  

In these calls *args is a valid argument for the string
formatting operator %, either a tuple of the right
length or a dictionary.  Any customization of the
behaviour of the system can be done (using keyword args
if you wish) in the log_record initializer (an example
will follow).

(Having said that perhaps we can check whether the
first arg to the new simple debug() is a logrecord and
if it is call the (hidden) extended version - that's
more pythonic I imagine)


c) This is not so much a feature request but a
motivating mode of operation that I'd like to be able
to use...

Currently you can set up log filters.  What you can
filter is largely based on what information appears in
the log record.  It'd be nice to filter messages based
on metadata  that you add at log time (i.e. in the
logger.debug(...) method).  Currently it's quite
painfull to set this up.  This is because we can't
customize the initialization of the log_record.  The
call structure in ii) above allows us to setup nice
filtering mechanisms
eg..

class GUIFilter:
   "A filter that only lets messges with gui tags
through."""
	def filter(self, log_record):
	    return hasattr(log_record, 'gui')

# set up a log, and a handler...
log = logging.getLogger(..)
file_handler = FileHandler(..)
log.addHandler(file_handler)
gui_msg_bar_handler = StreamHandler(..)
log.addHandler(gui_msg_bar_handler)
gui_msg_bar_handler.addFilter(GUIFilter())

# msg only goes to the file_handler
log.debug("here we go %s", "here's an arg")  

# msg goes to the file_handler and to the gui_handler.
log.x_debug(LogRecord(gui=True), "what you just tried
to do didn't work %s", "fool")


Change a) could be made with no backward compatability
problems (I can see), change b) could be made without
probs if you didn't overload the existing logging
methods with the new ones, and then deprecate the
existing ones  (though what you'd call the new fns I
don't know).

That said I quite like the logger lib and I use it. 
It's a lot better than anything I would have thought up.


cheers
    blaize



----------------------------------------------------------------------

Comment By: Vinay Sajip (vsajip)
Date: 2006-05-02 04:11

Message:
Logged In: YES 
user_id=308438

Why does the recent introduction of the 'extra' keyword
argument, meant to allow easily adding extra attributes to
the LogRecord, not meet your use cases? The LogRecord is
meant to be just a handy container and not have much logic
(e.g. it needs to be serialised as XML, pickle etc.); why do
you need to customise LogRecord.__init__? I didn't see an
actual argument above for doing this, please point it out.

It's also the case that the msg argument passed to a logging
call need not be a string; it can be an arbitrary object on
which str() is called at message formatting time to get the
actual format string. So a custom object defining __str__
can return a customised message string.

Perhaps I'm not seeing the use case you have in sufficient
detail to understand why existing functionality does not
meet your needs; please feel free to follow up with more
detailed info.



----------------------------------------------------------------------

Comment By: blaize rhodes (blaize)
Date: 2006-04-22 04:56

Message:
Logged In: YES 
user_id=264689



For readability put an "if __name__ == '__main__':" above the 

# set up a log, and a handler...

line.  Sorry I didn't realize all my whitespace would get
eaten rendering the code ambiguous.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1474577&group_id=5470

From noreply at sourceforge.net  Sat May 20 03:19:21 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 19 May 2006 18:19:21 -0700
Subject: [ python-Bugs-1486663 ] Over-zealous keyword-arguments check for
	built-in set class
Message-ID: <E1FhG7l-0006xL-Kj@sc8-sf-web3.sourceforge.net>

Bugs item #1486663, was opened at 2006-05-11 18:17
Message generated for change (Comment added) made by zseil
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1486663&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: 6
Submitted By: dib (dib_at_work)
Assigned to: Raymond Hettinger (rhettinger)
Summary: Over-zealous keyword-arguments check for built-in set class

Initial Comment:
The fix for bug #1119418 (xrange() builtin accepts
keyword arg silently) included in Python 2.4.2c1+
breaks code that passes keyword argument(s) into
classes derived from the built-in set class, even if
those derived classes explictly accept those keyword
arguments and avoid passing them down to the built-in
base class.

Simplified version of code in attached
BuiltinSetKeywordArgumentsCheckBroken.py fails at (G)
due to bug #1119418 if version < 2.4.2c1; if version >=
2.4.2c1 (G) passes thanks to that bug fix, but instead
(H) incorrectly-in-my-view fails.

[Presume similar cases would fail for xrange and the
other classes mentioned in #1119418.]

  -- David Bruce

(Tested on 2.4, 2.4.2, 2.5a2 on linux2, win32.)

----------------------------------------------------------------------

Comment By: ?iga Seilnacht (zseil)
Date: 2006-05-20 03:19

Message:
Logged In: YES 
user_id=1326842

See patch #1491939

----------------------------------------------------------------------

Comment By: ?iga Seilnacht (zseil)
Date: 2006-05-19 22:02

Message:
Logged In: YES 
user_id=1326842

This bug was introduced as part of the fix for bug #1119418.

It also affects collections.deque.

Can't the _PyArg_NoKeywords check simply be moved
to set_init and deque_init as it was done for
zipimport.zipimporter?

array.array doesn't need to be changed, since it
already does all of its initialization in its
__new__ method.

The rest of the types changed in that fix should not
be affected, since they are immutable.
 

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-05-11 19:23

Message:
Logged In: YES 
user_id=849994

Raymond, what to do in this case?

Note that other built-in types, such as list(), do accept
keyword arguments.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1486663&group_id=5470

From noreply at sourceforge.net  Sat May 20 08:08:47 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 19 May 2006 23:08:47 -0700
Subject: [ python-Bugs-1479586 ] Segmentation fault while using Tkinter
Message-ID: <E1FhKdr-00029g-Nq@sc8-sf-web3.sourceforge.net>

Bugs item #1479586, was opened at 2006-05-01 09:25
Message generated for change (Comment added) made by aligrudi
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1479586&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: Tkinter
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Ali Gholami Rudi (aligrudi)
Assigned to: Martin v. L??wis (loewis)
Summary: Segmentation fault while using Tkinter

Initial Comment:
While using Tkinter I encountere segmentation faults
regularly. I ran my program using gdb using python2.4
and Fedora Core 5 and received:

(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread -1209063760 (LWP 2024)]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[New Thread -1212232800 (LWP 2027)]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
---Type <return> to continue, or q <return> to quit---
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1209063760 (LWP 2024)]
0x001519ce in TkUndoSetDepth () from /usr/lib/libtk8.4.so
(gdb) 


I ran the same program using python2.5a2 and again
received:

Starting program: /usr/local/bin/python
~/temp/rope/rope/rope.py
Reading symbols from shared object read from target
memory...done.
Loaded system supplied DSO at 0xa05000
[Thread debugging using libthread_db enabled]
[New Thread -1208899920 (LWP 2415)]
[New Thread -1212068960 (LWP 2418)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1208899920 (LWP 2415)]
0x001519ce in TkUndoSetDepth () from /usr/lib/libtk8.4.so
(gdb)


Are these information enough for fixing the problem or
should I send my program?

Thanks


----------------------------------------------------------------------

>Comment By: Ali Gholami Rudi (aligrudi)
Date: 2006-05-20 10:38

Message:
Logged In: YES 
user_id=965314

When I complied Tk/Tcl myself the problem was solved. I
think the built rpm that comes with Fedora5 has problems.

Thanks 

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-05-02 10:57

Message:
Logged In: YES 
user_id=21627

Apparently, this has something to do with the undo mechanism
of the text widget; I would expect the problem to go away if
you disable undo (text["undo"]=0). Other than that, there is
not much I can tell, from either looking at the source or at
the backtrace.

Most likely, it is some bug in Tcl/Tk. It also could be that
Python is corrupting memory somehow, and that this causes Tk
to crash.

If you want to debug this yourself, compile Tcl/Tk (with,
say, --prefix==/var/tmp). Use --disable-shared
--enable-symbols for both Tcl and Tk, then edit
Modules/Setup to statically link _tkinter into the Python
interpreter. Replace the -ltk8.2 line with an explict
/var/tmp/lib/libtk8.4g.a, to be sure that your version of tk
is used.

Then run it in a debugger, and find out why it crashes. Is
it really crashing inside TkUndoSetDepth? If so, what is the
value of stack? What is the value of maxdepth? What is the
Tcl command being executed (if Tcl_Eval is on the stack, go
up several times, and print the value of its string argument).

----------------------------------------------------------------------

Comment By: Ali Gholami Rudi (aligrudi)
Date: 2006-05-02 09:55

Message:
Logged In: YES 
user_id=965314

I don't know when the segmentation fault occurs. So I can't
write
a test case to reproduce it. That is when I work with my
program(which
is attached) after a some time(a few minutes or a few hours)
I receive
SIGSEGV.

I did not compile Tcl/Tk. And I used the default
configuration for
compiling Python2.5a2. The 'import sys; print
sys.maxunicode;' prints
65535 in both Python versions I've used.


Python 2.4.2
------------
Python 2.4.2 (#1, Feb 12 2006, 03:59:46) 
[GCC 4.1.0 20060210 (Red Hat 4.1.0-0.24)] on linux2

<<<gdb output start>>>
GNU gdb Red Hat Linux (6.3.0.0-1.122rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public
License, and you are
welcome to change it and/or distribute copies of it under
certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show
warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...(no
debugging symbols found)
Using host libthread_db library "/lib/libthread_db.so.1".

(gdb) run ~/temp/rope/rope/rope.py 
Starting program: /usr/bin/python2.4 ~/temp/rope/rope/rope.py
Reading symbols from shared object read from target
memory...(no debugging symbols found)...done.
Loaded system supplied DSO at 0x8a8000
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread -1208494416 (LWP 2121)]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[New Thread -1211663456 (LWP 2124)]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1208494416 (LWP 2121)]
0x0099e9ce in TkUndoSetDepth () from /usr/lib/libtk8.4.so
(gdb) bt
#0  0x0099e9ce in TkUndoSetDepth () from /usr/lib/libtk8.4.so
#1  0x0099eac9 in TkUndoInsertUndoSeparator () from
/usr/lib/libtk8.4.so
#2  0x009f7208 in TkTextLostSelection () from
/usr/lib/libtk8.4.so
#3  0x0017fc7e in TclInvokeStringCommand () from
/usr/lib/libtcl8.4.so
#4  0x001815e4 in TclEvalObjvInternal () from
/usr/lib/libtcl8.4.so
#5  0x001ae2aa in Tcl_ExprObj () from /usr/lib/libtcl8.4.so
#6  0x001b218c in TclCompEvalObj () from /usr/lib/libtcl8.4.so
#7  0x001df09c in TclObjInterpProc () from /usr/lib/libtcl8.4.so
#8  0x001815e4 in TclEvalObjvInternal () from
/usr/lib/libtcl8.4.so
#9  0x00181b8f in Tcl_EvalEx () from /usr/lib/libtcl8.4.so
#10 0x00181e9c in Tcl_Eval () from /usr/lib/libtcl8.4.so
#11 0x00181f36 in Tcl_GlobalEval () from /usr/lib/libtcl8.4.so
#12 0x0097a9d9 in Tk_BindEvent () from /usr/lib/libtk8.4.so
#13 0x00980414 in TkBindEventProc () from /usr/lib/libtk8.4.so
#14 0x00985cbf in Tk_HandleEvent () from /usr/lib/libtk8.4.so
#15 0x009862db in Tk_HandleEvent () from /usr/lib/libtk8.4.so
#16 0x001d4267 in Tcl_ServiceEvent () from /usr/lib/libtcl8.4.so
#17 0x001d4537 in Tcl_DoOneEvent () from /usr/lib/libtcl8.4.so
#18 0x00114c6c in init_tkinter () from
/usr/lib/python2.4/lib-dynload/_tkinter.so
#19 0x007da92d in PyCFunction_Call () from
/usr/lib/libpython2.4.so.1.0
#20 0x00815646 in PyEval_EvalFrame () from
/usr/lib/libpython2.4.so.1.0
#21 0x008162c6 in PyEval_EvalCodeEx () from
/usr/lib/libpython2.4.so.1.0
#22 0x00814950 in PyEval_EvalFrame () from
/usr/lib/libpython2.4.so.1.0
#23 0x008151d7 in PyEval_EvalFrame () from
/usr/lib/libpython2.4.so.1.0
#24 0x008162c6 in PyEval_EvalCodeEx () from
/usr/lib/libpython2.4.so.1.0
#25 0x00816353 in PyEval_EvalCode () from
/usr/lib/libpython2.4.so.1.0
#26 0x00832f78 in Py_CompileString () from
/usr/lib/libpython2.4.so.1.0
#27 0x00834688 in PyRun_SimpleFileExFlags () from
/usr/lib/libpython2.4.so.1.0
#28 0x00834d6a in PyRun_AnyFileExFlags () from
/usr/lib/libpython2.4.so.1.0
#29 0x0083b45f in Py_Main () from /usr/lib/libpython2.4.so.1.0
#30 0x080485b2 in main ()
(gdb) 
<<<gdb output end>>>



Python 2.5a2
------------
Python 2.5a2 (r25a2:45740, Apr 29 2006, 18:39:09) 
[GCC 4.1.0 20060304 (Red Hat 4.1.0-3)] on linux2

<<<gdb output start>>>
GNU gdb Red Hat Linux (6.3.0.0-1.122rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public
License, and you are
welcome to change it and/or distribute copies of it under
certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show
warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...Using
host libthread_db library "/lib/libthread_db.so.1".

(gdb) run ~/temp/rope/rope/rope.py 
Starting program: /usr/local/bin/python ~/temp/rope/rope/rope.py
Reading symbols from shared object read from target
memory...done.
Loaded system supplied DSO at 0x4c6000
[Thread debugging using libthread_db enabled]
[New Thread -1208731984 (LWP 2176)]
[New Thread -1211835488 (LWP 2179)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1208731984 (LWP 2176)]
0x0099e9ce in TkUndoSetDepth () from /usr/lib/libtk8.4.so
(gdb) bt
#0  0x0099e9ce in TkUndoSetDepth () from /usr/lib/libtk8.4.so
#1  0x0099eac9 in TkUndoInsertUndoSeparator () from
/usr/lib/libtk8.4.so
#2  0x009f75e7 in TkTextLostSelection () from
/usr/lib/libtk8.4.so
#3  0x0013bc7e in TclInvokeStringCommand () from
/usr/lib/libtcl8.4.so
#4  0x0013d5e4 in TclEvalObjvInternal () from
/usr/lib/libtcl8.4.so
#5  0x0013e59b in Tcl_EvalObjv () from /usr/lib/libtcl8.4.so
#6  0x00118606 in Tkapp_Call (_self=0xb71d4640, args=0xb72337d4)
    at /dev/shm/Python-2.5a2/Modules/_tkinter.c:1324
#7  0x080bc0b2 in PyEval_EvalFrameEx (f=0x89c4a0c,
throwflag=0) at Python/ceval.c:3534
#8  0x080bd807 in PyEval_EvalCodeEx (co=0xb7c627e0,
globals=0xb7ed39bc, locals=0x0, 
    args=0x89c48ac, argcount=2, kws=0x89c48b4, kwcount=0,
defs=0x0, defcount=0, closure=0x0)
    at Python/ceval.c:2809
#9  0x080bb884 in PyEval_EvalFrameEx (f=0x89c475c,
throwflag=0) at Python/ceval.c:3630
#10 0x080bcac5 in PyEval_EvalFrameEx (f=0x8a41fd4,
throwflag=0) at Python/ceval.c:3619
#11 0x080bcac5 in PyEval_EvalFrameEx (f=0x87c931c,
throwflag=0) at Python/ceval.c:3619
#12 0x080bcac5 in PyEval_EvalFrameEx (f=0x87b1ee4,
throwflag=0) at Python/ceval.c:3619
#13 0x080bcac5 in PyEval_EvalFrameEx (f=0x89a0a24,
throwflag=0) at Python/ceval.c:3619
#14 0x080bd807 in PyEval_EvalCodeEx (co=0xb7ecff60,
globals=0xb7ed38ac, locals=0x0, 
    args=0xb71e4258, argcount=1, kws=0x0, kwcount=0,
defs=0x0, defcount=0, closure=0xb71e2f8c)
    at Python/ceval.c:2809
#15 0x081044f1 in function_call (func=0xb71a8374,
arg=0xb71e424c, kw=0x0)
    at Objects/funcobject.c:517
#16 0x08059c77 in PyObject_Call (func=0xb71a8374,
arg=0xb71e424c, kw=0x0)
    at Objects/abstract.c:1792
#17 0x080ba663 in PyEval_EvalFrameEx (f=0x87e732c,
throwflag=0) at Python/ceval.c:3814
#18 0x080bd807 in PyEval_EvalCodeEx (co=0xb7ef90a0,
globals=0xb7ed39bc, locals=0x0, 
    args=0xb723e310, argcount=20, kws=0x0, kwcount=0,
defs=0x0, defcount=0, closure=0x0)
    at Python/ceval.c:2809
#19 0x081044f1 in function_call (func=0xb7c76b54,
arg=0xb723e304, kw=0x0)
    at Objects/funcobject.c:517
#20 0x08059c77 in PyObject_Call (func=0xb7c76b54,
arg=0xb723e304, kw=0x0)
    at Objects/abstract.c:1792
#21 0x0805f847 in instancemethod_call (func=0xb71a78ec,
arg=0xb723e304, kw=0x0)
    at Objects/classobject.c:2421
#22 0x08059c77 in PyObject_Call (func=0xb71a78ec,
arg=0xb7f0a9ec, kw=0x0)
    at Objects/abstract.c:1792
#23 0x080b5aac in PyEval_CallObjectWithKeywords
(func=0xb71a78ec, arg=0xb7f0a9ec, kw=0x0)
---Type <return> to continue, or q <return> to quit---
    at Python/ceval.c:3403
#24 0x001171b2 in PythonCmd (clientData=0x8b84960,
interp=0x87a2080, argc=20, argv=0x8cf1f78)
    at /dev/shm/Python-2.5a2/Modules/_tkinter.c:2011
#25 0x0013bc7e in TclInvokeStringCommand () from
/usr/lib/libtcl8.4.so
#26 0x0013d5e4 in TclEvalObjvInternal () from
/usr/lib/libtcl8.4.so
#27 0x0016a2aa in Tcl_ExprObj () from /usr/lib/libtcl8.4.so
#28 0x001674cd in Tcl_ExprObj () from /usr/lib/libtcl8.4.so
#29 0x0013ce63 in Tcl_ExprBooleanObj () from
/usr/lib/libtcl8.4.so
#30 0x0014b072 in Tcl_IfObjCmd () from /usr/lib/libtcl8.4.so
#31 0x0013d5e4 in TclEvalObjvInternal () from
/usr/lib/libtcl8.4.so
#32 0x0013db8f in Tcl_EvalEx () from /usr/lib/libtcl8.4.so
#33 0x0013de9c in Tcl_Eval () from /usr/lib/libtcl8.4.so
#34 0x0013df36 in Tcl_GlobalEval () from /usr/lib/libtcl8.4.so
#35 0x0097a9d9 in Tk_BindEvent () from /usr/lib/libtk8.4.so
#36 0x00980414 in TkBindEventProc () from /usr/lib/libtk8.4.so
#37 0x00985cbf in Tk_HandleEvent () from /usr/lib/libtk8.4.so
#38 0x009862db in Tk_HandleEvent () from /usr/lib/libtk8.4.so
#39 0x00190267 in Tcl_ServiceEvent () from /usr/lib/libtcl8.4.so
#40 0x00190537 in Tcl_DoOneEvent () from /usr/lib/libtcl8.4.so
#41 0x00116eca in Tkapp_MainLoop (_self=0xb71d4640,
args=0xb7ed690c)
    at /dev/shm/Python-2.5a2/Modules/_tkinter.c:2542
#42 0x080bc0b2 in PyEval_EvalFrameEx (f=0x8752afc,
throwflag=0) at Python/ceval.c:3534
#43 0x080bd807 in PyEval_EvalCodeEx (co=0xb7ef1520,
globals=0xb7ed39bc, locals=0x0, 
    args=0x8741154, argcount=1, kws=0x8741158, kwcount=0,
defs=0xb7c74df8, defcount=1, closure=0x0)
    at Python/ceval.c:2809
#44 0x080bb884 in PyEval_EvalFrameEx (f=0x8741004,
throwflag=0) at Python/ceval.c:3630
#45 0x080bcac5 in PyEval_EvalFrameEx (f=0x873d0c4,
throwflag=0) at Python/ceval.c:3619
#46 0x080bd807 in PyEval_EvalCodeEx (co=0xb7ecbba0,
globals=0xb7f20934, locals=0xb7f20934, 
    args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0,
defcount=0, closure=0x0)
    at Python/ceval.c:2809
#47 0x080bd877 in PyEval_EvalCode (co=0xb7ecbba0,
globals=0xb7f20934, locals=0xb7f20934)
    at Python/ceval.c:491
#48 0x080dbc2e in PyRun_FileExFlags (fp=0x870b008, 
    filename=0xbfa51aae "/home/ali/temp/rope/rope/rope.py",
start=257, globals=0xb7f20934, 
    locals=0xb7f20934, closeit=1, flags=0xbfa51538) at
Python/pythonrun.c:1224
#49 0x080dbed7 in PyRun_SimpleFileExFlags (fp=0x870b008, 
    filename=0xbfa51aae "/home/ali/temp/rope/rope/rope.py",
closeit=1, flags=0xbfa51538)
---Type <return> to continue, or q <return> to quit---
    at Python/pythonrun.c:854
#50 0x08056934 in Py_Main (argc=1, argv=0xbfa51604) at
Modules/main.c:492
#51 0x08055f02 in main (argc=Cannot access memory at address
0x13
) at ./Modules/python.c:23
(gdb) 
<<<gdb output end>>>


The attached program, using which I encounter the above
problem, is 
rope<http://sf.net/project/rope/>. The editor is in
'rope/editor.py' module.


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-05-01 11:55

Message:
Logged In: YES 
user_id=33168

If you can send a small test case that would be great. 
Also, can you attach the backtrace (bt command in gdb)?

How did you configure python?  Did you use an
--enable-unicode or --enable-threads?  Did you built Tcl/Tk
or are you using the default version with FC5?

When python starts up, what do you see?  It should be
something like:

Python 2.5a2 (trunk:45831M, Apr 30 2006, 23:27:02) 
[GCC 4.0.0 20041026 (Apple Computer, Inc. build 4061)] on darwin


Also, what does this print:  
    import sys ; print sys.maxunicode

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-05-01 11:04

Message:
Logged In: YES 
user_id=21627

Please do send your program, or better yet a small test case
that allows to reproduce the problem. It looks like a Tk bug
at first glance, in TkUndoSetDepth.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1479586&group_id=5470

From noreply at sourceforge.net  Sat May 20 08:26:33 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 19 May 2006 23:26:33 -0700
Subject: [ python-Bugs-1479586 ] Segmentation fault while using Tkinter
Message-ID: <E1FhKv3-0001zD-Ru@sc8-sf-web1.sourceforge.net>

Bugs item #1479586, was opened at 2006-05-01 06:55
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1479586&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: Tkinter
>Group: 3rd Party
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Ali Gholami Rudi (aligrudi)
Assigned to: Martin v. L??wis (loewis)
Summary: Segmentation fault while using Tkinter

Initial Comment:
While using Tkinter I encountere segmentation faults
regularly. I ran my program using gdb using python2.4
and Fedora Core 5 and received:

(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread -1209063760 (LWP 2024)]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[New Thread -1212232800 (LWP 2027)]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
---Type <return> to continue, or q <return> to quit---
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1209063760 (LWP 2024)]
0x001519ce in TkUndoSetDepth () from /usr/lib/libtk8.4.so
(gdb) 


I ran the same program using python2.5a2 and again
received:

Starting program: /usr/local/bin/python
~/temp/rope/rope/rope.py
Reading symbols from shared object read from target
memory...done.
Loaded system supplied DSO at 0xa05000
[Thread debugging using libthread_db enabled]
[New Thread -1208899920 (LWP 2415)]
[New Thread -1212068960 (LWP 2418)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1208899920 (LWP 2415)]
0x001519ce in TkUndoSetDepth () from /usr/lib/libtk8.4.so
(gdb)


Are these information enough for fixing the problem or
should I send my program?

Thanks


----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-05-20 08:26

Message:
Logged In: YES 
user_id=21627

Closing it as "3rd party", then.

----------------------------------------------------------------------

Comment By: Ali Gholami Rudi (aligrudi)
Date: 2006-05-20 08:08

Message:
Logged In: YES 
user_id=965314

When I complied Tk/Tcl myself the problem was solved. I
think the built rpm that comes with Fedora5 has problems.

Thanks 

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-05-02 08:27

Message:
Logged In: YES 
user_id=21627

Apparently, this has something to do with the undo mechanism
of the text widget; I would expect the problem to go away if
you disable undo (text["undo"]=0). Other than that, there is
not much I can tell, from either looking at the source or at
the backtrace.

Most likely, it is some bug in Tcl/Tk. It also could be that
Python is corrupting memory somehow, and that this causes Tk
to crash.

If you want to debug this yourself, compile Tcl/Tk (with,
say, --prefix==/var/tmp). Use --disable-shared
--enable-symbols for both Tcl and Tk, then edit
Modules/Setup to statically link _tkinter into the Python
interpreter. Replace the -ltk8.2 line with an explict
/var/tmp/lib/libtk8.4g.a, to be sure that your version of tk
is used.

Then run it in a debugger, and find out why it crashes. Is
it really crashing inside TkUndoSetDepth? If so, what is the
value of stack? What is the value of maxdepth? What is the
Tcl command being executed (if Tcl_Eval is on the stack, go
up several times, and print the value of its string argument).

----------------------------------------------------------------------

Comment By: Ali Gholami Rudi (aligrudi)
Date: 2006-05-02 07:25

Message:
Logged In: YES 
user_id=965314

I don't know when the segmentation fault occurs. So I can't
write
a test case to reproduce it. That is when I work with my
program(which
is attached) after a some time(a few minutes or a few hours)
I receive
SIGSEGV.

I did not compile Tcl/Tk. And I used the default
configuration for
compiling Python2.5a2. The 'import sys; print
sys.maxunicode;' prints
65535 in both Python versions I've used.


Python 2.4.2
------------
Python 2.4.2 (#1, Feb 12 2006, 03:59:46) 
[GCC 4.1.0 20060210 (Red Hat 4.1.0-0.24)] on linux2

<<<gdb output start>>>
GNU gdb Red Hat Linux (6.3.0.0-1.122rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public
License, and you are
welcome to change it and/or distribute copies of it under
certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show
warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...(no
debugging symbols found)
Using host libthread_db library "/lib/libthread_db.so.1".

(gdb) run ~/temp/rope/rope/rope.py 
Starting program: /usr/bin/python2.4 ~/temp/rope/rope/rope.py
Reading symbols from shared object read from target
memory...(no debugging symbols found)...done.
Loaded system supplied DSO at 0x8a8000
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread -1208494416 (LWP 2121)]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[New Thread -1211663456 (LWP 2124)]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1208494416 (LWP 2121)]
0x0099e9ce in TkUndoSetDepth () from /usr/lib/libtk8.4.so
(gdb) bt
#0  0x0099e9ce in TkUndoSetDepth () from /usr/lib/libtk8.4.so
#1  0x0099eac9 in TkUndoInsertUndoSeparator () from
/usr/lib/libtk8.4.so
#2  0x009f7208 in TkTextLostSelection () from
/usr/lib/libtk8.4.so
#3  0x0017fc7e in TclInvokeStringCommand () from
/usr/lib/libtcl8.4.so
#4  0x001815e4 in TclEvalObjvInternal () from
/usr/lib/libtcl8.4.so
#5  0x001ae2aa in Tcl_ExprObj () from /usr/lib/libtcl8.4.so
#6  0x001b218c in TclCompEvalObj () from /usr/lib/libtcl8.4.so
#7  0x001df09c in TclObjInterpProc () from /usr/lib/libtcl8.4.so
#8  0x001815e4 in TclEvalObjvInternal () from
/usr/lib/libtcl8.4.so
#9  0x00181b8f in Tcl_EvalEx () from /usr/lib/libtcl8.4.so
#10 0x00181e9c in Tcl_Eval () from /usr/lib/libtcl8.4.so
#11 0x00181f36 in Tcl_GlobalEval () from /usr/lib/libtcl8.4.so
#12 0x0097a9d9 in Tk_BindEvent () from /usr/lib/libtk8.4.so
#13 0x00980414 in TkBindEventProc () from /usr/lib/libtk8.4.so
#14 0x00985cbf in Tk_HandleEvent () from /usr/lib/libtk8.4.so
#15 0x009862db in Tk_HandleEvent () from /usr/lib/libtk8.4.so
#16 0x001d4267 in Tcl_ServiceEvent () from /usr/lib/libtcl8.4.so
#17 0x001d4537 in Tcl_DoOneEvent () from /usr/lib/libtcl8.4.so
#18 0x00114c6c in init_tkinter () from
/usr/lib/python2.4/lib-dynload/_tkinter.so
#19 0x007da92d in PyCFunction_Call () from
/usr/lib/libpython2.4.so.1.0
#20 0x00815646 in PyEval_EvalFrame () from
/usr/lib/libpython2.4.so.1.0
#21 0x008162c6 in PyEval_EvalCodeEx () from
/usr/lib/libpython2.4.so.1.0
#22 0x00814950 in PyEval_EvalFrame () from
/usr/lib/libpython2.4.so.1.0
#23 0x008151d7 in PyEval_EvalFrame () from
/usr/lib/libpython2.4.so.1.0
#24 0x008162c6 in PyEval_EvalCodeEx () from
/usr/lib/libpython2.4.so.1.0
#25 0x00816353 in PyEval_EvalCode () from
/usr/lib/libpython2.4.so.1.0
#26 0x00832f78 in Py_CompileString () from
/usr/lib/libpython2.4.so.1.0
#27 0x00834688 in PyRun_SimpleFileExFlags () from
/usr/lib/libpython2.4.so.1.0
#28 0x00834d6a in PyRun_AnyFileExFlags () from
/usr/lib/libpython2.4.so.1.0
#29 0x0083b45f in Py_Main () from /usr/lib/libpython2.4.so.1.0
#30 0x080485b2 in main ()
(gdb) 
<<<gdb output end>>>



Python 2.5a2
------------
Python 2.5a2 (r25a2:45740, Apr 29 2006, 18:39:09) 
[GCC 4.1.0 20060304 (Red Hat 4.1.0-3)] on linux2

<<<gdb output start>>>
GNU gdb Red Hat Linux (6.3.0.0-1.122rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public
License, and you are
welcome to change it and/or distribute copies of it under
certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show
warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...Using
host libthread_db library "/lib/libthread_db.so.1".

(gdb) run ~/temp/rope/rope/rope.py 
Starting program: /usr/local/bin/python ~/temp/rope/rope/rope.py
Reading symbols from shared object read from target
memory...done.
Loaded system supplied DSO at 0x4c6000
[Thread debugging using libthread_db enabled]
[New Thread -1208731984 (LWP 2176)]
[New Thread -1211835488 (LWP 2179)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1208731984 (LWP 2176)]
0x0099e9ce in TkUndoSetDepth () from /usr/lib/libtk8.4.so
(gdb) bt
#0  0x0099e9ce in TkUndoSetDepth () from /usr/lib/libtk8.4.so
#1  0x0099eac9 in TkUndoInsertUndoSeparator () from
/usr/lib/libtk8.4.so
#2  0x009f75e7 in TkTextLostSelection () from
/usr/lib/libtk8.4.so
#3  0x0013bc7e in TclInvokeStringCommand () from
/usr/lib/libtcl8.4.so
#4  0x0013d5e4 in TclEvalObjvInternal () from
/usr/lib/libtcl8.4.so
#5  0x0013e59b in Tcl_EvalObjv () from /usr/lib/libtcl8.4.so
#6  0x00118606 in Tkapp_Call (_self=0xb71d4640, args=0xb72337d4)
    at /dev/shm/Python-2.5a2/Modules/_tkinter.c:1324
#7  0x080bc0b2 in PyEval_EvalFrameEx (f=0x89c4a0c,
throwflag=0) at Python/ceval.c:3534
#8  0x080bd807 in PyEval_EvalCodeEx (co=0xb7c627e0,
globals=0xb7ed39bc, locals=0x0, 
    args=0x89c48ac, argcount=2, kws=0x89c48b4, kwcount=0,
defs=0x0, defcount=0, closure=0x0)
    at Python/ceval.c:2809
#9  0x080bb884 in PyEval_EvalFrameEx (f=0x89c475c,
throwflag=0) at Python/ceval.c:3630
#10 0x080bcac5 in PyEval_EvalFrameEx (f=0x8a41fd4,
throwflag=0) at Python/ceval.c:3619
#11 0x080bcac5 in PyEval_EvalFrameEx (f=0x87c931c,
throwflag=0) at Python/ceval.c:3619
#12 0x080bcac5 in PyEval_EvalFrameEx (f=0x87b1ee4,
throwflag=0) at Python/ceval.c:3619
#13 0x080bcac5 in PyEval_EvalFrameEx (f=0x89a0a24,
throwflag=0) at Python/ceval.c:3619
#14 0x080bd807 in PyEval_EvalCodeEx (co=0xb7ecff60,
globals=0xb7ed38ac, locals=0x0, 
    args=0xb71e4258, argcount=1, kws=0x0, kwcount=0,
defs=0x0, defcount=0, closure=0xb71e2f8c)
    at Python/ceval.c:2809
#15 0x081044f1 in function_call (func=0xb71a8374,
arg=0xb71e424c, kw=0x0)
    at Objects/funcobject.c:517
#16 0x08059c77 in PyObject_Call (func=0xb71a8374,
arg=0xb71e424c, kw=0x0)
    at Objects/abstract.c:1792
#17 0x080ba663 in PyEval_EvalFrameEx (f=0x87e732c,
throwflag=0) at Python/ceval.c:3814
#18 0x080bd807 in PyEval_EvalCodeEx (co=0xb7ef90a0,
globals=0xb7ed39bc, locals=0x0, 
    args=0xb723e310, argcount=20, kws=0x0, kwcount=0,
defs=0x0, defcount=0, closure=0x0)
    at Python/ceval.c:2809
#19 0x081044f1 in function_call (func=0xb7c76b54,
arg=0xb723e304, kw=0x0)
    at Objects/funcobject.c:517
#20 0x08059c77 in PyObject_Call (func=0xb7c76b54,
arg=0xb723e304, kw=0x0)
    at Objects/abstract.c:1792
#21 0x0805f847 in instancemethod_call (func=0xb71a78ec,
arg=0xb723e304, kw=0x0)
    at Objects/classobject.c:2421
#22 0x08059c77 in PyObject_Call (func=0xb71a78ec,
arg=0xb7f0a9ec, kw=0x0)
    at Objects/abstract.c:1792
#23 0x080b5aac in PyEval_CallObjectWithKeywords
(func=0xb71a78ec, arg=0xb7f0a9ec, kw=0x0)
---Type <return> to continue, or q <return> to quit---
    at Python/ceval.c:3403
#24 0x001171b2 in PythonCmd (clientData=0x8b84960,
interp=0x87a2080, argc=20, argv=0x8cf1f78)
    at /dev/shm/Python-2.5a2/Modules/_tkinter.c:2011
#25 0x0013bc7e in TclInvokeStringCommand () from
/usr/lib/libtcl8.4.so
#26 0x0013d5e4 in TclEvalObjvInternal () from
/usr/lib/libtcl8.4.so
#27 0x0016a2aa in Tcl_ExprObj () from /usr/lib/libtcl8.4.so
#28 0x001674cd in Tcl_ExprObj () from /usr/lib/libtcl8.4.so
#29 0x0013ce63 in Tcl_ExprBooleanObj () from
/usr/lib/libtcl8.4.so
#30 0x0014b072 in Tcl_IfObjCmd () from /usr/lib/libtcl8.4.so
#31 0x0013d5e4 in TclEvalObjvInternal () from
/usr/lib/libtcl8.4.so
#32 0x0013db8f in Tcl_EvalEx () from /usr/lib/libtcl8.4.so
#33 0x0013de9c in Tcl_Eval () from /usr/lib/libtcl8.4.so
#34 0x0013df36 in Tcl_GlobalEval () from /usr/lib/libtcl8.4.so
#35 0x0097a9d9 in Tk_BindEvent () from /usr/lib/libtk8.4.so
#36 0x00980414 in TkBindEventProc () from /usr/lib/libtk8.4.so
#37 0x00985cbf in Tk_HandleEvent () from /usr/lib/libtk8.4.so
#38 0x009862db in Tk_HandleEvent () from /usr/lib/libtk8.4.so
#39 0x00190267 in Tcl_ServiceEvent () from /usr/lib/libtcl8.4.so
#40 0x00190537 in Tcl_DoOneEvent () from /usr/lib/libtcl8.4.so
#41 0x00116eca in Tkapp_MainLoop (_self=0xb71d4640,
args=0xb7ed690c)
    at /dev/shm/Python-2.5a2/Modules/_tkinter.c:2542
#42 0x080bc0b2 in PyEval_EvalFrameEx (f=0x8752afc,
throwflag=0) at Python/ceval.c:3534
#43 0x080bd807 in PyEval_EvalCodeEx (co=0xb7ef1520,
globals=0xb7ed39bc, locals=0x0, 
    args=0x8741154, argcount=1, kws=0x8741158, kwcount=0,
defs=0xb7c74df8, defcount=1, closure=0x0)
    at Python/ceval.c:2809
#44 0x080bb884 in PyEval_EvalFrameEx (f=0x8741004,
throwflag=0) at Python/ceval.c:3630
#45 0x080bcac5 in PyEval_EvalFrameEx (f=0x873d0c4,
throwflag=0) at Python/ceval.c:3619
#46 0x080bd807 in PyEval_EvalCodeEx (co=0xb7ecbba0,
globals=0xb7f20934, locals=0xb7f20934, 
    args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0,
defcount=0, closure=0x0)
    at Python/ceval.c:2809
#47 0x080bd877 in PyEval_EvalCode (co=0xb7ecbba0,
globals=0xb7f20934, locals=0xb7f20934)
    at Python/ceval.c:491
#48 0x080dbc2e in PyRun_FileExFlags (fp=0x870b008, 
    filename=0xbfa51aae "/home/ali/temp/rope/rope/rope.py",
start=257, globals=0xb7f20934, 
    locals=0xb7f20934, closeit=1, flags=0xbfa51538) at
Python/pythonrun.c:1224
#49 0x080dbed7 in PyRun_SimpleFileExFlags (fp=0x870b008, 
    filename=0xbfa51aae "/home/ali/temp/rope/rope/rope.py",
closeit=1, flags=0xbfa51538)
---Type <return> to continue, or q <return> to quit---
    at Python/pythonrun.c:854
#50 0x08056934 in Py_Main (argc=1, argv=0xbfa51604) at
Modules/main.c:492
#51 0x08055f02 in main (argc=Cannot access memory at address
0x13
) at ./Modules/python.c:23
(gdb) 
<<<gdb output end>>>


The attached program, using which I encounter the above
problem, is 
rope<http://sf.net/project/rope/>. The editor is in
'rope/editor.py' module.


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-05-01 09:25

Message:
Logged In: YES 
user_id=33168

If you can send a small test case that would be great. 
Also, can you attach the backtrace (bt command in gdb)?

How did you configure python?  Did you use an
--enable-unicode or --enable-threads?  Did you built Tcl/Tk
or are you using the default version with FC5?

When python starts up, what do you see?  It should be
something like:

Python 2.5a2 (trunk:45831M, Apr 30 2006, 23:27:02) 
[GCC 4.0.0 20041026 (Apple Computer, Inc. build 4061)] on darwin


Also, what does this print:  
    import sys ; print sys.maxunicode

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-05-01 08:34

Message:
Logged In: YES 
user_id=21627

Please do send your program, or better yet a small test case
that allows to reproduce the problem. It looks like a Tk bug
at first glance, in TkUndoSetDepth.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1479586&group_id=5470

From noreply at sourceforge.net  Sat May 20 08:31:14 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 19 May 2006 23:31:14 -0700
Subject: [ python-Bugs-1491574 ] distutils adds (unwanted) -xcode=pic32 in the
	compile comman
Message-ID: <E1FhKza-0004Rd-5T@sc8-sf-web1.sourceforge.net>

Bugs item #1491574, was opened at 2006-05-19 15:04
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1491574&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: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Toon Knapen (tknapen)
Assigned to: Nobody/Anonymous (nobody)
Summary: distutils adds (unwanted) -xcode=pic32 in the compile comman

Initial Comment:
After configuring, making and make installing the
svn-trunk version with sunstudio11 on a Solaris 9 box,
an extra '-xcode=pic32' argument is added to the
compile-command when I try to install numarray using
the setup.py that comes with numarray.

To configure python I first executed:

export CC=cc
export CFLAGS="-xarch=v9" # to force 64bit compilation
export EXTRA_CFLAGS="-xarch=v9" # 
export CXX=CC
export CXXFLAGS="-xarch=v9"
export F77=f77
export FFLAGS="-xarch=v9"
export LDFLAGS="-xarch=v9"

Note that EXTRA_CFLAGS needs to be defined too,
otherwise python itself will not be compiled with the
-xarch=v9 option.

Afterwards I want to install numarray using the
setup.py (`python setup.py install` command). During
compilation of numarray I can however see that
distutils is adding -xcode=pic32 on the command-line.
Afterwards distutils is not able to link because there
now is a mix of 32bit and 64bit code.


----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-05-20 08:31

Message:
Logged In: YES 
user_id=21627

You must be misunderstanding something. -xcode=pic32 does
*not* mean that the code ought to be compiled for the 32-bit
processor mode. Instead, it means that the PIC (position
independent code) offsets are encoded using 32-bit numbers,
which works for both 32-bit and 64-bit code as long as the
size of the code does not exceed 4GiB.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1491574&group_id=5470

From noreply at sourceforge.net  Sat May 20 09:00:14 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 20 May 2006 00:00:14 -0700
Subject: [ python-Bugs-1489051 ] keyword and topic help broken in Pythonwin IDE
Message-ID: <E1FhLRe-0004Fi-Co@sc8-sf-web3.sourceforge.net>

Bugs item #1489051, was opened at 2006-05-15 11:46
Message generated for change (Comment added) made by josiahcarlson
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1489051&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: BartlebyScrivener (bscrivener)
Assigned to: Nobody/Anonymous (nobody)
Summary: keyword and topic help broken in Pythonwin IDE

Initial Comment:
Using ActivePython 2.4.3 on Windows XP

While in the Pythonwin IDE, if I seek keyword help by
issuing the following command:

>>>help ('while')

I get:

Sorry, topic and keyword documentation is not available
because the Python HTML documentation files could not
be found.  If you have installed them, please set the
environment variable PYTHONDOCS to
indicate their location.

My PYTHONDOCS variable is set to:

c:\python24\Doc\Python-Docs-2.4.2\ref

which appears to be correct (ie the help html files are
installed
there).

Searching this group, I found someone else complaining
about the same behavior with no clear resolution.

http://tinyurl.com/pblev

See also

http://tinyurl.com/mbokp

----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-05-20 00:00

Message:
Logged In: YES 
user_id=341410

Since you are using the Pythonwin IDE, which was written and
is supported by Mark Hammond via the pywin32 project,
perhaps you should be visiting his project page instead:
http://sf.net/projects/pywin32

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1489051&group_id=5470

From noreply at sourceforge.net  Sat May 20 15:32:42 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 20 May 2006 06:32:42 -0700
Subject: [ python-Bugs-1000914 ] Carbon.CF.CFMutableArray hangs interpreter
Message-ID: <E1FhRZS-0001UL-Eu@sc8-sf-web3.sourceforge.net>

Bugs item #1000914, was opened at 2004-07-30 22:18
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1000914&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Macintosh
Group: Python 2.4
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Jack Jansen (jackjansen)
Summary: Carbon.CF.CFMutableArray hangs interpreter

Initial Comment:
$ /opt/python2.4/bin/python
Python 2.4a1+ (#1, Jul 30 2004, 20:22:17) 
[GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin
Type "help", "copyright", "credits" or "license" for more 
information.
>>> from Carbon.CF import *
>>> c = CFArrayCreateMutable(0)
>>> isinstance(c, CFMutableArrayRef)
True
>>> del c

The interpreter hangs after deleting c. This also happens when the 
call to isinstance is left out.

----------------------------------------------------------------------

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-05-20 15:32

Message:
Logged In: YES 
user_id=580910

I've just fixed it again in the trunk, and the bug is present in 2.4.3 as wel. Very 
strange...

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2004-08-15 14:47

Message:
Logged In: YES 
user_id=580910

Yup, the issue is no longer there.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2004-08-14 21:58

Message:
Logged In: YES 
user_id=45365

Ronald,
I think I fixed this in CVS just before my holidays. Could you please 
check?

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2004-08-07 18:14

Message:
Logged In: YES 
user_id=580910

It's infinite recursion...

- CF.CFMutableArrayRef has is a subtype of CF.CFArrayRef
- Both tp_del's call 'self->ob_type->tp_base->tp_dealloc' to deallocate
   the instance.
- When the instance is an CFMutableArrayRef self->ob_type->tp_base
   is CFArrayRef, which means we get:

1. Object refcount is 0, call tp_dealloc
2. Enter CFMutableArrayRefObj_dealloc
3. Call self->ob_type->tp_dealloc
4. Enter CFArrayRefObj_dealloc
5. Call self->ob_type->tp_dealloc
6. Enter CFArrayRefObj_dealloc
7. ...

I guess the right change is in Tools/bgen/bgen/bgenObjectDefinition.py:
outputDealloc.

Near line 138 this prints the problematic 'self->ob_type->tp_base-
>tp_dealloc'. I'd change this to:

    Output("%s.tp_dealloc((PyObject*)self);"%(self.basetype,))


----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2004-07-30 22:27

Message:
Logged In: YES 
user_id=580910

when I use gdb to check where the program hangs I always end up in 
CFArrayRefObj_dealloc. This also happens when I continue to program 
and break again later on.

It doesn't seem to be infinite recursion, the stack is 8 levels deep with 
the code mentioned earlier.

However:
(gdb) where
#0  0x00551f98 in CFArrayRefObj_dealloc (self=0x37f0e0) at /Volumes/
Data/Users/ronald/Software/python-HEAD/dist/src/Mac/Modules/cf/
_CFmodule.c:525
#1  0x0008879c in PyEval_EvalFrame (f=0x60d820) at Python/ceval.c:
1662
#2  0x0008a4bc in PyEval_EvalCodeEx (co=0x2, globals=0x59e54, 
locals=0x552308, args=0x16c, argcount=6312944, kws=0x874a0, 
kwcount=1, defs=0x60d96c, defcount=0, closure=0x0) at Python/
ceval.c:2697
#3  0x0008d648 in PyEval_EvalCode (co=0x37f0e0, globals=0x59e54, 
locals=0x55e1d4) at Python/ceval.c:448
#4  0x0000c9a0 in run_node (n=0x16c, filename=0x59e54 "\201^", 
globals=0x2, locals=0x60d96c, flags=0x0) at Python/pythonrun.c:1255
#5  0x0000c128 in PyRun_SimpleFileExFlags (fp=0xa0009818, 
filename=0xbffffc9e "t.py", closeit=6346784, flags=0x377a92) at Python/
pythonrun.c:850
#6  0x00006328 in Py_Main (argc=3533392, argv=0xbffffc9e) at 
Modules/main.c:413
#7  0x00001ee4 in _start (argc=3533392, argv=0xa0009818, 
envp=0xbffffc9e) at /SourceCache/Csu/Csu-46/crt.c:267
#8  0x00001d58 in start ()
(gdb) p self
$3 = (CFArrayRefObject *) 0x37f0e0
(gdb) p *self
$4 = {
  ob_refcnt = 0, 
  ob_type = 0x55e2e4, 
  ob_itself = 0x0, 
  ob_freeit = 0x90190b98 <CFRelease>
}
(gdb) p self->ob_type->tp_base
$5 = (struct _typeobject *) 0x55e1d4
(gdb) p self->ob_type->tp_base->tp_dealloc
$6 = 0x551f48 <CFArrayRefObj_dealloc>
(gdb) 

And CFArrayRefObj_dealloc is:

static void CFArrayRefObj_dealloc(CFArrayRefObject *self)
{
        if (self->ob_freeit && self->ob_itself)
        {
                self->ob_freeit((CFTypeRef)self->ob_itself);
                self->ob_itself = NULL;
        }
        self->ob_type->tp_base->tp_dealloc((PyObject *)self);
}

BTW: Python 2.4a1+ from anon-CVS as of today, running on OSX 10.3.4 
with Xcode 1.2 (gcc 3.3)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1000914&group_id=5470

From noreply at sourceforge.net  Sun May 21 02:34:04 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 20 May 2006 17:34:04 -0700
Subject: [ python-Bugs-1492293 ] Wierd Floating Point on FreeBSD4 
Message-ID: <E1FhbtU-0006dy-Fn@sc8-sf-web3.sourceforge.net>

Bugs item #1492293, was opened at 2006-05-20 19:34
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=1492293&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: David Abrahams (david_abrahams)
Assigned to: Nobody/Anonymous (nobody)
Summary: Wierd Floating Point on FreeBSD4 

Initial Comment:
This is just about the weirdest thing I've ever seen.
Python 2.4.2 (#1, Jan 17 2006, 09:30:19)
[GCC 2.95.2 19991024 (release)] on freebsd4

    ---- nan.py ----
    inf = 1e300000
    nan = inf/inf
    print nan
    ---- nan.py ----


    ---- tst.py ----
    import nan
    ---- tst.py ----

    % python -c "import nan"
    NaN

    % python -c "import tst"  
    NaN

Now I edit tst.py

    ---- tst.py ----
    #
    import nan
    ---- tst.py ----

    % python -c "import nan"
    Traceback (most recent call last):
      File "<string>", line 1, in ?
      File "nan.py", line 2, in ?
        nan = inf/inf
    ZeroDivisionError: float division

    % python -c "import tst"  
    Traceback (most recent call last):
      File "<string>", line 1, in ?
      File "tst.py", line 1, in ?
        import nan
      File "nan.py", line 2, in ?
        nan = inf/inf
    ZeroDivisionError: float division

    % rm *.pyc

    % python -c "import tst"  
    NaN

    % python -c "import nan"
    Traceback (most recent call last):
      File "<string>", line 1, in ?
      File "nan.py", line 2, in ?
        nan = inf/inf
    ZeroDivisionError: float division

    % python -c "import tst"  
    Traceback (most recent call last):
      File "<string>", line 1, in ?
      File "tst.py", line 1, in ?
        import nan
      File "nan.py", line 2, in ?
        nan = inf/inf
    ZeroDivisionError: float division


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1492293&group_id=5470

From noreply at sourceforge.net  Sun May 21 02:51:12 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 20 May 2006 17:51:12 -0700
Subject: [ python-Bugs-1489051 ] keyword and topic help broken in Pythonwin IDE
Message-ID: <E1FhcA4-00076a-Jm@sc8-sf-web3.sourceforge.net>

Bugs item #1489051, was opened at 2006-05-15 18:46
Message generated for change (Comment added) made by bscrivener
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1489051&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: BartlebyScrivener (bscrivener)
Assigned to: Nobody/Anonymous (nobody)
Summary: keyword and topic help broken in Pythonwin IDE

Initial Comment:
Using ActivePython 2.4.3 on Windows XP

While in the Pythonwin IDE, if I seek keyword help by
issuing the following command:

>>>help ('while')

I get:

Sorry, topic and keyword documentation is not available
because the Python HTML documentation files could not
be found.  If you have installed them, please set the
environment variable PYTHONDOCS to
indicate their location.

My PYTHONDOCS variable is set to:

c:\python24\Doc\Python-Docs-2.4.2\ref

which appears to be correct (ie the help html files are
installed
there).

Searching this group, I found someone else complaining
about the same behavior with no clear resolution.

http://tinyurl.com/pblev

See also

http://tinyurl.com/mbokp

----------------------------------------------------------------------

>Comment By: BartlebyScrivener (bscrivener)
Date: 2006-05-21 00:51

Message:
Logged In: YES 
user_id=1523094

help('topic') or help('keyword') doesn't work in IDLE or
Pythonwin IDE



----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-05-20 07:00

Message:
Logged In: YES 
user_id=341410

Since you are using the Pythonwin IDE, which was written and
is supported by Mark Hammond via the pywin32 project,
perhaps you should be visiting his project page instead:
http://sf.net/projects/pywin32

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1489051&group_id=5470

From noreply at sourceforge.net  Sun May 21 16:38:23 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 21 May 2006 07:38:23 -0700
Subject: [ python-Bugs-1464056 ] curses library in python 2.4.3 broken
Message-ID: <E1Fhp4Z-0004Qy-RY@sc8-sf-web2.sourceforge.net>

Bugs item #1464056, was opened at 2006-04-04 18:17
Message generated for change (Comment added) made by psmedley
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464056&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: nomind (vnainar)
Assigned to: Nobody/Anonymous (nobody)
Summary: curses library in python 2.4.3 broken

Initial Comment:
My python programs using curses  library do not work
with version 2.4.3.Even the 'ncurses.py ' demo program
in the Demo/curses directory does not work correctly.
The problem seems to be in the 'panels' library


----------------------------------------------------------------------

Comment By: Paul Smedley (psmedley)
Date: 2006-05-22 00:08

Message:
Logged In: YES 
user_id=1359962

I have a similar problem on OS/2.  When running any script
that uses curses I get:
[U:\dev\Python-2.4.3\PC\os2emx]python test_curses.py
Traceback (most recent call last):
  File "test_curses.py", line 242, in ?
    curses.wrapper(main)
  File "U:/DEV/PYTHON-2.4.3/Lib/curses/wrapper.py", line 49,
in wrapper
    curses.nocbreak()
_curses.error: nocbreak() returned ERR

If I remove the reference to nocbreak() from wrapper.py, I
get the same error but in endwin(), removing endwin() from
wrapper.py, I get an error in cbreak(), removing cbreak()
then some scripts work.

For example, from the demo folder, all work exceptlife.py &
xmas.py, which both return an error "_curses.error:
nocbreak() returned ERR" on various line numbers.

Seems certain curses functions are working correctly, others
aren't.

The patch in this bug does NOT make any difference here.

----------------------------------------------------------------------

Comment By: Jan Palus (atler_)
Date: 2006-04-18 04:20

Message:
Logged In: YES 
user_id=1497957

/me confirms

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-16 01:00

Message:
Logged In: YES 
user_id=21627

Good spotting! Can everybody please confirm that the
attached patch fixes the problem?

----------------------------------------------------------------------

Comment By: Jan Palus (atler_)
Date: 2006-04-16 00:18

Message:
Logged In: YES 
user_id=1497957

Half day of debugging and it seems that I found an answer...
just by accident ;).

When curses module is linked against ncursesw it seems that
it also should be linked against panelw not plain panel.
After changing this in setup.py, ncurses.py demo finally
runs fine.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-15 16:35

Message:
Logged In: YES 
user_id=21627

I couldn't reproduce the problem on a Linux console
(although my console had a different size); so it remains
unreproducable for me.

----------------------------------------------------------------------

Comment By: nomind (vnainar)
Date: 2006-04-13 20:30

Message:
Logged In: YES 
user_id=1493752

Well ,  it is the linux console (in VGA mode ).
The local is en_US.The size of the console is
100X37.



----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-11 15:02

Message:
Logged In: YES 
user_id=21627

Ah, ok. vnainar, atler_: What terminal had you been using to
make it crash? What is your locale? Any other conditions
that might be relevant (e.g. dimension of the terminal)?

----------------------------------------------------------------------

Comment By: nomind (vnainar)
Date: 2006-04-11 14:43

Message:
Logged In: YES 
user_id=1493752

Removing 'ncursesw' (there are two references  to it in
'setup.py') seems to solve the problem. I noticed one more
oddity. Even before the above recompilation , it  ran fine
on an Xterm !


----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-11 07:58

Message:
Logged In: YES 
user_id=21627

That's hard to tell. Somebody would have to debug ncurses to
find out why it crashes. Notice that it crashes only on some
installations, so it is likely rather a problem with your
ncurses installation, than with Python (or even with ncurses
itself).

----------------------------------------------------------------------

Comment By: Jan Palus (atler_)
Date: 2006-04-11 06:54

Message:
Logged In: YES 
user_id=1497957

loewis: removing lines refering to ncursesw solves the
problem. ncurses.py runs fine as well as other programs.

What is actual problem then? Something with ncursesw or
with python?

Anyway, Thanks for your help.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-10 06:28

Message:
Logged In: YES 
user_id=21627

atler_: around line 427, you find

            if self.compiler.find_library_file(lib_dirs,
                                                 'ncursesw'):
                readline_libs.append('ncursesw')
            elif self.compiler.find_library_file(lib_dirs,
                                                 'ncurses'):

Replace that with

            if self.compiler.find_library_file(lib_dirs,
                                                 'ncurses'):

(i.e. dropping the ncursesw part), and rebuild.

----------------------------------------------------------------------

Comment By: Jan Palus (atler_)
Date: 2006-04-09 23:18

Message:
Logged In: YES 
user_id=1497957

More complete backtrace, I hope it will help:
http://pastebin.com/649445

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2006-04-09 21:44

Message:
Logged In: YES 
user_id=29957

The buildbot boxes don't show this problem.

You might need to rebuild a Python with -g and unstripped to
get a useful backtrace.


----------------------------------------------------------------------

Comment By: Jan Palus (atler_)
Date: 2006-04-09 20:21

Message:
Logged In: YES 
user_id=1497957

$ ldd /usr/lib/python2.4/lib-dynload/_curses.so
        libncursesw.so.5 => /usr/lib/libncursesw.so.5
(0x7004c000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x70080000)
        libc.so.6 => /lib/libc.so.6 (0x700e4000)
        libdl.so.2 => /lib/libdl.so.2 (0x70228000)
        libtinfow.so.5 => /usr/lib/libtinfow.so.5 (0x7023c000)
        /lib/ld-linux.so.2 (0x70000000)

...
Program received signal SIGSEGV, Segmentation fault.
0x7063947c in hide_panel () from /usr/lib/libpanel.so.5
gdb) bt
#0  0x7063947c in hide_panel () from /usr/lib/libpanel.so.5
#1  0x706254b8 in ?? () from
/usr/lib/python2.4/lib-dynload/_curses_panel.so
#2  0x706254b8 in ?? () from
/usr/lib/python2.4/lib-dynload/_curses_panel.so
Previous frame identical to this frame (corrupt stack?)

It seems that only programs using panel library cause
segfaults (all other demos run fine except ncurses.py),
sorry for a mistake in a last post.

loewis: I'm not sure I understand second point. What excatly
should be changed in setup.py?

----------------------------------------------------------------------

Comment By: Matt Fleming (splitscreen)
Date: 2006-04-09 20:16

Message:
Logged In: YES 
user_id=1126061

Cannot reproduce on Gentoo. All the files in the Demo/curses
directory run fine.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-09 19:59

Message:
Logged In: YES 
user_id=21627

I can't reproduce any of this on Debian;
Demo/curses/ncurses.py runs fine. Can you please
1. run ldd on _curses.so, and report the output, and
2. edit setup.py, removing the lines that deal with ncursesw,
3. atler_: produce a gdb backtrace on the time of the crash,
4: vnainar: please report what you mean by "does not work".
Does it erase your hard disk? turn off the machine? Paint
things blue instead of red?

----------------------------------------------------------------------

Comment By: Jan Palus (atler_)
Date: 2006-04-09 19:36

Message:
Logged In: YES 
user_id=1497957

I confirm the problem. Every program using curses library
segfaults and there's only one error before it happens:

...
import curses # directory /usr/share/python2.4/curses
import curses # precompiled from
/usr/share/python2.4/curses/__init__.pyc
dlopen("/usr/lib/python2.4/lib-dynload/_curses.so", 2);
import _curses # dynamically loaded from
/usr/lib/python2.4/lib-dynload/_curses.so
import curses.wrapper # precompiled from
/usr/share/python2.4/curses/wrapper.pyc
import curses.panel # precompiled from
/usr/share/python2.4/curses/panel.pyc
dlopen("/usr/lib/python2.4/lib-dynload/_curses_panel.so", 2);
import _curses_panel # dynamically loaded from
/usr/lib/python2.4/lib-dynload/_curses_panel.so
Traceback (most recent call last):
  File "ncurses.py", line 273, in ?
    curses.wrapper(demo_panels)
  File "/usr/share/python2.4/curses/wrapper.py", line 49, in
wrapper
_curses.error: nocbreak() returned ERR

I'm running Linux (PLD) with Python 2.4.3 and ncurses 5.5.
With Python 2.4.2 everything worked fine.

----------------------------------------------------------------------

Comment By: nomind (vnainar)
Date: 2006-04-06 15:08

Message:
Logged In: YES 
user_id=1493752

Sorry my original post was incomplete. I am running
slackware 10.2 (linux kernel 2.6).The python library was
tested with ncurses 5.4 and ncurses 5.5( the latest
release). All  programs run OK with 2.4.1.As I said ,the 
curses demo that comes with the Python distributions runs OK
with 2.4.1 but 
not with 2.4.3 - I have both on my machine


----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-04-05 07:46

Message:
Logged In: YES 
user_id=21627

What do you mean by "do not work"? What operating system and
what curses implementation are you using?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464056&group_id=5470

From noreply at sourceforge.net  Sun May 21 17:09:33 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 21 May 2006 08:09:33 -0700
Subject: [ python-Bugs-1492293 ] Wierd Floating Point on FreeBSD4 
Message-ID: <E1FhpYj-0005k3-UX@sc8-sf-web1.sourceforge.net>

Bugs item #1492293, was opened at 2006-05-20 20:34
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1492293&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: David Abrahams (david_abrahams)
Assigned to: Nobody/Anonymous (nobody)
Summary: Wierd Floating Point on FreeBSD4 

Initial Comment:
This is just about the weirdest thing I've ever seen.
Python 2.4.2 (#1, Jan 17 2006, 09:30:19)
[GCC 2.95.2 19991024 (release)] on freebsd4

    ---- nan.py ----
    inf = 1e300000
    nan = inf/inf
    print nan
    ---- nan.py ----


    ---- tst.py ----
    import nan
    ---- tst.py ----

    % python -c "import nan"
    NaN

    % python -c "import tst"  
    NaN

Now I edit tst.py

    ---- tst.py ----
    #
    import nan
    ---- tst.py ----

    % python -c "import nan"
    Traceback (most recent call last):
      File "<string>", line 1, in ?
      File "nan.py", line 2, in ?
        nan = inf/inf
    ZeroDivisionError: float division

    % python -c "import tst"  
    Traceback (most recent call last):
      File "<string>", line 1, in ?
      File "tst.py", line 1, in ?
        import nan
      File "nan.py", line 2, in ?
        nan = inf/inf
    ZeroDivisionError: float division

    % rm *.pyc

    % python -c "import tst"  
    NaN

    % python -c "import nan"
    Traceback (most recent call last):
      File "<string>", line 1, in ?
      File "nan.py", line 2, in ?
        nan = inf/inf
    ZeroDivisionError: float division

    % python -c "import tst"  
    Traceback (most recent call last):
      File "<string>", line 1, in ?
      File "tst.py", line 1, in ?
        import nan
      File "nan.py", line 2, in ?
        nan = inf/inf
    ZeroDivisionError: float division


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2006-05-21 11:09

Message:
Logged In: YES 
user_id=31435

Python doesn't know anything about IEEE special values, and
in particular what the marshal format (used for code
objects) does with infinities and NaNs is a
platform-dependent accident.

Try changing

inf = 1e300000

to

inf = 1e300 * 1e300

to stop Python from _trying_ to marshal/unmarshal a floating
infinity on that box.  I bet your problems will go away then.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1492293&group_id=5470

From noreply at sourceforge.net  Sun May 21 22:50:44 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 21 May 2006 13:50:44 -0700
Subject: [ python-Bugs-1000914 ] Carbon.CF.CFMutableArray hangs interpreter
Message-ID: <E1Fhusu-0000pz-Fw@sc8-sf-web1.sourceforge.net>

Bugs item #1000914, was opened at 2004-07-30 22:18
Message generated for change (Comment added) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1000914&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Macintosh
Group: Python 2.4
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Jack Jansen (jackjansen)
Summary: Carbon.CF.CFMutableArray hangs interpreter

Initial Comment:
$ /opt/python2.4/bin/python
Python 2.4a1+ (#1, Jul 30 2004, 20:22:17) 
[GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin
Type "help", "copyright", "credits" or "license" for more 
information.
>>> from Carbon.CF import *
>>> c = CFArrayCreateMutable(0)
>>> isinstance(c, CFMutableArrayRef)
True
>>> del c

The interpreter hangs after deleting c. This also happens when the 
call to isinstance is left out.

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2006-05-21 22:50

Message:
Logged In: YES 
user_id=45365

I fixed a number of bugs in bgen the last couple of months, including one that 
had to do with base class destructors not being called. Maybe I re-introduced 
the bug somehow, with those fixes?

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-05-20 15:32

Message:
Logged In: YES 
user_id=580910

I've just fixed it again in the trunk, and the bug is present in 2.4.3 as wel. Very 
strange...

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2004-08-15 14:47

Message:
Logged In: YES 
user_id=580910

Yup, the issue is no longer there.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2004-08-14 21:58

Message:
Logged In: YES 
user_id=45365

Ronald,
I think I fixed this in CVS just before my holidays. Could you please 
check?

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2004-08-07 18:14

Message:
Logged In: YES 
user_id=580910

It's infinite recursion...

- CF.CFMutableArrayRef has is a subtype of CF.CFArrayRef
- Both tp_del's call 'self->ob_type->tp_base->tp_dealloc' to deallocate
   the instance.
- When the instance is an CFMutableArrayRef self->ob_type->tp_base
   is CFArrayRef, which means we get:

1. Object refcount is 0, call tp_dealloc
2. Enter CFMutableArrayRefObj_dealloc
3. Call self->ob_type->tp_dealloc
4. Enter CFArrayRefObj_dealloc
5. Call self->ob_type->tp_dealloc
6. Enter CFArrayRefObj_dealloc
7. ...

I guess the right change is in Tools/bgen/bgen/bgenObjectDefinition.py:
outputDealloc.

Near line 138 this prints the problematic 'self->ob_type->tp_base-
>tp_dealloc'. I'd change this to:

    Output("%s.tp_dealloc((PyObject*)self);"%(self.basetype,))


----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2004-07-30 22:27

Message:
Logged In: YES 
user_id=580910

when I use gdb to check where the program hangs I always end up in 
CFArrayRefObj_dealloc. This also happens when I continue to program 
and break again later on.

It doesn't seem to be infinite recursion, the stack is 8 levels deep with 
the code mentioned earlier.

However:
(gdb) where
#0  0x00551f98 in CFArrayRefObj_dealloc (self=0x37f0e0) at /Volumes/
Data/Users/ronald/Software/python-HEAD/dist/src/Mac/Modules/cf/
_CFmodule.c:525
#1  0x0008879c in PyEval_EvalFrame (f=0x60d820) at Python/ceval.c:
1662
#2  0x0008a4bc in PyEval_EvalCodeEx (co=0x2, globals=0x59e54, 
locals=0x552308, args=0x16c, argcount=6312944, kws=0x874a0, 
kwcount=1, defs=0x60d96c, defcount=0, closure=0x0) at Python/
ceval.c:2697
#3  0x0008d648 in PyEval_EvalCode (co=0x37f0e0, globals=0x59e54, 
locals=0x55e1d4) at Python/ceval.c:448
#4  0x0000c9a0 in run_node (n=0x16c, filename=0x59e54 "\201^", 
globals=0x2, locals=0x60d96c, flags=0x0) at Python/pythonrun.c:1255
#5  0x0000c128 in PyRun_SimpleFileExFlags (fp=0xa0009818, 
filename=0xbffffc9e "t.py", closeit=6346784, flags=0x377a92) at Python/
pythonrun.c:850
#6  0x00006328 in Py_Main (argc=3533392, argv=0xbffffc9e) at 
Modules/main.c:413
#7  0x00001ee4 in _start (argc=3533392, argv=0xa0009818, 
envp=0xbffffc9e) at /SourceCache/Csu/Csu-46/crt.c:267
#8  0x00001d58 in start ()
(gdb) p self
$3 = (CFArrayRefObject *) 0x37f0e0
(gdb) p *self
$4 = {
  ob_refcnt = 0, 
  ob_type = 0x55e2e4, 
  ob_itself = 0x0, 
  ob_freeit = 0x90190b98 <CFRelease>
}
(gdb) p self->ob_type->tp_base
$5 = (struct _typeobject *) 0x55e1d4
(gdb) p self->ob_type->tp_base->tp_dealloc
$6 = 0x551f48 <CFArrayRefObj_dealloc>
(gdb) 

And CFArrayRefObj_dealloc is:

static void CFArrayRefObj_dealloc(CFArrayRefObject *self)
{
        if (self->ob_freeit && self->ob_itself)
        {
                self->ob_freeit((CFTypeRef)self->ob_itself);
                self->ob_itself = NULL;
        }
        self->ob_type->tp_base->tp_dealloc((PyObject *)self);
}

BTW: Python 2.4a1+ from anon-CVS as of today, running on OSX 10.3.4 
with Xcode 1.2 (gcc 3.3)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1000914&group_id=5470

From noreply at sourceforge.net  Mon May 22 01:25:03 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 21 May 2006 16:25:03 -0700
Subject: [ python-Bugs-1472251 ] pdb 'run' crashes when the it's first
	argument is non-string
Message-ID: <E1FhxIF-0005dW-RZ@sc8-sf-web3.sourceforge.net>

Bugs item #1472251, was opened at 2006-04-18 05:16
Message generated for change (Comment added) made by isandler
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472251&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: Kuba Ko??czyk (jakamkon)
Assigned to: Nobody/Anonymous (nobody)
Summary: pdb 'run' crashes when the it's first argument is non-string

Initial Comment:
Pdb 'run/runeval' commands fails to check the type of
given argument.When argument to 'run/runeval' is
non-string the functions crashes with further
impilications on (correctly)invoking this functions: 

Python 2.5a1 (trunk:45527, Apr 18 2006, 11:12:31)

>>> def x(): pass
>>> import pdb
>>> pdb.run(x())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/jkk/python/python-svn/Lib/pdb.py", line
1113, in run
    Pdb().run(statement, globals, locals)
  File "/home/jkk/python/python-svn/Lib/bdb.py", line
363, in run
    cmd = cmd+'\n'
TypeError: unsupported operand type(s) for +:
'NoneType' and 'str'
>>> pdb.run('x()')
> /home/jkk/python/python-svn/Lib/pdb.py(1113)run()
-> Pdb().run(statement, globals, locals)
(Pdb)
# CTRL-D pressed
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/jkk/python/python-svn/Lib/pdb.py", line
1113, in run
    Pdb().run(statement, globals, locals)
  File "/home/jkk/python/python-svn/Lib/pdb.py", line
1113, in run
    Pdb().run(statement, globals, locals)
  File "/home/jkk/python/python-svn/Lib/bdb.py", line
48, in trace_dispatch
    return self.dispatch_line(frame)
  File "/home/jkk/python/python-svn/Lib/bdb.py", line
67, in dispatch_line
    if self.quitting: raise BdbQuit
bdb.BdbQuit

The solution is to simply ensure that the first
argument passed to the 'run/runeval' functions is string.

----------------------------------------------------------------------

Comment By: Ilya Sandler (isandler)
Date: 2006-05-21 16:25

Message:
Logged In: YES 
user_id=971153


I would not classify your example as a crash. You passed a
wrong value (None in your case) into pdb.run() and got back
a TypeError...Isn't it an expected response?

E.g if you do:  >>>max(13)

You'll also get: "TypeError"


Am I missing something? Could you clarify?



----------------------------------------------------------------------

Comment By: Kuba Ko??czyk (jakamkon)
Date: 2006-04-18 05:36

Message:
Logged In: YES 
user_id=1491175

Patch is in #1472257

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472251&group_id=5470

From noreply at sourceforge.net  Mon May 22 11:20:23 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 22 May 2006 02:20:23 -0700
Subject: [ python-Bugs-1472251 ] pdb 'run' crashes when the it's first
	argument is non-string
Message-ID: <E1Fi6aN-0004dG-9k@sc8-sf-web1.sourceforge.net>

Bugs item #1472251, was opened at 2006-04-18 12:16
Message generated for change (Comment added) made by jakamkon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472251&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: Kuba Ko??czyk (jakamkon)
Assigned to: Nobody/Anonymous (nobody)
Summary: pdb 'run' crashes when the it's first argument is non-string

Initial Comment:
Pdb 'run/runeval' commands fails to check the type of
given argument.When argument to 'run/runeval' is
non-string the functions crashes with further
impilications on (correctly)invoking this functions: 

Python 2.5a1 (trunk:45527, Apr 18 2006, 11:12:31)

>>> def x(): pass
>>> import pdb
>>> pdb.run(x())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/jkk/python/python-svn/Lib/pdb.py", line
1113, in run
    Pdb().run(statement, globals, locals)
  File "/home/jkk/python/python-svn/Lib/bdb.py", line
363, in run
    cmd = cmd+'\n'
TypeError: unsupported operand type(s) for +:
'NoneType' and 'str'
>>> pdb.run('x()')
> /home/jkk/python/python-svn/Lib/pdb.py(1113)run()
-> Pdb().run(statement, globals, locals)
(Pdb)
# CTRL-D pressed
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/jkk/python/python-svn/Lib/pdb.py", line
1113, in run
    Pdb().run(statement, globals, locals)
  File "/home/jkk/python/python-svn/Lib/pdb.py", line
1113, in run
    Pdb().run(statement, globals, locals)
  File "/home/jkk/python/python-svn/Lib/bdb.py", line
48, in trace_dispatch
    return self.dispatch_line(frame)
  File "/home/jkk/python/python-svn/Lib/bdb.py", line
67, in dispatch_line
    if self.quitting: raise BdbQuit
bdb.BdbQuit

The solution is to simply ensure that the first
argument passed to the 'run/runeval' functions is string.

----------------------------------------------------------------------

>Comment By: Kuba Ko??czyk (jakamkon)
Date: 2006-05-22 09:20

Message:
Logged In: YES 
user_id=1491175

The point is that when you want to invoke pdb.run correctly
(with string argument) after getting TypeError as in above
example,
your namespace is probably overwritten or deleted so that
you don't have access to previously defined symbols.

>>> def x():pass
>>> import pdb
>>> pdb.run(x())
TypeError
>>> pdb.run('x()')
> /home/jkk/python-svn/Lib/pdb.py(1122)run()
-> Pdb().run(statement, globals, locals)
(Pdb) pdb
*** NameError: name 'pdb' is not defined
(Pdb) x
*** NameError: name 'x' is not defined


----------------------------------------------------------------------

Comment By: Ilya Sandler (isandler)
Date: 2006-05-21 23:25

Message:
Logged In: YES 
user_id=971153


I would not classify your example as a crash. You passed a
wrong value (None in your case) into pdb.run() and got back
a TypeError...Isn't it an expected response?

E.g if you do:  >>>max(13)

You'll also get: "TypeError"


Am I missing something? Could you clarify?



----------------------------------------------------------------------

Comment By: Kuba Ko??czyk (jakamkon)
Date: 2006-04-18 12:36

Message:
Logged In: YES 
user_id=1491175

Patch is in #1472257

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472251&group_id=5470

From noreply at sourceforge.net  Mon May 22 11:32:46 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 22 May 2006 02:32:46 -0700
Subject: [ python-Bugs-1492293 ] Wierd Floating Point on FreeBSD4 
Message-ID: <E1Fi6mM-0000c7-GT@sc8-sf-web2.sourceforge.net>

Bugs item #1492293, was opened at 2006-05-21 02:34
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1492293&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: Invalid
Priority: 5
Submitted By: David Abrahams (david_abrahams)
Assigned to: Nobody/Anonymous (nobody)
Summary: Wierd Floating Point on FreeBSD4 

Initial Comment:
This is just about the weirdest thing I've ever seen.
Python 2.4.2 (#1, Jan 17 2006, 09:30:19)
[GCC 2.95.2 19991024 (release)] on freebsd4

    ---- nan.py ----
    inf = 1e300000
    nan = inf/inf
    print nan
    ---- nan.py ----


    ---- tst.py ----
    import nan
    ---- tst.py ----

    % python -c "import nan"
    NaN

    % python -c "import tst"  
    NaN

Now I edit tst.py

    ---- tst.py ----
    #
    import nan
    ---- tst.py ----

    % python -c "import nan"
    Traceback (most recent call last):
      File "<string>", line 1, in ?
      File "nan.py", line 2, in ?
        nan = inf/inf
    ZeroDivisionError: float division

    % python -c "import tst"  
    Traceback (most recent call last):
      File "<string>", line 1, in ?
      File "tst.py", line 1, in ?
        import nan
      File "nan.py", line 2, in ?
        nan = inf/inf
    ZeroDivisionError: float division

    % rm *.pyc

    % python -c "import tst"  
    NaN

    % python -c "import nan"
    Traceback (most recent call last):
      File "<string>", line 1, in ?
      File "nan.py", line 2, in ?
        nan = inf/inf
    ZeroDivisionError: float division

    % python -c "import tst"  
    Traceback (most recent call last):
      File "<string>", line 1, in ?
      File "tst.py", line 1, in ?
        import nan
      File "nan.py", line 2, in ?
        nan = inf/inf
    ZeroDivisionError: float division


----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-05-22 11:32

Message:
Logged In: YES 
user_id=21627

Closing this as "not a bug". Notice that this judgement is
difficult to make, as the report is incomplete: you report
what you did (good), what happened (good), but not what you
expected to happen, or why you think the behaviour is
incorrect - only that it is "weird". As Tim mentioned
indirectly, this is intentional.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-05-21 17:09

Message:
Logged In: YES 
user_id=31435

Python doesn't know anything about IEEE special values, and
in particular what the marshal format (used for code
objects) does with infinities and NaNs is a
platform-dependent accident.

Try changing

inf = 1e300000

to

inf = 1e300 * 1e300

to stop Python from _trying_ to marshal/unmarshal a floating
infinity on that box.  I bet your problems will go away then.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1492293&group_id=5470

From noreply at sourceforge.net  Mon May 22 12:00:07 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 22 May 2006 03:00:07 -0700
Subject: [ python-Bugs-1492293 ] Wierd Floating Point on FreeBSD4 
Message-ID: <E1Fi7Cp-0003ly-KJ@sc8-sf-web4-b.sourceforge.net>

Bugs item #1492293, was opened at 2006-05-21 01:34
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1492293&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: Invalid
Priority: 5
Submitted By: David Abrahams (david_abrahams)
Assigned to: Nobody/Anonymous (nobody)
Summary: Wierd Floating Point on FreeBSD4 

Initial Comment:
This is just about the weirdest thing I've ever seen.
Python 2.4.2 (#1, Jan 17 2006, 09:30:19)
[GCC 2.95.2 19991024 (release)] on freebsd4

    ---- nan.py ----
    inf = 1e300000
    nan = inf/inf
    print nan
    ---- nan.py ----


    ---- tst.py ----
    import nan
    ---- tst.py ----

    % python -c "import nan"
    NaN

    % python -c "import tst"  
    NaN

Now I edit tst.py

    ---- tst.py ----
    #
    import nan
    ---- tst.py ----

    % python -c "import nan"
    Traceback (most recent call last):
      File "<string>", line 1, in ?
      File "nan.py", line 2, in ?
        nan = inf/inf
    ZeroDivisionError: float division

    % python -c "import tst"  
    Traceback (most recent call last):
      File "<string>", line 1, in ?
      File "tst.py", line 1, in ?
        import nan
      File "nan.py", line 2, in ?
        nan = inf/inf
    ZeroDivisionError: float division

    % rm *.pyc

    % python -c "import tst"  
    NaN

    % python -c "import nan"
    Traceback (most recent call last):
      File "<string>", line 1, in ?
      File "nan.py", line 2, in ?
        nan = inf/inf
    ZeroDivisionError: float division

    % python -c "import tst"  
    Traceback (most recent call last):
      File "<string>", line 1, in ?
      File "tst.py", line 1, in ?
        import nan
      File "nan.py", line 2, in ?
        nan = inf/inf
    ZeroDivisionError: float division


----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2006-05-22 11:00

Message:
Logged In: YES 
user_id=6656

Also, this probably won't be a problem in 2.5.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-05-22 10:32

Message:
Logged In: YES 
user_id=21627

Closing this as "not a bug". Notice that this judgement is
difficult to make, as the report is incomplete: you report
what you did (good), what happened (good), but not what you
expected to happen, or why you think the behaviour is
incorrect - only that it is "weird". As Tim mentioned
indirectly, this is intentional.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-05-21 16:09

Message:
Logged In: YES 
user_id=31435

Python doesn't know anything about IEEE special values, and
in particular what the marshal format (used for code
objects) does with infinities and NaNs is a
platform-dependent accident.

Try changing

inf = 1e300000

to

inf = 1e300 * 1e300

to stop Python from _trying_ to marshal/unmarshal a floating
infinity on that box.  I bet your problems will go away then.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1492293&group_id=5470

From noreply at sourceforge.net  Mon May 22 12:28:27 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 22 May 2006 03:28:27 -0700
Subject: [ python-Bugs-1492293 ] Wierd Floating Point on FreeBSD4 
Message-ID: <E1Fi7eF-0002fN-Qa@sc8-sf-web2.sourceforge.net>

Bugs item #1492293, was opened at 2006-05-20 20:34
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1492293&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: Invalid
Priority: 5
Submitted By: David Abrahams (david_abrahams)
Assigned to: Nobody/Anonymous (nobody)
Summary: Wierd Floating Point on FreeBSD4 

Initial Comment:
This is just about the weirdest thing I've ever seen.
Python 2.4.2 (#1, Jan 17 2006, 09:30:19)
[GCC 2.95.2 19991024 (release)] on freebsd4

    ---- nan.py ----
    inf = 1e300000
    nan = inf/inf
    print nan
    ---- nan.py ----


    ---- tst.py ----
    import nan
    ---- tst.py ----

    % python -c "import nan"
    NaN

    % python -c "import tst"  
    NaN

Now I edit tst.py

    ---- tst.py ----
    #
    import nan
    ---- tst.py ----

    % python -c "import nan"
    Traceback (most recent call last):
      File "<string>", line 1, in ?
      File "nan.py", line 2, in ?
        nan = inf/inf
    ZeroDivisionError: float division

    % python -c "import tst"  
    Traceback (most recent call last):
      File "<string>", line 1, in ?
      File "tst.py", line 1, in ?
        import nan
      File "nan.py", line 2, in ?
        nan = inf/inf
    ZeroDivisionError: float division

    % rm *.pyc

    % python -c "import tst"  
    NaN

    % python -c "import nan"
    Traceback (most recent call last):
      File "<string>", line 1, in ?
      File "nan.py", line 2, in ?
        nan = inf/inf
    ZeroDivisionError: float division

    % python -c "import tst"  
    Traceback (most recent call last):
      File "<string>", line 1, in ?
      File "tst.py", line 1, in ?
        import nan
      File "nan.py", line 2, in ?
        nan = inf/inf
    ZeroDivisionError: float division


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2006-05-22 06:28

Message:
Logged In: YES 
user_id=31435

mwh:  Heh.  It's sure not better under Windows on current trunk:

C:\Code\python\PCbuild>python -c "import nan"
-1.#IND
Exception exceptions.SystemError: 'frexp() result out of
range' in 'garbage collection' ignored
Fatal Python error: unexpected exception during garbage
collection

And now that the .pyc file exists:

C:\Code\python\PCbuild>python -c "import nan"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ValueError: bad marshal data

This is nan.py, BTW:

"""
inf = 1e300000
nan = inf/inf
print nan
"""

Changing that to "inf = 1e300*1e300" doesn't help in the
trunk, because of its more ambitious constant folding.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2006-05-22 06:00

Message:
Logged In: YES 
user_id=6656

Also, this probably won't be a problem in 2.5.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-05-22 05:32

Message:
Logged In: YES 
user_id=21627

Closing this as "not a bug". Notice that this judgement is
difficult to make, as the report is incomplete: you report
what you did (good), what happened (good), but not what you
expected to happen, or why you think the behaviour is
incorrect - only that it is "weird". As Tim mentioned
indirectly, this is intentional.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-05-21 11:09

Message:
Logged In: YES 
user_id=31435

Python doesn't know anything about IEEE special values, and
in particular what the marshal format (used for code
objects) does with infinities and NaNs is a
platform-dependent accident.

Try changing

inf = 1e300000

to

inf = 1e300 * 1e300

to stop Python from _trying_ to marshal/unmarshal a floating
infinity on that box.  I bet your problems will go away then.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1492293&group_id=5470

From noreply at sourceforge.net  Mon May 22 12:45:00 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 22 May 2006 03:45:00 -0700
Subject: [ python-Bugs-1492293 ] Wierd Floating Point on FreeBSD4 
Message-ID: <E1Fi7uG-00006e-Ep@sc8-sf-web1.sourceforge.net>

Bugs item #1492293, was opened at 2006-05-21 01:34
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1492293&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: Invalid
Priority: 5
Submitted By: David Abrahams (david_abrahams)
Assigned to: Nobody/Anonymous (nobody)
Summary: Wierd Floating Point on FreeBSD4 

Initial Comment:
This is just about the weirdest thing I've ever seen.
Python 2.4.2 (#1, Jan 17 2006, 09:30:19)
[GCC 2.95.2 19991024 (release)] on freebsd4

    ---- nan.py ----
    inf = 1e300000
    nan = inf/inf
    print nan
    ---- nan.py ----


    ---- tst.py ----
    import nan
    ---- tst.py ----

    % python -c "import nan"
    NaN

    % python -c "import tst"  
    NaN

Now I edit tst.py

    ---- tst.py ----
    #
    import nan
    ---- tst.py ----

    % python -c "import nan"
    Traceback (most recent call last):
      File "<string>", line 1, in ?
      File "nan.py", line 2, in ?
        nan = inf/inf
    ZeroDivisionError: float division

    % python -c "import tst"  
    Traceback (most recent call last):
      File "<string>", line 1, in ?
      File "tst.py", line 1, in ?
        import nan
      File "nan.py", line 2, in ?
        nan = inf/inf
    ZeroDivisionError: float division

    % rm *.pyc

    % python -c "import tst"  
    NaN

    % python -c "import nan"
    Traceback (most recent call last):
      File "<string>", line 1, in ?
      File "nan.py", line 2, in ?
        nan = inf/inf
    ZeroDivisionError: float division

    % python -c "import tst"  
    Traceback (most recent call last):
      File "<string>", line 1, in ?
      File "tst.py", line 1, in ?
        import nan
      File "nan.py", line 2, in ?
        nan = inf/inf
    ZeroDivisionError: float division


----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2006-05-22 11:45

Message:
Logged In: YES 
user_id=6656

Huh what?  That code is supposed to be dead on real systems now.  What does 
this say for you:

>>> float.__getformat__('double')
'IEEE, big-endian'

?  I take it test_float still passes.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-05-22 11:28

Message:
Logged In: YES 
user_id=31435

mwh:  Heh.  It's sure not better under Windows on current trunk:

C:\Code\python\PCbuild>python -c "import nan"
-1.#IND
Exception exceptions.SystemError: 'frexp() result out of
range' in 'garbage collection' ignored
Fatal Python error: unexpected exception during garbage
collection

And now that the .pyc file exists:

C:\Code\python\PCbuild>python -c "import nan"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ValueError: bad marshal data

This is nan.py, BTW:

"""
inf = 1e300000
nan = inf/inf
print nan
"""

Changing that to "inf = 1e300*1e300" doesn't help in the
trunk, because of its more ambitious constant folding.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2006-05-22 11:00

Message:
Logged In: YES 
user_id=6656

Also, this probably won't be a problem in 2.5.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-05-22 10:32

Message:
Logged In: YES 
user_id=21627

Closing this as "not a bug". Notice that this judgement is
difficult to make, as the report is incomplete: you report
what you did (good), what happened (good), but not what you
expected to happen, or why you think the behaviour is
incorrect - only that it is "weird". As Tim mentioned
indirectly, this is intentional.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-05-21 16:09

Message:
Logged In: YES 
user_id=31435

Python doesn't know anything about IEEE special values, and
in particular what the marshal format (used for code
objects) does with infinities and NaNs is a
platform-dependent accident.

Try changing

inf = 1e300000

to

inf = 1e300 * 1e300

to stop Python from _trying_ to marshal/unmarshal a floating
infinity on that box.  I bet your problems will go away then.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1492293&group_id=5470

From noreply at sourceforge.net  Mon May 22 12:52:25 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 22 May 2006 03:52:25 -0700
Subject: [ python-Bugs-1492293 ] Wierd Floating Point on FreeBSD4 
Message-ID: <E1Fi81R-0002e7-B3@sc8-sf-web3.sourceforge.net>

Bugs item #1492293, was opened at 2006-05-20 20:34
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1492293&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: Invalid
Priority: 5
Submitted By: David Abrahams (david_abrahams)
Assigned to: Nobody/Anonymous (nobody)
Summary: Wierd Floating Point on FreeBSD4 

Initial Comment:
This is just about the weirdest thing I've ever seen.
Python 2.4.2 (#1, Jan 17 2006, 09:30:19)
[GCC 2.95.2 19991024 (release)] on freebsd4

    ---- nan.py ----
    inf = 1e300000
    nan = inf/inf
    print nan
    ---- nan.py ----


    ---- tst.py ----
    import nan
    ---- tst.py ----

    % python -c "import nan"
    NaN

    % python -c "import tst"  
    NaN

Now I edit tst.py

    ---- tst.py ----
    #
    import nan
    ---- tst.py ----

    % python -c "import nan"
    Traceback (most recent call last):
      File "<string>", line 1, in ?
      File "nan.py", line 2, in ?
        nan = inf/inf
    ZeroDivisionError: float division

    % python -c "import tst"  
    Traceback (most recent call last):
      File "<string>", line 1, in ?
      File "tst.py", line 1, in ?
        import nan
      File "nan.py", line 2, in ?
        nan = inf/inf
    ZeroDivisionError: float division

    % rm *.pyc

    % python -c "import tst"  
    NaN

    % python -c "import nan"
    Traceback (most recent call last):
      File "<string>", line 1, in ?
      File "nan.py", line 2, in ?
        nan = inf/inf
    ZeroDivisionError: float division

    % python -c "import tst"  
    Traceback (most recent call last):
      File "<string>", line 1, in ?
      File "tst.py", line 1, in ?
        import nan
      File "nan.py", line 2, in ?
        nan = inf/inf
    ZeroDivisionError: float division


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2006-05-22 06:52

Message:
Logged In: YES 
user_id=31435

Hmm:

C:\Code\python\PCbuild>python
Python 2.5a2 (trunk:46052, May 19 2006, 20:53:33) [MSC
v.1310 32 bit (Intel)] on win32
>>> float.__getformat__('double')
'unknown'


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2006-05-22 06:45

Message:
Logged In: YES 
user_id=6656

Huh what?  That code is supposed to be dead on real systems now.  What does 
this say for you:

>>> float.__getformat__('double')
'IEEE, big-endian'

?  I take it test_float still passes.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-05-22 06:28

Message:
Logged In: YES 
user_id=31435

mwh:  Heh.  It's sure not better under Windows on current trunk:

C:\Code\python\PCbuild>python -c "import nan"
-1.#IND
Exception exceptions.SystemError: 'frexp() result out of
range' in 'garbage collection' ignored
Fatal Python error: unexpected exception during garbage
collection

And now that the .pyc file exists:

C:\Code\python\PCbuild>python -c "import nan"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ValueError: bad marshal data

This is nan.py, BTW:

"""
inf = 1e300000
nan = inf/inf
print nan
"""

Changing that to "inf = 1e300*1e300" doesn't help in the
trunk, because of its more ambitious constant folding.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2006-05-22 06:00

Message:
Logged In: YES 
user_id=6656

Also, this probably won't be a problem in 2.5.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-05-22 05:32

Message:
Logged In: YES 
user_id=21627

Closing this as "not a bug". Notice that this judgement is
difficult to make, as the report is incomplete: you report
what you did (good), what happened (good), but not what you
expected to happen, or why you think the behaviour is
incorrect - only that it is "weird". As Tim mentioned
indirectly, this is intentional.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-05-21 11:09

Message:
Logged In: YES 
user_id=31435

Python doesn't know anything about IEEE special values, and
in particular what the marshal format (used for code
objects) does with infinities and NaNs is a
platform-dependent accident.

Try changing

inf = 1e300000

to

inf = 1e300 * 1e300

to stop Python from _trying_ to marshal/unmarshal a floating
infinity on that box.  I bet your problems will go away then.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1492293&group_id=5470

From noreply at sourceforge.net  Mon May 22 12:55:58 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 22 May 2006 03:55:58 -0700
Subject: [ python-Bugs-1492293 ] Wierd Floating Point on FreeBSD4 
Message-ID: <E1Fi84s-000419-Pu@sc8-sf-web3.sourceforge.net>

Bugs item #1492293, was opened at 2006-05-20 20:34
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1492293&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: Invalid
Priority: 5
Submitted By: David Abrahams (david_abrahams)
Assigned to: Nobody/Anonymous (nobody)
Summary: Wierd Floating Point on FreeBSD4 

Initial Comment:
This is just about the weirdest thing I've ever seen.
Python 2.4.2 (#1, Jan 17 2006, 09:30:19)
[GCC 2.95.2 19991024 (release)] on freebsd4

    ---- nan.py ----
    inf = 1e300000
    nan = inf/inf
    print nan
    ---- nan.py ----


    ---- tst.py ----
    import nan
    ---- tst.py ----

    % python -c "import nan"
    NaN

    % python -c "import tst"  
    NaN

Now I edit tst.py

    ---- tst.py ----
    #
    import nan
    ---- tst.py ----

    % python -c "import nan"
    Traceback (most recent call last):
      File "<string>", line 1, in ?
      File "nan.py", line 2, in ?
        nan = inf/inf
    ZeroDivisionError: float division

    % python -c "import tst"  
    Traceback (most recent call last):
      File "<string>", line 1, in ?
      File "tst.py", line 1, in ?
        import nan
      File "nan.py", line 2, in ?
        nan = inf/inf
    ZeroDivisionError: float division

    % rm *.pyc

    % python -c "import tst"  
    NaN

    % python -c "import nan"
    Traceback (most recent call last):
      File "<string>", line 1, in ?
      File "nan.py", line 2, in ?
        nan = inf/inf
    ZeroDivisionError: float division

    % python -c "import tst"  
    Traceback (most recent call last):
      File "<string>", line 1, in ?
      File "tst.py", line 1, in ?
        import nan
      File "nan.py", line 2, in ?
        nan = inf/inf
    ZeroDivisionError: float division


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2006-05-22 06:55

Message:
Logged In: YES 
user_id=31435

BTW, I suspect SIZEOF_DOUBLE simply isn't defined on
Windows.  I'll check that later.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-05-22 06:52

Message:
Logged In: YES 
user_id=31435

Hmm:

C:\Code\python\PCbuild>python
Python 2.5a2 (trunk:46052, May 19 2006, 20:53:33) [MSC
v.1310 32 bit (Intel)] on win32
>>> float.__getformat__('double')
'unknown'


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2006-05-22 06:45

Message:
Logged In: YES 
user_id=6656

Huh what?  That code is supposed to be dead on real systems now.  What does 
this say for you:

>>> float.__getformat__('double')
'IEEE, big-endian'

?  I take it test_float still passes.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-05-22 06:28

Message:
Logged In: YES 
user_id=31435

mwh:  Heh.  It's sure not better under Windows on current trunk:

C:\Code\python\PCbuild>python -c "import nan"
-1.#IND
Exception exceptions.SystemError: 'frexp() result out of
range' in 'garbage collection' ignored
Fatal Python error: unexpected exception during garbage
collection

And now that the .pyc file exists:

C:\Code\python\PCbuild>python -c "import nan"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ValueError: bad marshal data

This is nan.py, BTW:

"""
inf = 1e300000
nan = inf/inf
print nan
"""

Changing that to "inf = 1e300*1e300" doesn't help in the
trunk, because of its more ambitious constant folding.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2006-05-22 06:00

Message:
Logged In: YES 
user_id=6656

Also, this probably won't be a problem in 2.5.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-05-22 05:32

Message:
Logged In: YES 
user_id=21627

Closing this as "not a bug". Notice that this judgement is
difficult to make, as the report is incomplete: you report
what you did (good), what happened (good), but not what you
expected to happen, or why you think the behaviour is
incorrect - only that it is "weird". As Tim mentioned
indirectly, this is intentional.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-05-21 11:09

Message:
Logged In: YES 
user_id=31435

Python doesn't know anything about IEEE special values, and
in particular what the marshal format (used for code
objects) does with infinities and NaNs is a
platform-dependent accident.

Try changing

inf = 1e300000

to

inf = 1e300 * 1e300

to stop Python from _trying_ to marshal/unmarshal a floating
infinity on that box.  I bet your problems will go away then.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1492293&group_id=5470

From noreply at sourceforge.net  Mon May 22 12:58:42 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 22 May 2006 03:58:42 -0700
Subject: [ python-Bugs-1492293 ] Wierd Floating Point on FreeBSD4 
Message-ID: <E1Fi87W-0004wW-C0@sc8-sf-web3.sourceforge.net>

Bugs item #1492293, was opened at 2006-05-21 01:34
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1492293&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: Invalid
Priority: 5
Submitted By: David Abrahams (david_abrahams)
Assigned to: Nobody/Anonymous (nobody)
Summary: Wierd Floating Point on FreeBSD4 

Initial Comment:
This is just about the weirdest thing I've ever seen.
Python 2.4.2 (#1, Jan 17 2006, 09:30:19)
[GCC 2.95.2 19991024 (release)] on freebsd4

    ---- nan.py ----
    inf = 1e300000
    nan = inf/inf
    print nan
    ---- nan.py ----


    ---- tst.py ----
    import nan
    ---- tst.py ----

    % python -c "import nan"
    NaN

    % python -c "import tst"  
    NaN

Now I edit tst.py

    ---- tst.py ----
    #
    import nan
    ---- tst.py ----

    % python -c "import nan"
    Traceback (most recent call last):
      File "<string>", line 1, in ?
      File "nan.py", line 2, in ?
        nan = inf/inf
    ZeroDivisionError: float division

    % python -c "import tst"  
    Traceback (most recent call last):
      File "<string>", line 1, in ?
      File "tst.py", line 1, in ?
        import nan
      File "nan.py", line 2, in ?
        nan = inf/inf
    ZeroDivisionError: float division

    % rm *.pyc

    % python -c "import tst"  
    NaN

    % python -c "import nan"
    Traceback (most recent call last):
      File "<string>", line 1, in ?
      File "nan.py", line 2, in ?
        nan = inf/inf
    ZeroDivisionError: float division

    % python -c "import tst"  
    Traceback (most recent call last):
      File "<string>", line 1, in ?
      File "tst.py", line 1, in ?
        import nan
      File "nan.py", line 2, in ?
        nan = inf/inf
    ZeroDivisionError: float division


----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2006-05-22 11:58

Message:
Logged In: YES 
user_id=6656

Oh right.

The "Fatal Python error: unexpected exception during garbage collection" thing 
is still a bit disturbing though...

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-05-22 11:55

Message:
Logged In: YES 
user_id=31435

BTW, I suspect SIZEOF_DOUBLE simply isn't defined on
Windows.  I'll check that later.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-05-22 11:52

Message:
Logged In: YES 
user_id=31435

Hmm:

C:\Code\python\PCbuild>python
Python 2.5a2 (trunk:46052, May 19 2006, 20:53:33) [MSC
v.1310 32 bit (Intel)] on win32
>>> float.__getformat__('double')
'unknown'


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2006-05-22 11:45

Message:
Logged In: YES 
user_id=6656

Huh what?  That code is supposed to be dead on real systems now.  What does 
this say for you:

>>> float.__getformat__('double')
'IEEE, big-endian'

?  I take it test_float still passes.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-05-22 11:28

Message:
Logged In: YES 
user_id=31435

mwh:  Heh.  It's sure not better under Windows on current trunk:

C:\Code\python\PCbuild>python -c "import nan"
-1.#IND
Exception exceptions.SystemError: 'frexp() result out of
range' in 'garbage collection' ignored
Fatal Python error: unexpected exception during garbage
collection

And now that the .pyc file exists:

C:\Code\python\PCbuild>python -c "import nan"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ValueError: bad marshal data

This is nan.py, BTW:

"""
inf = 1e300000
nan = inf/inf
print nan
"""

Changing that to "inf = 1e300*1e300" doesn't help in the
trunk, because of its more ambitious constant folding.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2006-05-22 11:00

Message:
Logged In: YES 
user_id=6656

Also, this probably won't be a problem in 2.5.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-05-22 10:32

Message:
Logged In: YES 
user_id=21627

Closing this as "not a bug". Notice that this judgement is
difficult to make, as the report is incomplete: you report
what you did (good), what happened (good), but not what you
expected to happen, or why you think the behaviour is
incorrect - only that it is "weird". As Tim mentioned
indirectly, this is intentional.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-05-21 16:09

Message:
Logged In: YES 
user_id=31435

Python doesn't know anything about IEEE special values, and
in particular what the marshal format (used for code
objects) does with infinities and NaNs is a
platform-dependent accident.

Try changing

inf = 1e300000

to

inf = 1e300 * 1e300

to stop Python from _trying_ to marshal/unmarshal a floating
infinity on that box.  I bet your problems will go away then.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1492293&group_id=5470

From noreply at sourceforge.net  Mon May 22 13:31:26 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 22 May 2006 04:31:26 -0700
Subject: [ python-Feature Requests-1492856 ] Create "Performance" category?
Message-ID: <E1Fi8dC-0006dp-92@sc8-sf-web5.sourceforge.net>

Feature Requests item #1492856, was opened at 2006-05-22 11:31
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1492856&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: Demos and Tools
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Sean Reifschneider (jafo)
Assigned to: Nobody/Anonymous (nobody)
Summary: Create "Performance" category?

Initial Comment:
Based on discussion at the Need for Speed sprint, it
would be nice to have a category for performance
tracker items.  Any objections?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1492856&group_id=5470

From noreply at sourceforge.net  Mon May 22 13:43:05 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 22 May 2006 04:43:05 -0700
Subject: [ python-Feature Requests-1492860 ] Integer bit operations
	performance improvement.
Message-ID: <E1Fi8oT-0006zX-Jj@sc8-sf-web2.sourceforge.net>

Feature Requests item #1492860, was opened at 2006-05-22 11:43
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1492860&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: 1
Submitted By: Sean Reifschneider (jafo)
Assigned to: Nobody/Anonymous (nobody)
Summary: Integer bit operations performance improvement.

Initial Comment:
At the Need for Speed sprint, Tim Peters asked if
anyone had any need for integer bit operation
performance improvement.  Apparently, it's easy to
improve, but nobody has said they need this.  Please
reply to this task if you have an application which
needs this.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1492860&group_id=5470

From noreply at sourceforge.net  Mon May 22 14:27:13 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 22 May 2006 05:27:13 -0700
Subject: [ python-Feature Requests-1492856 ] Create "Performance" category?
Message-ID: <E1Fi9VB-0000hi-3R@sc8-sf-web2.sourceforge.net>

Feature Requests item #1492856, was opened at 2006-05-22 07:31
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1492856&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: Performance
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Sean Reifschneider (jafo)
Assigned to: Nobody/Anonymous (nobody)
Summary: Create "Performance" category?

Initial Comment:
Based on discussion at the Need for Speed sprint, it
would be nice to have a category for performance
tracker items.  Any objections?

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2006-05-22 08:27

Message:
Logged In: YES 
user_id=31435

I created a Performance category in the Bug, Patch, and
Feature Request trackers.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1492856&group_id=5470

From noreply at sourceforge.net  Mon May 22 14:29:48 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 22 May 2006 05:29:48 -0700
Subject: [ python-Feature Requests-1492860 ] Integer bit operations
	performance improvement.
Message-ID: <E1Fi9Xg-0001ou-JY@sc8-sf-web2.sourceforge.net>

Feature Requests item #1492860, was opened at 2006-05-22 07:43
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1492860&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: Performance
Group: None
Status: Open
Resolution: None
Priority: 1
Submitted By: Sean Reifschneider (jafo)
Assigned to: Nobody/Anonymous (nobody)
Summary: Integer bit operations performance improvement.

Initial Comment:
At the Need for Speed sprint, Tim Peters asked if
anyone had any need for integer bit operation
performance improvement.  Apparently, it's easy to
improve, but nobody has said they need this.  Please
reply to this task if you have an application which
needs this.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2006-05-22 08:29

Message:
Logged In: YES 
user_id=31435

Changed Category to Performance.  The idea with this one is
that the eval loop could easily inline "int & int", "int |
int", "int ^ int", much as it inlines "int + int" today.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1492860&group_id=5470

From noreply at sourceforge.net  Mon May 22 15:09:11 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 22 May 2006 06:09:11 -0700
Subject: [ python-Bugs-1491574 ] distutils adds (unwanted) -xcode=pic32 in the
	compile comman
Message-ID: <E1FiA9n-000369-5G@sc8-sf-web3.sourceforge.net>

Bugs item #1491574, was opened at 2006-05-19 15:04
Message generated for change (Comment added) made by tknapen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1491574&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: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Toon Knapen (tknapen)
Assigned to: Nobody/Anonymous (nobody)
Summary: distutils adds (unwanted) -xcode=pic32 in the compile comman

Initial Comment:
After configuring, making and make installing the
svn-trunk version with sunstudio11 on a Solaris 9 box,
an extra '-xcode=pic32' argument is added to the
compile-command when I try to install numarray using
the setup.py that comes with numarray.

To configure python I first executed:

export CC=cc
export CFLAGS="-xarch=v9" # to force 64bit compilation
export EXTRA_CFLAGS="-xarch=v9" # 
export CXX=CC
export CXXFLAGS="-xarch=v9"
export F77=f77
export FFLAGS="-xarch=v9"
export LDFLAGS="-xarch=v9"

Note that EXTRA_CFLAGS needs to be defined too,
otherwise python itself will not be compiled with the
-xarch=v9 option.

Afterwards I want to install numarray using the
setup.py (`python setup.py install` command). During
compilation of numarray I can however see that
distutils is adding -xcode=pic32 on the command-line.
Afterwards distutils is not able to link because there
now is a mix of 32bit and 64bit code.


----------------------------------------------------------------------

>Comment By: Toon Knapen (tknapen)
Date: 2006-05-22 15:09

Message:
Logged In: YES 
user_id=144552

Indeed the -xcode=pic32 is not at fault here. The problem
though still is that distutils is not linking the shared
libraries using the link-option '-xarch=v9'. The linker
therefore complains about a mix of 32bit and 64bit code.

Should'nt distutils copy the content of LDFLAGS of when
python is being configured and add these options to the
link-line ?

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-05-20 08:31

Message:
Logged In: YES 
user_id=21627

You must be misunderstanding something. -xcode=pic32 does
*not* mean that the code ought to be compiled for the 32-bit
processor mode. Instead, it means that the PIC (position
independent code) offsets are encoded using 32-bit numbers,
which works for both 32-bit and 64-bit code as long as the
size of the code does not exceed 4GiB.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1491574&group_id=5470

From noreply at sourceforge.net  Tue May 23 00:27:52 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 22 May 2006 15:27:52 -0700
Subject: [ python-Bugs-1491574 ] distutils adds (unwanted) -xcode=pic32 in the
	compile comman
Message-ID: <E1FiIsS-0001CG-Gx@sc8-sf-web4-b.sourceforge.net>

Bugs item #1491574, was opened at 2006-05-19 15:04
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1491574&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: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Toon Knapen (tknapen)
Assigned to: Nobody/Anonymous (nobody)
Summary: distutils adds (unwanted) -xcode=pic32 in the compile comman

Initial Comment:
After configuring, making and make installing the
svn-trunk version with sunstudio11 on a Solaris 9 box,
an extra '-xcode=pic32' argument is added to the
compile-command when I try to install numarray using
the setup.py that comes with numarray.

To configure python I first executed:

export CC=cc
export CFLAGS="-xarch=v9" # to force 64bit compilation
export EXTRA_CFLAGS="-xarch=v9" # 
export CXX=CC
export CXXFLAGS="-xarch=v9"
export F77=f77
export FFLAGS="-xarch=v9"
export LDFLAGS="-xarch=v9"

Note that EXTRA_CFLAGS needs to be defined too,
otherwise python itself will not be compiled with the
-xarch=v9 option.

Afterwards I want to install numarray using the
setup.py (`python setup.py install` command). During
compilation of numarray I can however see that
distutils is adding -xcode=pic32 on the command-line.
Afterwards distutils is not able to link because there
now is a mix of 32bit and 64bit code.


----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-05-23 00:27

Message:
Logged In: YES 
user_id=21627

Something like that, yes. It's quite involved, so it is not
easy to see what the right approach is.

If you can come up with a patch that works for you, I can
review the patch to find out what else it breaks.

----------------------------------------------------------------------

Comment By: Toon Knapen (tknapen)
Date: 2006-05-22 15:09

Message:
Logged In: YES 
user_id=144552

Indeed the -xcode=pic32 is not at fault here. The problem
though still is that distutils is not linking the shared
libraries using the link-option '-xarch=v9'. The linker
therefore complains about a mix of 32bit and 64bit code.

Should'nt distutils copy the content of LDFLAGS of when
python is being configured and add these options to the
link-line ?

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-05-20 08:31

Message:
Logged In: YES 
user_id=21627

You must be misunderstanding something. -xcode=pic32 does
*not* mean that the code ought to be compiled for the 32-bit
processor mode. Instead, it means that the PIC (position
independent code) offsets are encoded using 32-bit numbers,
which works for both 32-bit and 64-bit code as long as the
size of the code does not exceed 4GiB.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1491574&group_id=5470

From noreply at sourceforge.net  Tue May 23 04:30:17 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 22 May 2006 19:30:17 -0700
Subject: [ python-Bugs-1493322 ] bsddb: db never opened for writing forgets
	its size
Message-ID: <E1FiMf3-0000qy-Hb@sc8-sf-web3.sourceforge.net>

Bugs item #1493322, was opened at 2006-05-22 20:30
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=1493322&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: Steven Taschuk (staschuk)
Assigned to: Nobody/Anonymous (nobody)
Summary: bsddb: db never opened for writing forgets its size

Initial Comment:
See the attached program; on my machine, its output is
as described therein.  That is: if a bsddb hash
database is opened read-only, and has never been opened
for writing (except when first created), then calling
len() on the database object returns the correct value
the first time, but zero on the second and later calls.
 Opening the database for writing once seems to
eliminate the problem; even when it is opened read-only
later, len() behaves as expected.

My machine runs Linux 2.6.16, glibc 2.3.4, Python
2.4.3, and Berkeley DB 4.3.28.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1493322&group_id=5470

From noreply at sourceforge.net  Tue May 23 05:36:02 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 22 May 2006 20:36:02 -0700
Subject: [ python-Bugs-1472251 ] pdb 'run' crashes when the it's first
	argument is non-string
Message-ID: <E1FiNgg-0006cI-FA@sc8-sf-web3.sourceforge.net>

Bugs item #1472251, was opened at 2006-04-18 05:16
Message generated for change (Comment added) made by isandler
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472251&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: Kuba Ko??czyk (jakamkon)
Assigned to: Nobody/Anonymous (nobody)
Summary: pdb 'run' crashes when the it's first argument is non-string

Initial Comment:
Pdb 'run/runeval' commands fails to check the type of
given argument.When argument to 'run/runeval' is
non-string the functions crashes with further
impilications on (correctly)invoking this functions: 

Python 2.5a1 (trunk:45527, Apr 18 2006, 11:12:31)

>>> def x(): pass
>>> import pdb
>>> pdb.run(x())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/jkk/python/python-svn/Lib/pdb.py", line
1113, in run
    Pdb().run(statement, globals, locals)
  File "/home/jkk/python/python-svn/Lib/bdb.py", line
363, in run
    cmd = cmd+'\n'
TypeError: unsupported operand type(s) for +:
'NoneType' and 'str'
>>> pdb.run('x()')
> /home/jkk/python/python-svn/Lib/pdb.py(1113)run()
-> Pdb().run(statement, globals, locals)
(Pdb)
# CTRL-D pressed
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/jkk/python/python-svn/Lib/pdb.py", line
1113, in run
    Pdb().run(statement, globals, locals)
  File "/home/jkk/python/python-svn/Lib/pdb.py", line
1113, in run
    Pdb().run(statement, globals, locals)
  File "/home/jkk/python/python-svn/Lib/bdb.py", line
48, in trace_dispatch
    return self.dispatch_line(frame)
  File "/home/jkk/python/python-svn/Lib/bdb.py", line
67, in dispatch_line
    if self.quitting: raise BdbQuit
bdb.BdbQuit

The solution is to simply ensure that the first
argument passed to the 'run/runeval' functions is string.

----------------------------------------------------------------------

Comment By: Ilya Sandler (isandler)
Date: 2006-05-22 20:36

Message:
Logged In: YES 
user_id=971153


Well, I don't see anything in bdb's run which could
overwrite your namespace..

What seems to be happenning in your example is that bdb's
first line event happens while bdb is still in run(), so you
when you see pdb's prompt, are in bdb's namespace not in
yours.. If you do "next" you will get where you should be..

 bagira:~> python2.4
 Python 2.4.1 (#2, May  5 2005, 11:32:06) 
 >>> def x(): print "in x"
 >>> import pdb
 >>> pdb.run( x())
 in x
 TypeError: unsupported operand type(s) for +: 'NoneType'
and 'str'
 >>> pdb.run( 'x()' )
 > /usr/lib/python2.4/pdb.py(987)run()
 -> Pdb().run(statement, globals, locals)
 (Pdb) n          #now you are back in your namespace
 > <string>(1)?()
 (Pdb) p x        #and you get your symbols back
 <function x at 0x4021be2c>
 (Pdb) p pdb
 <module 'pdb' from '/usr/lib/python2.4/pdb.pyc'>
 (Pdb) n
 in x
 --Return--
 > <string>(1)?()->None


What do you think?

----------------------------------------------------------------------

Comment By: Kuba Ko??czyk (jakamkon)
Date: 2006-05-22 02:20

Message:
Logged In: YES 
user_id=1491175

The point is that when you want to invoke pdb.run correctly
(with string argument) after getting TypeError as in above
example,
your namespace is probably overwritten or deleted so that
you don't have access to previously defined symbols.

>>> def x():pass
>>> import pdb
>>> pdb.run(x())
TypeError
>>> pdb.run('x()')
> /home/jkk/python-svn/Lib/pdb.py(1122)run()
-> Pdb().run(statement, globals, locals)
(Pdb) pdb
*** NameError: name 'pdb' is not defined
(Pdb) x
*** NameError: name 'x' is not defined


----------------------------------------------------------------------

Comment By: Ilya Sandler (isandler)
Date: 2006-05-21 16:25

Message:
Logged In: YES 
user_id=971153


I would not classify your example as a crash. You passed a
wrong value (None in your case) into pdb.run() and got back
a TypeError...Isn't it an expected response?

E.g if you do:  >>>max(13)

You'll also get: "TypeError"


Am I missing something? Could you clarify?



----------------------------------------------------------------------

Comment By: Kuba Ko??czyk (jakamkon)
Date: 2006-04-18 05:36

Message:
Logged In: YES 
user_id=1491175

Patch is in #1472257

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472251&group_id=5470

From noreply at sourceforge.net  Tue May 23 07:47:37 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 22 May 2006 22:47:37 -0700
Subject: [ python-Bugs-1493322 ] bsddb: db never opened for writing forgets
	its size
Message-ID: <E1FiPk1-000797-8g@sc8-sf-web1.sourceforge.net>

Bugs item #1493322, was opened at 2006-05-22 19:30
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1493322&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: Steven Taschuk (staschuk)
>Assigned to: Gregory P. Smith (greg)
Summary: bsddb: db never opened for writing forgets its size

Initial Comment:
See the attached program; on my machine, its output is
as described therein.  That is: if a bsddb hash
database is opened read-only, and has never been opened
for writing (except when first created), then calling
len() on the database object returns the correct value
the first time, but zero on the second and later calls.
 Opening the database for writing once seems to
eliminate the problem; even when it is opened read-only
later, len() behaves as expected.

My machine runs Linux 2.6.16, glibc 2.3.4, Python
2.4.3, and Berkeley DB 4.3.28.

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-05-22 22:47

Message:
Logged In: YES 
user_id=33168

Greg, is this a known issue?  Any ideas?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1493322&group_id=5470

From noreply at sourceforge.net  Tue May 23 11:13:45 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 23 May 2006 02:13:45 -0700
Subject: [ python-Bugs-1491574 ] distutils adds (unwanted) -xcode=pic32 in the
	compile comman
Message-ID: <E1FiSxV-0005tp-3o@sc8-sf-web2.sourceforge.net>

Bugs item #1491574, was opened at 2006-05-19 15:04
Message generated for change (Comment added) made by tknapen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1491574&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: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Toon Knapen (tknapen)
Assigned to: Nobody/Anonymous (nobody)
Summary: distutils adds (unwanted) -xcode=pic32 in the compile comman

Initial Comment:
After configuring, making and make installing the
svn-trunk version with sunstudio11 on a Solaris 9 box,
an extra '-xcode=pic32' argument is added to the
compile-command when I try to install numarray using
the setup.py that comes with numarray.

To configure python I first executed:

export CC=cc
export CFLAGS="-xarch=v9" # to force 64bit compilation
export EXTRA_CFLAGS="-xarch=v9" # 
export CXX=CC
export CXXFLAGS="-xarch=v9"
export F77=f77
export FFLAGS="-xarch=v9"
export LDFLAGS="-xarch=v9"

Note that EXTRA_CFLAGS needs to be defined too,
otherwise python itself will not be compiled with the
-xarch=v9 option.

Afterwards I want to install numarray using the
setup.py (`python setup.py install` command). During
compilation of numarray I can however see that
distutils is adding -xcode=pic32 on the command-line.
Afterwards distutils is not able to link because there
now is a mix of 32bit and 64bit code.


----------------------------------------------------------------------

>Comment By: Toon Knapen (tknapen)
Date: 2006-05-23 11:13

Message:
Logged In: YES 
user_id=144552

Looking through the code of distutils I finally found that
plenty of information is recoved from the _current_
environment in distutils/sysconfig.py.

Thus the LDFLAGS env.var. I had defined when configuring
python is not stored somewhere. So when e.g. installing
numarray, I need to set the LDFLAGS env.var. again.

Would'nt it be better if python would store the
flags/options that were used to compile python itself. This
guarantees that the extension modules will be
compiled/linked with the same flags and guarantees a maximal
compatibility?

If you prefer to move this discussion to the python-ml ....

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-05-23 00:27

Message:
Logged In: YES 
user_id=21627

Something like that, yes. It's quite involved, so it is not
easy to see what the right approach is.

If you can come up with a patch that works for you, I can
review the patch to find out what else it breaks.

----------------------------------------------------------------------

Comment By: Toon Knapen (tknapen)
Date: 2006-05-22 15:09

Message:
Logged In: YES 
user_id=144552

Indeed the -xcode=pic32 is not at fault here. The problem
though still is that distutils is not linking the shared
libraries using the link-option '-xarch=v9'. The linker
therefore complains about a mix of 32bit and 64bit code.

Should'nt distutils copy the content of LDFLAGS of when
python is being configured and add these options to the
link-line ?

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-05-20 08:31

Message:
Logged In: YES 
user_id=21627

You must be misunderstanding something. -xcode=pic32 does
*not* mean that the code ought to be compiled for the 32-bit
processor mode. Instead, it means that the PIC (position
independent code) offsets are encoded using 32-bit numbers,
which works for both 32-bit and 64-bit code as long as the
size of the code does not exceed 4GiB.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1491574&group_id=5470

From noreply at sourceforge.net  Tue May 23 12:51:47 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 23 May 2006 03:51:47 -0700
Subject: [ python-Bugs-963494 ] packman upgrade issue
Message-ID: <E1FiUUN-0008DE-3d@sc8-sf-web3.sourceforge.net>

Bugs item #963494, was opened at 2004-05-31 11:39
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=963494&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Macintosh
Group: Feature Request
Status: Open
Resolution: None
Priority: 3
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Jack Jansen (jackjansen)
Summary: packman upgrade issue

Initial Comment:
When you upgrade a package using packman the installer doesn't 
remove the old version before installing the new version. The end 
result is that old files might interfere with the correct operation of 
the upgraded package.

I ran into this with an upgrade from PyObjC 1.0 to PyObjC 1.1. 
Some extension modules have moved between those two releases. 
When upgrading using PackMan the old extension modules still 
exists, and cause problems when you try to use the package.

Three possible solutions:

1) Remove the existing package directory before installing the
    upgrade

2) Add pre/post install/upgrade scripts

3) Use a real package database

----------------------------------------------------------------------

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-05-23 12:51

Message:
Logged In: YES 
user_id=580910

I propose closing this bug as WontFix, PackMan is dead in the water.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2005-01-04 21:48

Message:
Logged In: YES 
user_id=45365

I don't like the extra_path idea: it's meant for something else really. I 
think I'll just go for it and try the uninstaller trick. Don't know whether I'll 
have it in place before additions build 3, though, we'll see.

As to the other issue (missing dependencies and such): I want to solve 
that differently, eventually. Currently there's only one test (installed) per 
package that's supposed to be as cheap as possible. I want to have at 
least one more (consistency) and maybe even two (consistency and full 
selfcheck). But that'll have to wait.

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2005-01-04 17:34

Message:
Logged In: YES 
user_id=580910

That might work. It does require that packman installs dependencies 
before installing the package itself. 

Another problem is smart GUI's. One useful feature for a PackMan GUI 
would be a listing of missing dependencies (e.g. you've installed _tkinter 
and somehow didn't install AquaTk, it would be nice if PackMan said that 
AquaTk is missing). Such a feature would have to know about uninstall 
packages, otherwise it would complain that 'foo-uninstall' is missing after 
you've installed 'foo'.

Another solution (at least for PyObjC) is making sure that every package 
uses the 'extra_path' feature of distutils, add that value to the packman 
database, and remove $extra_path before installing a package. The 
extra_path key in the database could be optional: only add it when the 
previous version must be uninstalled before installing a new version.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2005-01-04 17:03

Message:
Logged In: YES 
user_id=45365

All of these are difficult. But I was just wondering whether we could 
implement something simple: uninstall packages. For example, a 
package "PyObjC-uninstall" (normallly hidden) would somehow contain 
enough info to eradicate any known PyObjC installation. It's "installed" 
status would be true if PyObjC is *not* installed, false if it is.

PyObjC-1.3-{source,binary} could then depend on PyObjC-uninstall, and 
when the user installed either of these they would first "install" PyObjC-
uninstall, which would erase any previous installation.

An uninstall package would probably consist of a list of files and dirs that 
would need to be removed. The package would be flagged as "installed" 
if any of these exist.

There's probably packages that need something more complex (like 
editing config files or whatever), but I think this scheme would handle 
most common cases.

"installing" an uninstall package, possibly as a result of a dependency, 
should probably put up a warning dialog first.

Does this sound workable?

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2004-06-03 15:14

Message:
Logged In: YES 
user_id=45365

I'm moving this to the feature requests category: it requires major 
surgery, and it could be argued that this functionality belongs more in 
distutils than in Package Manager.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=963494&group_id=5470

From noreply at sourceforge.net  Tue May 23 13:07:34 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 23 May 2006 04:07:34 -0700
Subject: [ python-Bugs-1486897 ] OS X framework build for python 2.5 fails,
	configure is odd
Message-ID: <E1FiUje-0003PP-36@sc8-sf-web4-b.sourceforge.net>

Bugs item #1486897, was opened at 2006-05-11 23:44
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1486897&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: Christopher Knox (vizowl)
Assigned to: Nobody/Anonymous (nobody)
Summary: OS X framework build for python 2.5 fails, configure is odd

Initial Comment:
The OS X framework build for python 2.5 does not install a dynamic 
library at /Library/Frameworks/Python.framework/Versions/2.5/Python 
where it should. The python2.5 executible does not run because it is 
trying to load this dynamic library.

This is on an intel mac with darwin-8.6.1 and gcc4 and python2.5a2.

Also all of the extra modules (_CG extension, IDLE extra) fail to link 
because their link command is -lpython2.5 which is not what it should be 
for a framework build and even if it was correct for linking agianst a 
framework it would fil because the framework doesn't have its library 
anyway.

Finally, the configure script behaves oddly in that it works fine, but if you 
change the parameters and rerun it it will fail unless you run 'make 
distclean'

This is where it fails.

checking whether mmap with MAP_ANON(YMOUS) works... yes
configure: error: "libffi has not been ported to i686-apple-darwin8.6.1."
Failed to configure _ctypes module

----------------------------------------------------------------------

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-05-23 13:07

Message:
Logged In: YES 
user_id=580910

The configure failure in the orginal message is not a problem, that's libffi failing. 
Libffi is used by ctypes and not supported on darwin/x86. I have a patch and I 
know of another one, but neither have been merged into the copy that's used by 
ctypes. The only effect of this is that you won't get ctypes.

Could you test  again without --enable-profiling? That's one flag I've never used 
and didn't test yet. BTW. the attached build log contains lots of NUL bytes, 
should it or has it been corrupted along the way?

----------------------------------------------------------------------

Comment By: Christopher Knox (vizowl)
Date: 2006-05-15 19:13

Message:
Logged In: YES 
user_id=1346203

Hi Neal,

I checked out rev 46003 (the HEAD at the time) in a clean directory and used: 

./configure --enable-profiling --enable-shared --enable-framework --
enable-universalsdk

Unfortunately it failed in the same way it has the same problems in that it is 
linking with the flag -lpython2.5 when it should be a framework linking. I 
have attached the build log from after having built it once so you only see the 
linking.

However, it does appear that the issue raised in bug # 1487105 is solved. It 
compiled fine on an intel mac it just has linking problems.

Also I get exactly the same problem on a G5

Chris

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-05-15 08:25

Message:
Logged In: YES 
user_id=33168

Christopher can you try with a current checkout?  Ronald
checked in lots of changes which I think include x86 support
at svn rev 45997.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1486897&group_id=5470

From noreply at sourceforge.net  Tue May 23 13:08:00 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 23 May 2006 04:08:00 -0700
Subject: [ python-Bugs-1486897 ] OS X framework build for python 2.5 fails,
	configure is odd
Message-ID: <E1FiUk4-0003YL-Gu@sc8-sf-web4-b.sourceforge.net>

Bugs item #1486897, was opened at 2006-05-11 23:44
Message generated for change (Settings changed) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1486897&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: Christopher Knox (vizowl)
>Assigned to: Ronald Oussoren (ronaldoussoren)
Summary: OS X framework build for python 2.5 fails, configure is odd

Initial Comment:
The OS X framework build for python 2.5 does not install a dynamic 
library at /Library/Frameworks/Python.framework/Versions/2.5/Python 
where it should. The python2.5 executible does not run because it is 
trying to load this dynamic library.

This is on an intel mac with darwin-8.6.1 and gcc4 and python2.5a2.

Also all of the extra modules (_CG extension, IDLE extra) fail to link 
because their link command is -lpython2.5 which is not what it should be 
for a framework build and even if it was correct for linking agianst a 
framework it would fil because the framework doesn't have its library 
anyway.

Finally, the configure script behaves oddly in that it works fine, but if you 
change the parameters and rerun it it will fail unless you run 'make 
distclean'

This is where it fails.

checking whether mmap with MAP_ANON(YMOUS) works... yes
configure: error: "libffi has not been ported to i686-apple-darwin8.6.1."
Failed to configure _ctypes module

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-05-23 13:07

Message:
Logged In: YES 
user_id=580910

The configure failure in the orginal message is not a problem, that's libffi failing. 
Libffi is used by ctypes and not supported on darwin/x86. I have a patch and I 
know of another one, but neither have been merged into the copy that's used by 
ctypes. The only effect of this is that you won't get ctypes.

Could you test  again without --enable-profiling? That's one flag I've never used 
and didn't test yet. BTW. the attached build log contains lots of NUL bytes, 
should it or has it been corrupted along the way?

----------------------------------------------------------------------

Comment By: Christopher Knox (vizowl)
Date: 2006-05-15 19:13

Message:
Logged In: YES 
user_id=1346203

Hi Neal,

I checked out rev 46003 (the HEAD at the time) in a clean directory and used: 

./configure --enable-profiling --enable-shared --enable-framework --
enable-universalsdk

Unfortunately it failed in the same way it has the same problems in that it is 
linking with the flag -lpython2.5 when it should be a framework linking. I 
have attached the build log from after having built it once so you only see the 
linking.

However, it does appear that the issue raised in bug # 1487105 is solved. It 
compiled fine on an intel mac it just has linking problems.

Also I get exactly the same problem on a G5

Chris

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-05-15 08:25

Message:
Logged In: YES 
user_id=33168

Christopher can you try with a current checkout?  Ronald
checked in lots of changes which I think include x86 support
at svn rev 45997.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1486897&group_id=5470

From noreply at sourceforge.net  Tue May 23 13:27:49 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 23 May 2006 04:27:49 -0700
Subject: [ python-Bugs-1486897 ] OS X framework build for python 2.5 fails,
	configure is odd
Message-ID: <E1FiV3F-0002zr-Kk@sc8-sf-web3.sourceforge.net>

Bugs item #1486897, was opened at 2006-05-11 23:44
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1486897&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: Christopher Knox (vizowl)
Assigned to: Ronald Oussoren (ronaldoussoren)
Summary: OS X framework build for python 2.5 fails, configure is odd

Initial Comment:
The OS X framework build for python 2.5 does not install a dynamic 
library at /Library/Frameworks/Python.framework/Versions/2.5/Python 
where it should. The python2.5 executible does not run because it is 
trying to load this dynamic library.

This is on an intel mac with darwin-8.6.1 and gcc4 and python2.5a2.

Also all of the extra modules (_CG extension, IDLE extra) fail to link 
because their link command is -lpython2.5 which is not what it should be 
for a framework build and even if it was correct for linking agianst a 
framework it would fil because the framework doesn't have its library 
anyway.

Finally, the configure script behaves oddly in that it works fine, but if you 
change the parameters and rerun it it will fail unless you run 'make 
distclean'

This is where it fails.

checking whether mmap with MAP_ANON(YMOUS) works... yes
configure: error: "libffi has not been ported to i686-apple-darwin8.6.1."
Failed to configure _ctypes module

----------------------------------------------------------------------

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-05-23 13:27

Message:
Logged In: YES 
user_id=580910

I'm currently building the trunk and I'm seeing the same issue as you. The 
problem is caused by the checkin at revision 45232 by Martin van Loewis. This 
forces '-lpython2.5' onto the commandline for the linker when building 
extensions.

I'm working on a patch that disables this feature for framework builds.


----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-05-23 13:07

Message:
Logged In: YES 
user_id=580910

The configure failure in the orginal message is not a problem, that's libffi failing. 
Libffi is used by ctypes and not supported on darwin/x86. I have a patch and I 
know of another one, but neither have been merged into the copy that's used by 
ctypes. The only effect of this is that you won't get ctypes.

Could you test  again without --enable-profiling? That's one flag I've never used 
and didn't test yet. BTW. the attached build log contains lots of NUL bytes, 
should it or has it been corrupted along the way?

----------------------------------------------------------------------

Comment By: Christopher Knox (vizowl)
Date: 2006-05-15 19:13

Message:
Logged In: YES 
user_id=1346203

Hi Neal,

I checked out rev 46003 (the HEAD at the time) in a clean directory and used: 

./configure --enable-profiling --enable-shared --enable-framework --
enable-universalsdk

Unfortunately it failed in the same way it has the same problems in that it is 
linking with the flag -lpython2.5 when it should be a framework linking. I 
have attached the build log from after having built it once so you only see the 
linking.

However, it does appear that the issue raised in bug # 1487105 is solved. It 
compiled fine on an intel mac it just has linking problems.

Also I get exactly the same problem on a G5

Chris

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-05-15 08:25

Message:
Logged In: YES 
user_id=33168

Christopher can you try with a current checkout?  Ronald
checked in lots of changes which I think include x86 support
at svn rev 45997.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1486897&group_id=5470

From noreply at sourceforge.net  Tue May 23 13:47:56 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 23 May 2006 04:47:56 -0700
Subject: [ python-Bugs-1487105 ] 2.5 rev 45972 fails build on Mac-Intel
Message-ID: <E1FiVMi-0001JM-89@sc8-sf-web3.sourceforge.net>

Bugs item #1487105, was opened at 2006-05-12 07:51
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1487105&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: 7
Submitted By: Alex Martelli (aleax)
Assigned to: Alex Martelli (aleax)
Summary: 2.5 rev 45972 fails build on Mac-Intel

Initial Comment:
brain:~/py25 alex$ make
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes   Parser/acceler.o 
Parser/grammar1.o Parser/listnode.o Parser/node.o Parser/parser.o 
Parser/parsetok.o Parser/bitset.o Parser/metagrammar.o Parser/
firstsets.o Parser/grammar.o Parser/pgen.o Objects/obmalloc.o Python/
mysnprintf.o Parser/tokenizer_pgen.o Parser/printgrammar.o Parser/
pgenmain.o -ldl  -o Parser/pgen
/usr/bin/ld: warning Parser/printgrammar.o cputype (18, architecture 
ppc) does not match cputype (7) for specified -arch flag: i386 (file not 
loaded)
/usr/bin/ld: Undefined symbols:
__Py_printgrammar
__Py_printnonterminals
collect2: ld returned 1 exit status
make: *** [Parser/pgen] Error 1
brain:~/py25 alex$ 

This is a MacBook Pro with gcc version 4.0.1 (Apple Computer, Inc. build 
5250) -- not sure why there's an "architecture ppc" found somewhere, 
haven't looked at it in detail yet, but at any rate this breaks the make.


Alex


----------------------------------------------------------------------

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-05-23 13:47

Message:
Logged In: YES 
user_id=580910

I've checked in a fix in revision 46103. Could you please test if this solves the 
problems for you?


----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-05-19 12:38

Message:
Logged In: YES 
user_id=580910

It seems to work for me (current trunk). Feel free to assign this to me if it 
doesn't work for you.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-05-15 08:23

Message:
Logged In: YES 
user_id=33168

Alex, can you try with a current checkout?  It looks like
Ronald checked in fixes for x86 at 45997.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1487105&group_id=5470

From noreply at sourceforge.net  Tue May 23 14:12:35 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 23 May 2006 05:12:35 -0700
Subject: [ python-Bugs-1487105 ] 2.5 rev 45972 fails build on Mac-Intel
Message-ID: <E1FiVkZ-0005Rx-SP@sc8-sf-web2.sourceforge.net>

Bugs item #1487105, was opened at 2006-05-12 07:51
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1487105&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: 7
Submitted By: Alex Martelli (aleax)
Assigned to: Alex Martelli (aleax)
Summary: 2.5 rev 45972 fails build on Mac-Intel

Initial Comment:
brain:~/py25 alex$ make
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes   Parser/acceler.o 
Parser/grammar1.o Parser/listnode.o Parser/node.o Parser/parser.o 
Parser/parsetok.o Parser/bitset.o Parser/metagrammar.o Parser/
firstsets.o Parser/grammar.o Parser/pgen.o Objects/obmalloc.o Python/
mysnprintf.o Parser/tokenizer_pgen.o Parser/printgrammar.o Parser/
pgenmain.o -ldl  -o Parser/pgen
/usr/bin/ld: warning Parser/printgrammar.o cputype (18, architecture 
ppc) does not match cputype (7) for specified -arch flag: i386 (file not 
loaded)
/usr/bin/ld: Undefined symbols:
__Py_printgrammar
__Py_printnonterminals
collect2: ld returned 1 exit status
make: *** [Parser/pgen] Error 1
brain:~/py25 alex$ 

This is a MacBook Pro with gcc version 4.0.1 (Apple Computer, Inc. build 
5250) -- not sure why there's an "architecture ppc" found somewhere, 
haven't looked at it in detail yet, but at any rate this breaks the make.


Alex


----------------------------------------------------------------------

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-05-23 14:12

Message:
Logged In: YES 
user_id=580910

Never mind, wrong bug. I would like to hear if the trunk works for you though.

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-05-23 13:47

Message:
Logged In: YES 
user_id=580910

I've checked in a fix in revision 46103. Could you please test if this solves the 
problems for you?


----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-05-19 12:38

Message:
Logged In: YES 
user_id=580910

It seems to work for me (current trunk). Feel free to assign this to me if it 
doesn't work for you.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-05-15 08:23

Message:
Logged In: YES 
user_id=33168

Alex, can you try with a current checkout?  It looks like
Ronald checked in fixes for x86 at 45997.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1487105&group_id=5470

From noreply at sourceforge.net  Tue May 23 14:13:17 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 23 May 2006 05:13:17 -0700
Subject: [ python-Bugs-1486897 ] OS X framework build for python 2.5 fails,
	configure is odd
Message-ID: <E1FiVlF-0007MB-9T@sc8-sf-web4-b.sourceforge.net>

Bugs item #1486897, was opened at 2006-05-11 23:44
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1486897&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: 5
Submitted By: Christopher Knox (vizowl)
Assigned to: Ronald Oussoren (ronaldoussoren)
Summary: OS X framework build for python 2.5 fails, configure is odd

Initial Comment:
The OS X framework build for python 2.5 does not install a dynamic 
library at /Library/Frameworks/Python.framework/Versions/2.5/Python 
where it should. The python2.5 executible does not run because it is 
trying to load this dynamic library.

This is on an intel mac with darwin-8.6.1 and gcc4 and python2.5a2.

Also all of the extra modules (_CG extension, IDLE extra) fail to link 
because their link command is -lpython2.5 which is not what it should be 
for a framework build and even if it was correct for linking agianst a 
framework it would fil because the framework doesn't have its library 
anyway.

Finally, the configure script behaves oddly in that it works fine, but if you 
change the parameters and rerun it it will fail unless you run 'make 
distclean'

This is where it fails.

checking whether mmap with MAP_ANON(YMOUS) works... yes
configure: error: "libffi has not been ported to i686-apple-darwin8.6.1."
Failed to configure _ctypes module

----------------------------------------------------------------------

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-05-23 14:13

Message:
Logged In: YES 
user_id=580910

I've checked in a fix in revision 46103. Could you please test if this solves the 
problems for you?

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-05-23 13:27

Message:
Logged In: YES 
user_id=580910

I'm currently building the trunk and I'm seeing the same issue as you. The 
problem is caused by the checkin at revision 45232 by Martin van Loewis. This 
forces '-lpython2.5' onto the commandline for the linker when building 
extensions.

I'm working on a patch that disables this feature for framework builds.


----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-05-23 13:07

Message:
Logged In: YES 
user_id=580910

The configure failure in the orginal message is not a problem, that's libffi failing. 
Libffi is used by ctypes and not supported on darwin/x86. I have a patch and I 
know of another one, but neither have been merged into the copy that's used by 
ctypes. The only effect of this is that you won't get ctypes.

Could you test  again without --enable-profiling? That's one flag I've never used 
and didn't test yet. BTW. the attached build log contains lots of NUL bytes, 
should it or has it been corrupted along the way?

----------------------------------------------------------------------

Comment By: Christopher Knox (vizowl)
Date: 2006-05-15 19:13

Message:
Logged In: YES 
user_id=1346203

Hi Neal,

I checked out rev 46003 (the HEAD at the time) in a clean directory and used: 

./configure --enable-profiling --enable-shared --enable-framework --
enable-universalsdk

Unfortunately it failed in the same way it has the same problems in that it is 
linking with the flag -lpython2.5 when it should be a framework linking. I 
have attached the build log from after having built it once so you only see the 
linking.

However, it does appear that the issue raised in bug # 1487105 is solved. It 
compiled fine on an intel mac it just has linking problems.

Also I get exactly the same problem on a G5

Chris

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-05-15 08:25

Message:
Logged In: YES 
user_id=33168

Christopher can you try with a current checkout?  Ronald
checked in lots of changes which I think include x86 support
at svn rev 45997.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1486897&group_id=5470

From noreply at sourceforge.net  Tue May 23 14:51:31 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 23 May 2006 05:51:31 -0700
Subject: [ python-Bugs-1451717 ] OS/X on i386 framework build
Message-ID: <E1FiWMF-0001d9-Gw@sc8-sf-web3.sourceforge.net>

Bugs item #1451717, was opened at 2006-03-16 23:22
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1451717&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.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Ian Holsman (webperf)
Assigned to: Nobody/Anonymous (nobody)
Summary: OS/X on i386 framework build

Initial Comment:
in Makefile.pre (374) it hard codes the architecture to
'ppc' which isn't correct for the new x86 boxes.

this needs to be i386 for the framework install to
actually build on the new macs.

regards
Ian

----------------------------------------------------------------------

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-05-23 14:51

Message:
Logged In: YES 
user_id=580910

This has been fixed on the trunk. I'll backport this to 2.4.x in the near future.

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-17 16:07

Message:
Logged In: YES 
user_id=580910

BTW. The 'also' bit has been fixed in the trunk.

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-02 21:21

Message:
Logged In: YES 
user_id=580910

This is a duplicate of bug 1447587 <http://www.python.org/sf/1447587> 

----------------------------------------------------------------------

Comment By: Ian Holsman (webperf)
Date: 2006-03-16 23:34

Message:
Logged In: YES 
user_id=5209

also..
in plat-mac/applesingle.py the fields
AS_HEADER_FORMAT
and 
AS_ENTRY_FORMAT
need a '>' infront of the definitions
AS_HEADER_FORMAT=">LL16sh"
AS_ENTRY_FORMAT=">lll"
(this is what the system-packaged python has.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1451717&group_id=5470

From noreply at sourceforge.net  Tue May 23 17:41:26 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 23 May 2006 08:41:26 -0700
Subject: [ python-Bugs-1486897 ] OS X framework build for python 2.5 fails,
	configure is odd
Message-ID: <E1FiZ0g-0000Sx-RW@sc8-sf-web4-b.sourceforge.net>

Bugs item #1486897, was opened at 2006-05-11 14:44
Message generated for change (Comment added) made by vizowl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1486897&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: 5
Submitted By: Christopher Knox (vizowl)
Assigned to: Ronald Oussoren (ronaldoussoren)
Summary: OS X framework build for python 2.5 fails, configure is odd

Initial Comment:
The OS X framework build for python 2.5 does not install a dynamic 
library at /Library/Frameworks/Python.framework/Versions/2.5/Python 
where it should. The python2.5 executible does not run because it is 
trying to load this dynamic library.

This is on an intel mac with darwin-8.6.1 and gcc4 and python2.5a2.

Also all of the extra modules (_CG extension, IDLE extra) fail to link 
because their link command is -lpython2.5 which is not what it should be 
for a framework build and even if it was correct for linking agianst a 
framework it would fil because the framework doesn't have its library 
anyway.

Finally, the configure script behaves oddly in that it works fine, but if you 
change the parameters and rerun it it will fail unless you run 'make 
distclean'

This is where it fails.

checking whether mmap with MAP_ANON(YMOUS) works... yes
configure: error: "libffi has not been ported to i686-apple-darwin8.6.1."
Failed to configure _ctypes module

----------------------------------------------------------------------

>Comment By: Christopher Knox (vizowl)
Date: 2006-05-23 08:41

Message:
Logged In: YES 
user_id=1346203

I checked out rev 46110 and it is almost fixed.

It builds correctly now - however the make install (or altinstall) does not copy 
the dynamic library into the framework. It is built into BUILD_ROOT/
Python.Framework/Versions/2.5/Python and after installation it should land 
up in /Library/Frameworks/Python.framework/Versions/2.5/Python - but 
nothing is there. If I copy it over manually then the python2.5 interpeter will 
run.

The 2.4 framework has a symlink from /Library/Frameworks/
Python.framework/Python to /Library/Frameworks/Python.framework/
Versions/2.4/Python

The rest of my comment is more of an aside than a bug...

The equivalent symlink exists in the built version of the 2.5 framework and it 
chould not (and does not currently) get transferred into /Library/
Frameworks/Python.framework. However, if someone wanted to upgrade 
from python2.4 to 2.5 then the symlink should also be updated - otherwise 
when people add the linker flag -framework Python to their builds it will keep 
linking against the 2.4 dynamic lib.

Also I am not sure what happened with the build log - it is fine when I 
download it - but it doesn't matter now

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-05-23 05:13

Message:
Logged In: YES 
user_id=580910

I've checked in a fix in revision 46103. Could you please test if this solves the 
problems for you?

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-05-23 04:27

Message:
Logged In: YES 
user_id=580910

I'm currently building the trunk and I'm seeing the same issue as you. The 
problem is caused by the checkin at revision 45232 by Martin van Loewis. This 
forces '-lpython2.5' onto the commandline for the linker when building 
extensions.

I'm working on a patch that disables this feature for framework builds.


----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-05-23 04:07

Message:
Logged In: YES 
user_id=580910

The configure failure in the orginal message is not a problem, that's libffi failing. 
Libffi is used by ctypes and not supported on darwin/x86. I have a patch and I 
know of another one, but neither have been merged into the copy that's used by 
ctypes. The only effect of this is that you won't get ctypes.

Could you test  again without --enable-profiling? That's one flag I've never used 
and didn't test yet. BTW. the attached build log contains lots of NUL bytes, 
should it or has it been corrupted along the way?

----------------------------------------------------------------------

Comment By: Christopher Knox (vizowl)
Date: 2006-05-15 10:13

Message:
Logged In: YES 
user_id=1346203

Hi Neal,

I checked out rev 46003 (the HEAD at the time) in a clean directory and used: 

./configure --enable-profiling --enable-shared --enable-framework --
enable-universalsdk

Unfortunately it failed in the same way it has the same problems in that it is 
linking with the flag -lpython2.5 when it should be a framework linking. I 
have attached the build log from after having built it once so you only see the 
linking.

However, it does appear that the issue raised in bug # 1487105 is solved. It 
compiled fine on an intel mac it just has linking problems.

Also I get exactly the same problem on a G5

Chris

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-05-14 23:25

Message:
Logged In: YES 
user_id=33168

Christopher can you try with a current checkout?  Ronald
checked in lots of changes which I think include x86 support
at svn rev 45997.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1486897&group_id=5470

From noreply at sourceforge.net  Tue May 23 17:58:26 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 23 May 2006 08:58:26 -0700
Subject: [ python-Bugs-1493676 ] time.strftime() %z error
Message-ID: <E1FiZH8-0004dU-54@sc8-sf-web4-b.sourceforge.net>

Bugs item #1493676, was opened at 2006-05-23 16:58
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=1493676&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: Cillian Sharkey (csharkey)
Assigned to: Nobody/Anonymous (nobody)
Summary: time.strftime() %z error

Initial Comment:
According to the time module documentation, if the time
argument for strftime() is not provided, it will use
the current time as returned by localtime().

However, when the value of localtime() is explicitly
given to strftime(), this produces an error in the
value of the timezone offset (%z) as seen here:

>>> from time import *
>>> strftime("%a %b %e %H:%M:%S %Y %Z %z")
'Tue May 23 16:28:31 2006 IST +0100'
>>> strftime("%a %b %e %H:%M:%S %Y %Z %z", localtime())
'Tue May 23 16:28:31 2006 IST +0000'

This same problem happens for other timezones (the
offset is always +0000 when localtime() is explicitly
given).

This problem is present in both these versions:

Python 2.4.2 (#2, Sep 30 2005, 21:19:01)
[GCC 4.0.2 20050808 (prerelease) (Ubuntu
4.0.1-4ubuntu8)] on linux2

Python 2.3.5 (#2, Sep  4 2005, 22:01:42)
[GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1493676&group_id=5470

From noreply at sourceforge.net  Tue May 23 18:26:55 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 23 May 2006 09:26:55 -0700
Subject: [ python-Bugs-1486897 ] OS X framework build for python 2.5 fails,
	configure is odd
Message-ID: <E1FiZih-0004MW-DI@sc8-sf-web4-b.sourceforge.net>

Bugs item #1486897, was opened at 2006-05-11 23:44
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1486897&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: 5
Submitted By: Christopher Knox (vizowl)
Assigned to: Ronald Oussoren (ronaldoussoren)
Summary: OS X framework build for python 2.5 fails, configure is odd

Initial Comment:
The OS X framework build for python 2.5 does not install a dynamic 
library at /Library/Frameworks/Python.framework/Versions/2.5/Python 
where it should. The python2.5 executible does not run because it is 
trying to load this dynamic library.

This is on an intel mac with darwin-8.6.1 and gcc4 and python2.5a2.

Also all of the extra modules (_CG extension, IDLE extra) fail to link 
because their link command is -lpython2.5 which is not what it should be 
for a framework build and even if it was correct for linking agianst a 
framework it would fil because the framework doesn't have its library 
anyway.

Finally, the configure script behaves oddly in that it works fine, but if you 
change the parameters and rerun it it will fail unless you run 'make 
distclean'

This is where it fails.

checking whether mmap with MAP_ANON(YMOUS) works... yes
configure: error: "libffi has not been ported to i686-apple-darwin8.6.1."
Failed to configure _ctypes module

----------------------------------------------------------------------

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-05-23 18:26

Message:
Logged In: YES 
user_id=580910

You shouldn't use make install, but make frameworkinstall.  This is documented 
in Mac/OSX/README.

I wouldn't mind seeing a patch that makes it possible to install a framework 
using 'make install', but that's very low on my todo-list.

----------------------------------------------------------------------

Comment By: Christopher Knox (vizowl)
Date: 2006-05-23 17:41

Message:
Logged In: YES 
user_id=1346203

I checked out rev 46110 and it is almost fixed.

It builds correctly now - however the make install (or altinstall) does not copy 
the dynamic library into the framework. It is built into BUILD_ROOT/
Python.Framework/Versions/2.5/Python and after installation it should land 
up in /Library/Frameworks/Python.framework/Versions/2.5/Python - but 
nothing is there. If I copy it over manually then the python2.5 interpeter will 
run.

The 2.4 framework has a symlink from /Library/Frameworks/
Python.framework/Python to /Library/Frameworks/Python.framework/
Versions/2.4/Python

The rest of my comment is more of an aside than a bug...

The equivalent symlink exists in the built version of the 2.5 framework and it 
chould not (and does not currently) get transferred into /Library/
Frameworks/Python.framework. However, if someone wanted to upgrade 
from python2.4 to 2.5 then the symlink should also be updated - otherwise 
when people add the linker flag -framework Python to their builds it will keep 
linking against the 2.4 dynamic lib.

Also I am not sure what happened with the build log - it is fine when I 
download it - but it doesn't matter now

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-05-23 14:13

Message:
Logged In: YES 
user_id=580910

I've checked in a fix in revision 46103. Could you please test if this solves the 
problems for you?

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-05-23 13:27

Message:
Logged In: YES 
user_id=580910

I'm currently building the trunk and I'm seeing the same issue as you. The 
problem is caused by the checkin at revision 45232 by Martin van Loewis. This 
forces '-lpython2.5' onto the commandline for the linker when building 
extensions.

I'm working on a patch that disables this feature for framework builds.


----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-05-23 13:07

Message:
Logged In: YES 
user_id=580910

The configure failure in the orginal message is not a problem, that's libffi failing. 
Libffi is used by ctypes and not supported on darwin/x86. I have a patch and I 
know of another one, but neither have been merged into the copy that's used by 
ctypes. The only effect of this is that you won't get ctypes.

Could you test  again without --enable-profiling? That's one flag I've never used 
and didn't test yet. BTW. the attached build log contains lots of NUL bytes, 
should it or has it been corrupted along the way?

----------------------------------------------------------------------

Comment By: Christopher Knox (vizowl)
Date: 2006-05-15 19:13

Message:
Logged In: YES 
user_id=1346203

Hi Neal,

I checked out rev 46003 (the HEAD at the time) in a clean directory and used: 

./configure --enable-profiling --enable-shared --enable-framework --
enable-universalsdk

Unfortunately it failed in the same way it has the same problems in that it is 
linking with the flag -lpython2.5 when it should be a framework linking. I 
have attached the build log from after having built it once so you only see the 
linking.

However, it does appear that the issue raised in bug # 1487105 is solved. It 
compiled fine on an intel mac it just has linking problems.

Also I get exactly the same problem on a G5

Chris

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-05-15 08:25

Message:
Logged In: YES 
user_id=33168

Christopher can you try with a current checkout?  Ronald
checked in lots of changes which I think include x86 support
at svn rev 45997.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1486897&group_id=5470

From noreply at sourceforge.net  Tue May 23 18:54:50 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 23 May 2006 09:54:50 -0700
Subject: [ python-Bugs-1486897 ] OS X framework build for python 2.5 fails,
	configure is odd
Message-ID: <E1Fia9i-0003u2-A0@sc8-sf-web4-b.sourceforge.net>

Bugs item #1486897, was opened at 2006-05-11 14:44
Message generated for change (Comment added) made by vizowl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1486897&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: 5
Submitted By: Christopher Knox (vizowl)
Assigned to: Ronald Oussoren (ronaldoussoren)
Summary: OS X framework build for python 2.5 fails, configure is odd

Initial Comment:
The OS X framework build for python 2.5 does not install a dynamic 
library at /Library/Frameworks/Python.framework/Versions/2.5/Python 
where it should. The python2.5 executible does not run because it is 
trying to load this dynamic library.

This is on an intel mac with darwin-8.6.1 and gcc4 and python2.5a2.

Also all of the extra modules (_CG extension, IDLE extra) fail to link 
because their link command is -lpython2.5 which is not what it should be 
for a framework build and even if it was correct for linking agianst a 
framework it would fil because the framework doesn't have its library 
anyway.

Finally, the configure script behaves oddly in that it works fine, but if you 
change the parameters and rerun it it will fail unless you run 'make 
distclean'

This is where it fails.

checking whether mmap with MAP_ANON(YMOUS) works... yes
configure: error: "libffi has not been ported to i686-apple-darwin8.6.1."
Failed to configure _ctypes module

----------------------------------------------------------------------

>Comment By: Christopher Knox (vizowl)
Date: 2006-05-23 09:54

Message:
Logged In: YES 
user_id=1346203

Sorry - it was too early in the morning here and I forgot about the 
frameworkinstall....

The frameworkinstall does not quite work.

It looks like it installs everything critical and then fails on the MacPython 
stuff. Specifically, it fails here:

/usr/bin/install -c -s ../../python.exe "/Library/Frameworks/
Python.framework/Versions/2.5/Resources/Python.app/Contents/MacOS/
Python"
../../python.exe ./../scripts/BuildApplet.py \
--destroot "" \
        --python /Library/Frameworks/Python.framework/Versions/2.5/
Resources/Python.app/Contents/MacOS/Python \
        --output "/Applications/MacPython 2.5/Build Applet.app" \
        ./../scripts/BuildApplet.py
make[1]: *** [install_BuildApplet] Bus error
make: *** [frameworkinstallapps] Error 2

However, I can still run the python interpeter - although when I exit the 
interpretor it says "mcount: gmon.out: Permission denied"

frameworkinstall does overwrite the Current symlink - but I just fixed it 
manually.

Also I noticed that make clean does not remove the actual dynamic library 
called 'Python' from the Python.framework directory in the build directory

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-05-23 09:26

Message:
Logged In: YES 
user_id=580910

You shouldn't use make install, but make frameworkinstall.  This is documented 
in Mac/OSX/README.

I wouldn't mind seeing a patch that makes it possible to install a framework 
using 'make install', but that's very low on my todo-list.

----------------------------------------------------------------------

Comment By: Christopher Knox (vizowl)
Date: 2006-05-23 08:41

Message:
Logged In: YES 
user_id=1346203

I checked out rev 46110 and it is almost fixed.

It builds correctly now - however the make install (or altinstall) does not copy 
the dynamic library into the framework. It is built into BUILD_ROOT/
Python.Framework/Versions/2.5/Python and after installation it should land 
up in /Library/Frameworks/Python.framework/Versions/2.5/Python - but 
nothing is there. If I copy it over manually then the python2.5 interpeter will 
run.

The 2.4 framework has a symlink from /Library/Frameworks/
Python.framework/Python to /Library/Frameworks/Python.framework/
Versions/2.4/Python

The rest of my comment is more of an aside than a bug...

The equivalent symlink exists in the built version of the 2.5 framework and it 
chould not (and does not currently) get transferred into /Library/
Frameworks/Python.framework. However, if someone wanted to upgrade 
from python2.4 to 2.5 then the symlink should also be updated - otherwise 
when people add the linker flag -framework Python to their builds it will keep 
linking against the 2.4 dynamic lib.

Also I am not sure what happened with the build log - it is fine when I 
download it - but it doesn't matter now

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-05-23 05:13

Message:
Logged In: YES 
user_id=580910

I've checked in a fix in revision 46103. Could you please test if this solves the 
problems for you?

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-05-23 04:27

Message:
Logged In: YES 
user_id=580910

I'm currently building the trunk and I'm seeing the same issue as you. The 
problem is caused by the checkin at revision 45232 by Martin van Loewis. This 
forces '-lpython2.5' onto the commandline for the linker when building 
extensions.

I'm working on a patch that disables this feature for framework builds.


----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-05-23 04:07

Message:
Logged In: YES 
user_id=580910

The configure failure in the orginal message is not a problem, that's libffi failing. 
Libffi is used by ctypes and not supported on darwin/x86. I have a patch and I 
know of another one, but neither have been merged into the copy that's used by 
ctypes. The only effect of this is that you won't get ctypes.

Could you test  again without --enable-profiling? That's one flag I've never used 
and didn't test yet. BTW. the attached build log contains lots of NUL bytes, 
should it or has it been corrupted along the way?

----------------------------------------------------------------------

Comment By: Christopher Knox (vizowl)
Date: 2006-05-15 10:13

Message:
Logged In: YES 
user_id=1346203

Hi Neal,

I checked out rev 46003 (the HEAD at the time) in a clean directory and used: 

./configure --enable-profiling --enable-shared --enable-framework --
enable-universalsdk

Unfortunately it failed in the same way it has the same problems in that it is 
linking with the flag -lpython2.5 when it should be a framework linking. I 
have attached the build log from after having built it once so you only see the 
linking.

However, it does appear that the issue raised in bug # 1487105 is solved. It 
compiled fine on an intel mac it just has linking problems.

Also I get exactly the same problem on a G5

Chris

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-05-14 23:25

Message:
Logged In: YES 
user_id=33168

Christopher can you try with a current checkout?  Ronald
checked in lots of changes which I think include x86 support
at svn rev 45997.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1486897&group_id=5470

From noreply at sourceforge.net  Tue May 23 18:58:34 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 23 May 2006 09:58:34 -0700
Subject: [ python-Bugs-1493676 ] time.strftime() %z error
Message-ID: <E1FiaDK-000521-4B@sc8-sf-web4-b.sourceforge.net>

Bugs item #1493676, was opened at 2006-05-23 15:58
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1493676&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: Cillian Sharkey (csharkey)
Assigned to: Nobody/Anonymous (nobody)
Summary: time.strftime() %z error

Initial Comment:
According to the time module documentation, if the time
argument for strftime() is not provided, it will use
the current time as returned by localtime().

However, when the value of localtime() is explicitly
given to strftime(), this produces an error in the
value of the timezone offset (%z) as seen here:

>>> from time import *
>>> strftime("%a %b %e %H:%M:%S %Y %Z %z")
'Tue May 23 16:28:31 2006 IST +0100'
>>> strftime("%a %b %e %H:%M:%S %Y %Z %z", localtime())
'Tue May 23 16:28:31 2006 IST +0000'

This same problem happens for other timezones (the
offset is always +0000 when localtime() is explicitly
given).

This problem is present in both these versions:

Python 2.4.2 (#2, Sep 30 2005, 21:19:01)
[GCC 4.0.2 20050808 (prerelease) (Ubuntu
4.0.1-4ubuntu8)] on linux2

Python 2.3.5 (#2, Sep  4 2005, 22:01:42)
[GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2


----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-05-23 16:58

Message:
Logged In: YES 
user_id=849994

Note that %z isn't officially supported by Python, judging
by the docs.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1493676&group_id=5470

From noreply at sourceforge.net  Tue May 23 19:44:15 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 23 May 2006 10:44:15 -0700
Subject: [ python-Bugs-1486897 ] OS X framework build for python 2.5 fails,
	configure is odd
Message-ID: <E1FiavX-0002Lz-9W@sc8-sf-web4-b.sourceforge.net>

Bugs item #1486897, was opened at 2006-05-11 23:44
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1486897&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: 5
Submitted By: Christopher Knox (vizowl)
Assigned to: Ronald Oussoren (ronaldoussoren)
Summary: OS X framework build for python 2.5 fails, configure is odd

Initial Comment:
The OS X framework build for python 2.5 does not install a dynamic 
library at /Library/Frameworks/Python.framework/Versions/2.5/Python 
where it should. The python2.5 executible does not run because it is 
trying to load this dynamic library.

This is on an intel mac with darwin-8.6.1 and gcc4 and python2.5a2.

Also all of the extra modules (_CG extension, IDLE extra) fail to link 
because their link command is -lpython2.5 which is not what it should be 
for a framework build and even if it was correct for linking agianst a 
framework it would fil because the framework doesn't have its library 
anyway.

Finally, the configure script behaves oddly in that it works fine, but if you 
change the parameters and rerun it it will fail unless you run 'make 
distclean'

This is where it fails.

checking whether mmap with MAP_ANON(YMOUS) works... yes
configure: error: "libffi has not been ported to i686-apple-darwin8.6.1."
Failed to configure _ctypes module

----------------------------------------------------------------------

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-05-23 19:44

Message:
Logged In: YES 
user_id=580910

Why do you try to use --enable-profiling with a framework install? Whenever I 
need such a special build I generally install a normal unix build in a 
temporary location.

I know --enable-framework doesn't clean up after itself. It does work 
correctly in a seperate build directory though, that way you can just dump the 
build directory to clean up.

BTW. Integrating 'make frameworkinstall' into 'make install' seems to be 
pretty easy, I might check in a patch later this week.

--enable-profiling crashes for me too, I don't have time to look into this at 
the moment.

----------------------------------------------------------------------

Comment By: Christopher Knox (vizowl)
Date: 2006-05-23 18:54

Message:
Logged In: YES 
user_id=1346203

Sorry - it was too early in the morning here and I forgot about the 
frameworkinstall....

The frameworkinstall does not quite work.

It looks like it installs everything critical and then fails on the MacPython 
stuff. Specifically, it fails here:

/usr/bin/install -c -s ../../python.exe "/Library/Frameworks/
Python.framework/Versions/2.5/Resources/Python.app/Contents/MacOS/
Python"
../../python.exe ./../scripts/BuildApplet.py \
--destroot "" \
        --python /Library/Frameworks/Python.framework/Versions/2.5/
Resources/Python.app/Contents/MacOS/Python \
        --output "/Applications/MacPython 2.5/Build Applet.app" \
        ./../scripts/BuildApplet.py
make[1]: *** [install_BuildApplet] Bus error
make: *** [frameworkinstallapps] Error 2

However, I can still run the python interpeter - although when I exit the 
interpretor it says "mcount: gmon.out: Permission denied"

frameworkinstall does overwrite the Current symlink - but I just fixed it 
manually.

Also I noticed that make clean does not remove the actual dynamic library 
called 'Python' from the Python.framework directory in the build directory

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-05-23 18:26

Message:
Logged In: YES 
user_id=580910

You shouldn't use make install, but make frameworkinstall.  This is documented 
in Mac/OSX/README.

I wouldn't mind seeing a patch that makes it possible to install a framework 
using 'make install', but that's very low on my todo-list.

----------------------------------------------------------------------

Comment By: Christopher Knox (vizowl)
Date: 2006-05-23 17:41

Message:
Logged In: YES 
user_id=1346203

I checked out rev 46110 and it is almost fixed.

It builds correctly now - however the make install (or altinstall) does not copy 
the dynamic library into the framework. It is built into BUILD_ROOT/
Python.Framework/Versions/2.5/Python and after installation it should land 
up in /Library/Frameworks/Python.framework/Versions/2.5/Python - but 
nothing is there. If I copy it over manually then the python2.5 interpeter will 
run.

The 2.4 framework has a symlink from /Library/Frameworks/
Python.framework/Python to /Library/Frameworks/Python.framework/
Versions/2.4/Python

The rest of my comment is more of an aside than a bug...

The equivalent symlink exists in the built version of the 2.5 framework and it 
chould not (and does not currently) get transferred into /Library/
Frameworks/Python.framework. However, if someone wanted to upgrade 
from python2.4 to 2.5 then the symlink should also be updated - otherwise 
when people add the linker flag -framework Python to their builds it will keep 
linking against the 2.4 dynamic lib.

Also I am not sure what happened with the build log - it is fine when I 
download it - but it doesn't matter now

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-05-23 14:13

Message:
Logged In: YES 
user_id=580910

I've checked in a fix in revision 46103. Could you please test if this solves the 
problems for you?

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-05-23 13:27

Message:
Logged In: YES 
user_id=580910

I'm currently building the trunk and I'm seeing the same issue as you. The 
problem is caused by the checkin at revision 45232 by Martin van Loewis. This 
forces '-lpython2.5' onto the commandline for the linker when building 
extensions.

I'm working on a patch that disables this feature for framework builds.


----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-05-23 13:07

Message:
Logged In: YES 
user_id=580910

The configure failure in the orginal message is not a problem, that's libffi failing. 
Libffi is used by ctypes and not supported on darwin/x86. I have a patch and I 
know of another one, but neither have been merged into the copy that's used by 
ctypes. The only effect of this is that you won't get ctypes.

Could you test  again without --enable-profiling? That's one flag I've never used 
and didn't test yet. BTW. the attached build log contains lots of NUL bytes, 
should it or has it been corrupted along the way?

----------------------------------------------------------------------

Comment By: Christopher Knox (vizowl)
Date: 2006-05-15 19:13

Message:
Logged In: YES 
user_id=1346203

Hi Neal,

I checked out rev 46003 (the HEAD at the time) in a clean directory and used: 

./configure --enable-profiling --enable-shared --enable-framework --
enable-universalsdk

Unfortunately it failed in the same way it has the same problems in that it is 
linking with the flag -lpython2.5 when it should be a framework linking. I 
have attached the build log from after having built it once so you only see the 
linking.

However, it does appear that the issue raised in bug # 1487105 is solved. It 
compiled fine on an intel mac it just has linking problems.

Also I get exactly the same problem on a G5

Chris

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-05-15 08:25

Message:
Logged In: YES 
user_id=33168

Christopher can you try with a current checkout?  Ronald
checked in lots of changes which I think include x86 support
at svn rev 45997.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1486897&group_id=5470

From noreply at sourceforge.net  Tue May 23 20:11:55 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 23 May 2006 11:11:55 -0700
Subject: [ python-Bugs-1486897 ] OS X framework build for python 2.5 fails,
	configure is odd
Message-ID: <E1FibMJ-0002Aq-Ht@sc8-sf-web4-b.sourceforge.net>

Bugs item #1486897, was opened at 2006-05-11 14:44
Message generated for change (Comment added) made by vizowl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1486897&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: 5
Submitted By: Christopher Knox (vizowl)
Assigned to: Ronald Oussoren (ronaldoussoren)
Summary: OS X framework build for python 2.5 fails, configure is odd

Initial Comment:
The OS X framework build for python 2.5 does not install a dynamic 
library at /Library/Frameworks/Python.framework/Versions/2.5/Python 
where it should. The python2.5 executible does not run because it is 
trying to load this dynamic library.

This is on an intel mac with darwin-8.6.1 and gcc4 and python2.5a2.

Also all of the extra modules (_CG extension, IDLE extra) fail to link 
because their link command is -lpython2.5 which is not what it should be 
for a framework build and even if it was correct for linking agianst a 
framework it would fil because the framework doesn't have its library 
anyway.

Finally, the configure script behaves oddly in that it works fine, but if you 
change the parameters and rerun it it will fail unless you run 'make 
distclean'

This is where it fails.

checking whether mmap with MAP_ANON(YMOUS) works... yes
configure: error: "libffi has not been ported to i686-apple-darwin8.6.1."
Failed to configure _ctypes module

----------------------------------------------------------------------

>Comment By: Christopher Knox (vizowl)
Date: 2006-05-23 11:11

Message:
Logged In: YES 
user_id=1346203

Yeah - it works fine without --enable-profiling - I forgot that you said not to 
use it. I fear I am being less than helpful today.



----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-05-23 10:44

Message:
Logged In: YES 
user_id=580910

Why do you try to use --enable-profiling with a framework install? Whenever I 
need such a special build I generally install a normal unix build in a 
temporary location.

I know --enable-framework doesn't clean up after itself. It does work 
correctly in a seperate build directory though, that way you can just dump the 
build directory to clean up.

BTW. Integrating 'make frameworkinstall' into 'make install' seems to be 
pretty easy, I might check in a patch later this week.

--enable-profiling crashes for me too, I don't have time to look into this at 
the moment.

----------------------------------------------------------------------

Comment By: Christopher Knox (vizowl)
Date: 2006-05-23 09:54

Message:
Logged In: YES 
user_id=1346203

Sorry - it was too early in the morning here and I forgot about the 
frameworkinstall....

The frameworkinstall does not quite work.

It looks like it installs everything critical and then fails on the MacPython 
stuff. Specifically, it fails here:

/usr/bin/install -c -s ../../python.exe "/Library/Frameworks/
Python.framework/Versions/2.5/Resources/Python.app/Contents/MacOS/
Python"
../../python.exe ./../scripts/BuildApplet.py \
--destroot "" \
        --python /Library/Frameworks/Python.framework/Versions/2.5/
Resources/Python.app/Contents/MacOS/Python \
        --output "/Applications/MacPython 2.5/Build Applet.app" \
        ./../scripts/BuildApplet.py
make[1]: *** [install_BuildApplet] Bus error
make: *** [frameworkinstallapps] Error 2

However, I can still run the python interpeter - although when I exit the 
interpretor it says "mcount: gmon.out: Permission denied"

frameworkinstall does overwrite the Current symlink - but I just fixed it 
manually.

Also I noticed that make clean does not remove the actual dynamic library 
called 'Python' from the Python.framework directory in the build directory

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-05-23 09:26

Message:
Logged In: YES 
user_id=580910

You shouldn't use make install, but make frameworkinstall.  This is documented 
in Mac/OSX/README.

I wouldn't mind seeing a patch that makes it possible to install a framework 
using 'make install', but that's very low on my todo-list.

----------------------------------------------------------------------

Comment By: Christopher Knox (vizowl)
Date: 2006-05-23 08:41

Message:
Logged In: YES 
user_id=1346203

I checked out rev 46110 and it is almost fixed.

It builds correctly now - however the make install (or altinstall) does not copy 
the dynamic library into the framework. It is built into BUILD_ROOT/
Python.Framework/Versions/2.5/Python and after installation it should land 
up in /Library/Frameworks/Python.framework/Versions/2.5/Python - but 
nothing is there. If I copy it over manually then the python2.5 interpeter will 
run.

The 2.4 framework has a symlink from /Library/Frameworks/
Python.framework/Python to /Library/Frameworks/Python.framework/
Versions/2.4/Python

The rest of my comment is more of an aside than a bug...

The equivalent symlink exists in the built version of the 2.5 framework and it 
chould not (and does not currently) get transferred into /Library/
Frameworks/Python.framework. However, if someone wanted to upgrade 
from python2.4 to 2.5 then the symlink should also be updated - otherwise 
when people add the linker flag -framework Python to their builds it will keep 
linking against the 2.4 dynamic lib.

Also I am not sure what happened with the build log - it is fine when I 
download it - but it doesn't matter now

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-05-23 05:13

Message:
Logged In: YES 
user_id=580910

I've checked in a fix in revision 46103. Could you please test if this solves the 
problems for you?

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-05-23 04:27

Message:
Logged In: YES 
user_id=580910

I'm currently building the trunk and I'm seeing the same issue as you. The 
problem is caused by the checkin at revision 45232 by Martin van Loewis. This 
forces '-lpython2.5' onto the commandline for the linker when building 
extensions.

I'm working on a patch that disables this feature for framework builds.


----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-05-23 04:07

Message:
Logged In: YES 
user_id=580910

The configure failure in the orginal message is not a problem, that's libffi failing. 
Libffi is used by ctypes and not supported on darwin/x86. I have a patch and I 
know of another one, but neither have been merged into the copy that's used by 
ctypes. The only effect of this is that you won't get ctypes.

Could you test  again without --enable-profiling? That's one flag I've never used 
and didn't test yet. BTW. the attached build log contains lots of NUL bytes, 
should it or has it been corrupted along the way?

----------------------------------------------------------------------

Comment By: Christopher Knox (vizowl)
Date: 2006-05-15 10:13

Message:
Logged In: YES 
user_id=1346203

Hi Neal,

I checked out rev 46003 (the HEAD at the time) in a clean directory and used: 

./configure --enable-profiling --enable-shared --enable-framework --
enable-universalsdk

Unfortunately it failed in the same way it has the same problems in that it is 
linking with the flag -lpython2.5 when it should be a framework linking. I 
have attached the build log from after having built it once so you only see the 
linking.

However, it does appear that the issue raised in bug # 1487105 is solved. It 
compiled fine on an intel mac it just has linking problems.

Also I get exactly the same problem on a G5

Chris

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-05-14 23:25

Message:
Logged In: YES 
user_id=33168

Christopher can you try with a current checkout?  Ronald
checked in lots of changes which I think include x86 support
at svn rev 45997.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1486897&group_id=5470

From noreply at sourceforge.net  Tue May 23 20:50:21 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 23 May 2006 11:50:21 -0700
Subject: [ python-Bugs-1334662 ] int(string, base) wrong answers
Message-ID: <E1FibxV-0002yT-AE@sc8-sf-web1.sourceforge.net>

Bugs item #1334662, was opened at 2005-10-22 00:13
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1334662&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: Tim Peters (tim_one)
Assigned to: Nobody/Anonymous (nobody)
Summary: int(string, base) wrong answers

Initial Comment:
This affects all Python releases to date.  See

<http://mail.python.org/pipermail/python-dev/2005-
October/057510.html>

for discussion.  The overflow check in PyOS_strtoul() is 
too clever, and causes these wrong results on a 32-bit 
box (on a box with sizeof(long) == 8, other examples 
would fail):

int('102002022201221111211', 3) = 0
int('32244002423141', 5) = 0
int('1550104015504', 6) = 0
int('211301422354', 7) = 0
int('12068657454', 9) = 0
int('1904440554', 11) = 0
int('9ba461594', 12) = 0
int('535a79889', 13) = 0
int('2ca5b7464', 14) = 0
int('1a20dcd81', 15) = 0
int('a7ffda91', 17) = 0
int('704he7g4', 18) = 0
int('4f5aff66', 19) = 0
int('3723ai4g', 20) = 0
int('281d55i4', 21) = 0
int('1fj8b184', 22) = 0
int('1606k7ic', 23) = 0
int('mb994ag', 24) = 0
int('hek2mgl', 25) = 0
int('dnchbnm', 26) = 0
int('b28jpdm', 27) = 0
int('8pfgih4', 28) = 0
int('76beigg', 29) = 0
int('5qmcpqg', 30) = 0
int('4q0jto4', 31) = 0
int('3aokq94', 33) = 0
int('2qhxjli', 34) = 0
int('2br45qb', 35) = 0
int('1z141z4', 36) = 0


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2006-05-23 14:50

Message:
Logged In: YES 
user_id=31435

This was repaired via a variant of patch 1335972.

----------------------------------------------------------------------

Comment By: Ivan Vilata i Balaguer (ivilata)
Date: 2006-03-31 15:19

Message:
Logged In: YES 
user_id=1064183

Request #1462361 also contains a patch for adding some tests
to ``test_builtin.py``.  Someone with a 64-bit platform out
there?

----------------------------------------------------------------------

Comment By: Ivan Vilata i Balaguer (ivilata)
Date: 2006-03-31 14:23

Message:
Logged In: YES 
user_id=1064183

The patch I talked about is under request ID #1462361.

----------------------------------------------------------------------

Comment By: Ivan Vilata i Balaguer (ivilata)
Date: 2006-03-31 13:58

Message:
Logged In: YES 
user_id=1064183

There is a special case (added by Guido back in 1997, r9327)
for detecting overflows only for base 10, so that
'4294967296' does not get interpreted as 0.  It seems that
the special case is no longer needed since the adoption on
Python long integers in case of overflow.  Using the case
for base 10 for all bases (look at the attached
1334662-mystrtoul.c.diff) does the trick.  Given this script::

  print 2, int('100000000000000000000000000000000', 2)
  print 3, int('102002022201221111211', 3)
  print 4, int('10000000000000000', 4)
  print 5, int('32244002423141', 5)
  print 6, int('1550104015504', 6)
  print 7, int('211301422354', 7)
  print 8, int('40000000000', 8)
  print 9, int('12068657454', 9)
  print 10, int('4294967296', 10)
  print 11, int('1904440554', 11)
  print 12, int('9ba461594', 12)
  print 13, int('535a79889', 13)
  print 14, int('2ca5b7464', 14)
  print 15, int('1a20dcd81', 15)
  print 16, int('100000000', 16)
  print 17, int('a7ffda91', 17)
  print 18, int('704he7g4', 18)
  print 19, int('4f5aff66', 19)
  print 20, int('3723ai4g', 20)
  print 21, int('281d55i4', 21)
  print 22, int('1fj8b184', 22)
  print 23, int('1606k7ic', 23)
  print 24, int('mb994ag', 24)
  print 25, int('hek2mgl', 25)
  print 26, int('dnchbnm', 26)
  print 27, int('b28jpdm', 27)
  print 28, int('8pfgih4', 28)
  print 29, int('76beigg', 29)
  print 30, int('5qmcpqg', 30)
  print 31, int('4q0jto4', 31)
  print 32, int('4000000', 32)
  print 33, int('3aokq94', 33)
  print 34, int('2qhxjli', 34)
  print 35, int('2br45qb', 35)
  print 36, int('1z141z4', 36)

The old output is::

  2 4294967296
  3 0
  4 4294967296
  5 0
  6 0
  7 0
  8 4294967296
  9 0
  10 4294967296
  11 0
  12 0
  13 0
  14 0
  15 0
  16 4294967296
  17 0
  18 0
  19 0
  20 0
  21 0
  22 0
  23 0
  24 0
  25 0
  26 0
  27 0
  28 0
  29 0
  30 0
  31 0
  32 4294967296
  33 0
  34 0
  35 0
  36 0

And the new one::

  2 4294967296
  3 4294967296
  4 4294967296
  5 4294967296
  6 4294967296
  ...
  32 4294967296
  33 4294967296
  34 4294967296
  35 4294967296
  36 4294967296

The old bugs should be tested for in ``test_builtin.py``,
but I don't know the Python test infrastructure too well.  I
will give it a try, nonetheless.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1334662&group_id=5470

From noreply at sourceforge.net  Tue May 23 23:11:46 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 23 May 2006 14:11:46 -0700
Subject: [ python-Bugs-1491574 ] distutils adds (unwanted) -xcode=pic32 in the
	compile comman
Message-ID: <E1FieAM-0005Ol-NB@sc8-sf-web3.sourceforge.net>

Bugs item #1491574, was opened at 2006-05-19 15:04
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1491574&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: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Toon Knapen (tknapen)
Assigned to: Nobody/Anonymous (nobody)
Summary: distutils adds (unwanted) -xcode=pic32 in the compile comman

Initial Comment:
After configuring, making and make installing the
svn-trunk version with sunstudio11 on a Solaris 9 box,
an extra '-xcode=pic32' argument is added to the
compile-command when I try to install numarray using
the setup.py that comes with numarray.

To configure python I first executed:

export CC=cc
export CFLAGS="-xarch=v9" # to force 64bit compilation
export EXTRA_CFLAGS="-xarch=v9" # 
export CXX=CC
export CXXFLAGS="-xarch=v9"
export F77=f77
export FFLAGS="-xarch=v9"
export LDFLAGS="-xarch=v9"

Note that EXTRA_CFLAGS needs to be defined too,
otherwise python itself will not be compiled with the
-xarch=v9 option.

Afterwards I want to install numarray using the
setup.py (`python setup.py install` command). During
compilation of numarray I can however see that
distutils is adding -xcode=pic32 on the command-line.
Afterwards distutils is not able to link because there
now is a mix of 32bit and 64bit code.


----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-05-23 23:11

Message:
Logged In: YES 
user_id=21627

Yes, please move discussion to python-dev, although
discussion of the build process usually fails to attract
anybody.

----------------------------------------------------------------------

Comment By: Toon Knapen (tknapen)
Date: 2006-05-23 11:13

Message:
Logged In: YES 
user_id=144552

Looking through the code of distutils I finally found that
plenty of information is recoved from the _current_
environment in distutils/sysconfig.py.

Thus the LDFLAGS env.var. I had defined when configuring
python is not stored somewhere. So when e.g. installing
numarray, I need to set the LDFLAGS env.var. again.

Would'nt it be better if python would store the
flags/options that were used to compile python itself. This
guarantees that the extension modules will be
compiled/linked with the same flags and guarantees a maximal
compatibility?

If you prefer to move this discussion to the python-ml ....

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-05-23 00:27

Message:
Logged In: YES 
user_id=21627

Something like that, yes. It's quite involved, so it is not
easy to see what the right approach is.

If you can come up with a patch that works for you, I can
review the patch to find out what else it breaks.

----------------------------------------------------------------------

Comment By: Toon Knapen (tknapen)
Date: 2006-05-22 15:09

Message:
Logged In: YES 
user_id=144552

Indeed the -xcode=pic32 is not at fault here. The problem
though still is that distutils is not linking the shared
libraries using the link-option '-xarch=v9'. The linker
therefore complains about a mix of 32bit and 64bit code.

Should'nt distutils copy the content of LDFLAGS of when
python is being configured and add these options to the
link-line ?

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-05-20 08:31

Message:
Logged In: YES 
user_id=21627

You must be misunderstanding something. -xcode=pic32 does
*not* mean that the code ought to be compiled for the 32-bit
processor mode. Instead, it means that the PIC (position
independent code) offsets are encoded using 32-bit numbers,
which works for both 32-bit and 64-bit code as long as the
size of the code does not exceed 4GiB.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1491574&group_id=5470

From noreply at sourceforge.net  Wed May 24 02:56:18 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 23 May 2006 17:56:18 -0700
Subject: [ python-Bugs-1493922 ] Setting a socket timeout breaks SSL
Message-ID: <E1Fihfe-0002FR-DV@sc8-sf-web3.sourceforge.net>

Bugs item #1493922, was opened at 2006-05-24 10:56
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=1493922&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: Andrew Pollock (apollock)
Assigned to: Nobody/Anonymous (nobody)
Summary: Setting a socket timeout breaks SSL

Initial Comment:
Hi,

Bug #1153016 implies that this problem was fixed in 2.3
and is a regression in 2.4, however in 

2.3.5 (#2, Aug 30 2005, 15:50:26)
[GCC 4.0.2 20050821 (prerelease) (Debian 4.0.1-6)]

I'm able to do this:

import smtplib
s = smtplib.SMTP("localhost")
s.sock.settimeout(5)
s.starttls()
s.helo("localhost")

and get:

Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.3/smtplib.py", line 379, in helo
    (code,msg)=self.getreply()
  File "/usr/lib/python2.3/smtplib.py", line 344, in
getreply
    line = self.file.readline()
  File "/usr/lib/python2.3/smtplib.py", line 159, in
readline
    chr = self.sslobj.read(1)
socket.sslerror: The read operation timed out

I expect this won't be limited to just smtplib.

I'm new to Python, and to the Python project, so I'm
still trying to grapple with SF's bug tracking system
and source code repository, so I haven't been able to
do a thorough analysis of the problem because I can't
find my way around terribly well. Is Python 2.3 still
even maintained?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1493922&group_id=5470

From noreply at sourceforge.net  Wed May 24 08:51:37 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 23 May 2006 23:51:37 -0700
Subject: [ python-Bugs-1493922 ] Setting a socket timeout breaks SSL
Message-ID: <E1FinDV-0004rJ-AE@sc8-sf-web4-b.sourceforge.net>

Bugs item #1493922, was opened at 2006-05-24 02:56
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1493922&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: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Andrew Pollock (apollock)
Assigned to: Nobody/Anonymous (nobody)
Summary: Setting a socket timeout breaks SSL

Initial Comment:
Hi,

Bug #1153016 implies that this problem was fixed in 2.3
and is a regression in 2.4, however in 

2.3.5 (#2, Aug 30 2005, 15:50:26)
[GCC 4.0.2 20050821 (prerelease) (Debian 4.0.1-6)]

I'm able to do this:

import smtplib
s = smtplib.SMTP("localhost")
s.sock.settimeout(5)
s.starttls()
s.helo("localhost")

and get:

Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.3/smtplib.py", line 379, in helo
    (code,msg)=self.getreply()
  File "/usr/lib/python2.3/smtplib.py", line 344, in
getreply
    line = self.file.readline()
  File "/usr/lib/python2.3/smtplib.py", line 159, in
readline
    chr = self.sslobj.read(1)
socket.sslerror: The read operation timed out

I expect this won't be limited to just smtplib.

I'm new to Python, and to the Python project, so I'm
still trying to grapple with SF's bug tracking system
and source code repository, so I haven't been able to
do a thorough analysis of the problem because I can't
find my way around terribly well. Is Python 2.3 still
even maintained?

----------------------------------------------------------------------

>Comment By: Martin v. L??wis (loewis)
Date: 2006-05-24 08:51

Message:
Logged In: YES 
user_id=21627

Python 2.3 is not maintained anymore, so closing this as
"won't fix".

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1493922&group_id=5470

From noreply at sourceforge.net  Wed May 24 11:22:44 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 24 May 2006 02:22:44 -0700
Subject: [ python-Bugs-1493922 ] Setting a socket timeout breaks SSL
Message-ID: <E1FipZk-000161-UI@sc8-sf-web4-b.sourceforge.net>

Bugs item #1493922, was opened at 2006-05-24 00:56
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1493922&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: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: Andrew Pollock (apollock)
Assigned to: Nobody/Anonymous (nobody)
Summary: Setting a socket timeout breaks SSL

Initial Comment:
Hi,

Bug #1153016 implies that this problem was fixed in 2.3
and is a regression in 2.4, however in 

2.3.5 (#2, Aug 30 2005, 15:50:26)
[GCC 4.0.2 20050821 (prerelease) (Debian 4.0.1-6)]

I'm able to do this:

import smtplib
s = smtplib.SMTP("localhost")
s.sock.settimeout(5)
s.starttls()
s.helo("localhost")

and get:

Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.3/smtplib.py", line 379, in helo
    (code,msg)=self.getreply()
  File "/usr/lib/python2.3/smtplib.py", line 344, in
getreply
    line = self.file.readline()
  File "/usr/lib/python2.3/smtplib.py", line 159, in
readline
    chr = self.sslobj.read(1)
socket.sslerror: The read operation timed out

I expect this won't be limited to just smtplib.

I'm new to Python, and to the Python project, so I'm
still trying to grapple with SF's bug tracking system
and source code repository, so I haven't been able to
do a thorough analysis of the problem because I can't
find my way around terribly well. Is Python 2.3 still
even maintained?

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-05-24 09:22

Message:
Logged In: YES 
user_id=849994

Also, this is fixed in 2.5, see bug 1380952.

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-05-24 06:51

Message:
Logged In: YES 
user_id=21627

Python 2.3 is not maintained anymore, so closing this as
"won't fix".

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1493922&group_id=5470

From noreply at sourceforge.net  Wed May 24 12:25:30 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 24 May 2006 03:25:30 -0700
Subject: [ python-Bugs-1229380 ] No struct.pack exception for some out of
	range integers
Message-ID: <E1FiqYU-0003IO-DM@sc8-sf-web2.sourceforge.net>

Bugs item #1229380, was opened at 2005-06-28 23:30
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1229380&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: Adal Chiriliuc (adalx)
>Assigned to: Bob Ippolito (etrepum)
Summary: No struct.pack exception for some out of range integers

Initial Comment:
struct.pack("B", -1) generates an OverflowError
exception since the B format corresponds to the
"unsigned char" type which can have values between 0
and 255.

But struct.pack("I", -1) and struct.pack("L", -1) do
not generate these errors, even if struct.pack("I",
-1L) and struct.pack("L", -1L) do (notice the final L).


----------------------------------------------------------------------

Comment By: Ilya Sandler (isandler)
Date: 2006-04-27 14:46

Message:
Logged In: YES 
user_id=971153


Also it appears that there is some kind of interference
between range checking and byte-order chars:

  import struct; struct.pack("H", 70000)  #Exception

  import struct; struct.pack(">H", 70000) # no exception

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-02-20 20:52

Message:
Logged In: YES 
user_id=849994

Attaching patch, raises struct.error. Neal, please look over it.

Note that I find struct's error handling confusing: it's not
clear from the docs in which cases OverflowError is raised,
and in which struct.error.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1229380&group_id=5470

From noreply at sourceforge.net  Wed May 24 12:25:49 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 24 May 2006 03:25:49 -0700
Subject: [ python-Bugs-1229380 ] No struct.pack exception for some out of
	range integers
Message-ID: <E1FiqYn-0003Q5-O3@sc8-sf-web2.sourceforge.net>

Bugs item #1229380, was opened at 2005-06-28 23:30
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1229380&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: Adal Chiriliuc (adalx)
Assigned to: Bob Ippolito (etrepum)
Summary: No struct.pack exception for some out of range integers

Initial Comment:
struct.pack("B", -1) generates an OverflowError
exception since the B format corresponds to the
"unsigned char" type which can have values between 0
and 255.

But struct.pack("I", -1) and struct.pack("L", -1) do
not generate these errors, even if struct.pack("I",
-1L) and struct.pack("L", -1L) do (notice the final L).


----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-05-24 10:25

Message:
Logged In: YES 
user_id=849994

Assigning to Bob since he rewrote/extended the struct module
for 2.5.

----------------------------------------------------------------------

Comment By: Ilya Sandler (isandler)
Date: 2006-04-27 14:46

Message:
Logged In: YES 
user_id=971153


Also it appears that there is some kind of interference
between range checking and byte-order chars:

  import struct; struct.pack("H", 70000)  #Exception

  import struct; struct.pack(">H", 70000) # no exception

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-02-20 20:52

Message:
Logged In: YES 
user_id=849994

Attaching patch, raises struct.error. Neal, please look over it.

Note that I find struct's error handling confusing: it's not
clear from the docs in which cases OverflowError is raised,
and in which struct.error.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1229380&group_id=5470

From noreply at sourceforge.net  Wed May 24 15:51:05 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 24 May 2006 06:51:05 -0700
Subject: [ python-Bugs-1494314 ] Cannot use high-numbered sockets in 2.4.3
Message-ID: <E1FitlR-0005ec-Ui@sc8-sf-web1.sourceforge.net>

Bugs item #1494314, was opened at 2006-05-24 15:51
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=1494314&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: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Smith (mlrsmith)
Assigned to: Nobody/Anonymous (nobody)
Summary: Cannot use high-numbered sockets in 2.4.3

Initial Comment:
Python 2.4.3 introduced (in Modules/socketmodule.c) the
IS_SELECTABLE() macro, to check whether calling
select() on a given file descriptor is permissible.

However, it executes this check even when it won't
actually call select(). Specifically, select() is
called ONLY when s->sock_timeout > 0 (in
internal_select mostly, but also internal_connect).

I have a twisted application which uses many FDs
(several thousand), and upgrading python to 2.4.3 makes
it hit this limit (at 1024 file descriptors),
regardless of ulimit settings. Twisted itself always
uses non-blocking I/O on sockets, so with older
versions of python this worked fine.

A simple solution relies on the fact that select is
only ever actually called, and changes the
IS_SELECTABLE macro as in the attached fairly trivial
patch. This is sufficient to restore my application to
its previous state (where it works fine).

This doesn't solve the more general problem in
socketmodule - that we simply can't do all operations
properly with the current reliance on select(), though,
and it seems like a bit of a hack...  If I wrote up a
patch to use poll() on systems where it's available,
throughout socketmodule.c, in preference to select(),
would this be accepted?

Mike



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1494314&group_id=5470

From noreply at sourceforge.net  Wed May 24 17:31:18 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 24 May 2006 08:31:18 -0700
Subject: [ python-Bugs-1494387 ] SVN longobject.c compiler warnings
Message-ID: <E1FivKQ-0005U4-6Q@sc8-sf-web4-b.sourceforge.net>

Bugs item #1494387, was opened at 2006-05-24 10:31
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=1494387&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: Joel Konkle-Parker (joeljkp)
Assigned to: Nobody/Anonymous (nobody)
Summary: SVN longobject.c compiler warnings

Initial Comment:
>From SVN, longobject.c gives the following compiler
warnings (Sun Studio 11):

cc -xtarget=native64 -v -Xc -xc99=none -c  -DNDEBUG -O
 -I. -I./Include  -DPy_BUILD_CORE -o
Objects/longobject.o Objects/longobject.c
"Objects/longobject.c", line 1255: warning: statement
not reached
"Objects/longobject.c", line 1591: warning: statement
not reached
"Objects/longobject.c", line 1908: warning: statement
not reached
"Objects/longobject.c", line 1946: warning: statement
not reached

The attached patch fixes the problem.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1494387&group_id=5470

From noreply at sourceforge.net  Wed May 24 23:00:48 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 24 May 2006 14:00:48 -0700
Subject: [ python-Feature Requests-1494595 ] sys.getrefcount should be in gc
Message-ID: <E1Fj0TI-0003zb-Lx@sc8-sf-web2.sourceforge.net>

Feature Requests item #1494595, was opened at 2006-05-24 17:00
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1494595&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: Jim Jewett (jimjjewett)
Assigned to: Nobody/Anonymous (nobody)
Summary: sys.getrefcount should be in gc

Initial Comment:
sys.getrefcount should be in the gc module, at least 
as an alias.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1494595&group_id=5470

From noreply at sourceforge.net  Wed May 24 23:25:30 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 24 May 2006 14:25:30 -0700
Subject: [ python-Bugs-1494605 ] unchecked PyObject_SetAttrString() in
	PyErr_SyntaxLocation()
Message-ID: <E1Fj0rC-0003Ae-1K@sc8-sf-web2.sourceforge.net>

Bugs item #1494605, was opened at 2006-05-24 14:25
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=1494605&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: Brett Cannon (bcannon)
Assigned to: Nobody/Anonymous (nobody)
Summary: unchecked PyObject_SetAttrString() in PyErr_SyntaxLocation()

Initial Comment:
Line 733 of Python/errors.c has a
PyObject_SetAttrString() call where Py_Clear() is not
called if it failed.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1494605&group_id=5470

From noreply at sourceforge.net  Wed May 24 23:26:42 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 24 May 2006 14:26:42 -0700
Subject: [ python-Bugs-1493676 ] time.strftime() %z error
Message-ID: <E1Fj0sM-0001YS-57@sc8-sf-web1.sourceforge.net>

Bugs item #1493676, was opened at 2006-05-23 08:58
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1493676&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: Cillian Sharkey (csharkey)
Assigned to: Nobody/Anonymous (nobody)
Summary: time.strftime() %z error

Initial Comment:
According to the time module documentation, if the time
argument for strftime() is not provided, it will use
the current time as returned by localtime().

However, when the value of localtime() is explicitly
given to strftime(), this produces an error in the
value of the timezone offset (%z) as seen here:

>>> from time import *
>>> strftime("%a %b %e %H:%M:%S %Y %Z %z")
'Tue May 23 16:28:31 2006 IST +0100'
>>> strftime("%a %b %e %H:%M:%S %Y %Z %z", localtime())
'Tue May 23 16:28:31 2006 IST +0000'

This same problem happens for other timezones (the
offset is always +0000 when localtime() is explicitly
given).

This problem is present in both these versions:

Python 2.4.2 (#2, Sep 30 2005, 21:19:01)
[GCC 4.0.2 20050808 (prerelease) (Ubuntu
4.0.1-4ubuntu8)] on linux2

Python 2.3.5 (#2, Sep  4 2005, 22:01:42)
[GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2


----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2006-05-24 14:26

Message:
Logged In: YES 
user_id=357491

Closing as invalid since, as Georg pointed out, %z is not
supported by Python.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-05-23 09:58

Message:
Logged In: YES 
user_id=849994

Note that %z isn't officially supported by Python, judging
by the docs.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1493676&group_id=5470

From noreply at sourceforge.net  Thu May 25 02:51:53 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 24 May 2006 17:51:53 -0700
Subject: [ python-Bugs-1494671 ] PyOS_ascii_strtod() uses malloc()
Message-ID: <E1Fj44v-0008Fd-E9@sc8-sf-web1.sourceforge.net>

Bugs item #1494671, was opened at 2006-05-24 17:51
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=1494671&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: Brett Cannon (bcannon)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyOS_ascii_strtod() uses malloc()

Initial Comment:
Line 103 shows a use of a bare malloc() instead of the
proper memory-related macro.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1494671&group_id=5470

From noreply at sourceforge.net  Thu May 25 02:52:12 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 24 May 2006 17:52:12 -0700
Subject: [ python-Bugs-1494671 ] PyOS_ascii_strtod() uses malloc() directly
Message-ID: <E1Fj45E-0008Ov-NP@sc8-sf-web1.sourceforge.net>

Bugs item #1494671, was opened at 2006-05-24 17:51
Message generated for change (Settings changed) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1494671&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: Brett Cannon (bcannon)
Assigned to: Nobody/Anonymous (nobody)
>Summary: PyOS_ascii_strtod() uses malloc() directly

Initial Comment:
Line 103 shows a use of a bare malloc() instead of the
proper memory-related macro.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1494671&group_id=5470

From noreply at sourceforge.net  Thu May 25 03:18:56 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 24 May 2006 18:18:56 -0700
Subject: [ python-Bugs-1494671 ] PyOS_ascii_strtod() uses malloc() directly
Message-ID: <E1Fj4V6-0004k3-T5@sc8-sf-web4-b.sourceforge.net>

Bugs item #1494671, was opened at 2006-05-24 20:51
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1494671&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: Brett Cannon (bcannon)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyOS_ascii_strtod() uses malloc() directly

Initial Comment:
Line 103 shows a use of a bare malloc() instead of the
proper memory-related macro.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2006-05-24 21:18

Message:
Logged In: YES 
user_id=31435

Well, it's not really a bug.  If a module wants to use
malloc/free internally, that's fine.  I can't think of a
reason for _why_ this code wants to do that, but it doesn't
really hurt.

Somtimes there is a good reason.  For example, the code
providing a portable notion of thread-local storage in
thread.c uses malloc deliberately, because those functions
can be called when the GIL isn't held (i.e., multiple
threads can call them simultaneously).  The Python memory
families, like almost all parts of the Python C API, are
free to assume that the GIL is held; in particular, obmalloc
does assume that, so it would be disastrous if thread.c used
that memory family instead.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1494671&group_id=5470

From noreply at sourceforge.net  Thu May 25 03:51:57 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 24 May 2006 18:51:57 -0700
Subject: [ python-Bugs-1489648 ] time module missing from global mod index
Message-ID: <E1Fj513-00088Z-11@sc8-sf-web3.sourceforge.net>

Bugs item #1489648, was opened at 2006-05-16 11:49
Message generated for change (Comment added) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1489648&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: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: time module missing from global mod index

Initial Comment:
The time module is not listed in the latest dev global
module index:

http://docs.python.org/dev/modindex.html

Skip


----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-05-24 21:51

Message:
Logged In: YES 
user_id=3066

I can't reproduce this, even after doing a "make clobber" in
the Doc/ directory.  Was there anything weird about the
environment?  Windows/Cygwin?

----------------------------------------------------------------------

Comment By: George Yoshida (quiver)
Date: 2006-05-16 14:44

Message:
Logged In: YES 
user_id=671362

Same as bug #1109523

I can't reproduce this in my local environment but Fred
should know the reason.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1489648&group_id=5470

From noreply at sourceforge.net  Thu May 25 04:05:56 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 24 May 2006 19:05:56 -0700
Subject: [ python-Bugs-1281291 ] Erroneous \url command in python.sty
Message-ID: <E1Fj5Ea-0007FE-OD@sc8-sf-web2.sourceforge.net>

Bugs item #1281291, was opened at 2005-09-03 11:18
Message generated for change (Comment added) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1281291&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: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Rory Yorke (ryorke)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Erroneous \url command in python.sty

Initial Comment:
The \url and \ulink commands in texinputs/python.sty
produce erroneous PDF files. This can be fairly easily
tested using GhostScript (see the attached log file for
an example). 

The current Python 2.4.1 PDF docs (as downloadable from
www.python.org) have this error.

Although the error does not prevent correct rendering
in viewers such as gv, xpdf or acroread, the link is
absent.

The attached patch partially addresses this, by
changing the arguments to the \pdfstart command used.
The changes are taken straight from
texmf/tex/latex/hyperref/hpdftex.def; that file has the
following version header:

%% File: hyperref.dtx Copyright 1995-2001 Sebastian Rahtz,
%% RCS: $Id: hyperref.dtx 6.71 2000/10/04 rahtz Exp rahtz $

I don't pretend to understand the TeX code, but it does
fix some of the problem.

Some URLs, like
http://sourceforge.net/bugs/?group_id=5470, are not
linked to correctly. That particular URL becomes

http://sourceforge.net/bugs/?groupunhbox%20voidb at x%20penalty%20 at M%20hskip%20z at skip%20unhbox%20voidb at x%20kern%20.06emvbox%20{hrule%20width.3em}discretionary%20{-}{}{}penalty%20 at M%20hskip%20z at skip%20id=5470

-- I guess that has something to do with the underscore.

The diff was generated relative to Python CVS head of 3
Sept 2005; the python.sty file had version 1.113.

The python executable used was 2.4.1, not CVS.

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-05-24 22:05

Message:
Logged In: YES 
user_id=3066

I can't seem to get the attachments; there are no links for
them!  Something appears to be wrong with SourceForge.

It would not surprise me it underscores break the PDF;
there's too much magic about them.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1281291&group_id=5470

From noreply at sourceforge.net  Thu May 25 04:09:05 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 24 May 2006 19:09:05 -0700
Subject: [ python-Bugs-1281291 ] Erroneous \url command in python.sty
Message-ID: <E1Fj5Hd-0007OW-OB@sc8-sf-web3.sourceforge.net>

Bugs item #1281291, was opened at 2005-09-03 11:18
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1281291&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: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Rory Yorke (ryorke)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Erroneous \url command in python.sty

Initial Comment:
The \url and \ulink commands in texinputs/python.sty
produce erroneous PDF files. This can be fairly easily
tested using GhostScript (see the attached log file for
an example). 

The current Python 2.4.1 PDF docs (as downloadable from
www.python.org) have this error.

Although the error does not prevent correct rendering
in viewers such as gv, xpdf or acroread, the link is
absent.

The attached patch partially addresses this, by
changing the arguments to the \pdfstart command used.
The changes are taken straight from
texmf/tex/latex/hyperref/hpdftex.def; that file has the
following version header:

%% File: hyperref.dtx Copyright 1995-2001 Sebastian Rahtz,
%% RCS: $Id: hyperref.dtx 6.71 2000/10/04 rahtz Exp rahtz $

I don't pretend to understand the TeX code, but it does
fix some of the problem.

Some URLs, like
http://sourceforge.net/bugs/?group_id=5470, are not
linked to correctly. That particular URL becomes

http://sourceforge.net/bugs/?groupunhbox%20voidb at x%20penalty%20 at M%20hskip%20z at skip%20unhbox%20voidb at x%20kern%20.06emvbox%20{hrule%20width.3em}discretionary%20{-}{}{}penalty%20 at M%20hskip%20z at skip%20id=5470

-- I guess that has something to do with the underscore.

The diff was generated relative to Python CVS head of 3
Sept 2005; the python.sty file had version 1.113.

The python executable used was 2.4.1, not CVS.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2006-05-24 22:09

Message:
Logged In: YES 
user_id=31435

Fred, there are links, but you'll probably have to use your
horizontal scrollbar to find them (way off on the right).

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-05-24 22:05

Message:
Logged In: YES 
user_id=3066

I can't seem to get the attachments; there are no links for
them!  Something appears to be wrong with SourceForge.

It would not surprise me it underscores break the PDF;
there's too much magic about them.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1281291&group_id=5470

From noreply at sourceforge.net  Thu May 25 04:34:48 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 24 May 2006 19:34:48 -0700
Subject: [ python-Bugs-1489648 ] time module missing from global mod index
Message-ID: <E1Fj5gW-000279-Hn@sc8-sf-web3.sourceforge.net>

Bugs item #1489648, was opened at 2006-05-16 10:49
Message generated for change (Comment added) made by montanaro
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1489648&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: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: time module missing from global mod index

Initial Comment:
The time module is not listed in the latest dev global
module index:

http://docs.python.org/dev/modindex.html

Skip


----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2006-05-24 21:34

Message:
Logged In: YES 
user_id=44345

I'm not sure what's to reproduce.  I just observed that the dev version of the 
module index is missing the time module, at least when viewed from my Mac 
using Safari or Firefox.  Does updating the dev docs restore it?

Skip


----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-05-24 20:51

Message:
Logged In: YES 
user_id=3066

I can't reproduce this, even after doing a "make clobber" in
the Doc/ directory.  Was there anything weird about the
environment?  Windows/Cygwin?

----------------------------------------------------------------------

Comment By: George Yoshida (quiver)
Date: 2006-05-16 13:44

Message:
Logged In: YES 
user_id=671362

Same as bug #1109523

I can't reproduce this in my local environment but Fred
should know the reason.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1489648&group_id=5470

From noreply at sourceforge.net  Thu May 25 04:46:26 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 24 May 2006 19:46:26 -0700
Subject: [ python-Bugs-1281291 ] Erroneous \url command in python.sty
Message-ID: <E1Fj5rm-0007Kg-7a@sc8-sf-web3.sourceforge.net>

Bugs item #1281291, was opened at 2005-09-03 11:18
Message generated for change (Comment added) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1281291&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: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Rory Yorke (ryorke)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Erroneous \url command in python.sty

Initial Comment:
The \url and \ulink commands in texinputs/python.sty
produce erroneous PDF files. This can be fairly easily
tested using GhostScript (see the attached log file for
an example). 

The current Python 2.4.1 PDF docs (as downloadable from
www.python.org) have this error.

Although the error does not prevent correct rendering
in viewers such as gv, xpdf or acroread, the link is
absent.

The attached patch partially addresses this, by
changing the arguments to the \pdfstart command used.
The changes are taken straight from
texmf/tex/latex/hyperref/hpdftex.def; that file has the
following version header:

%% File: hyperref.dtx Copyright 1995-2001 Sebastian Rahtz,
%% RCS: $Id: hyperref.dtx 6.71 2000/10/04 rahtz Exp rahtz $

I don't pretend to understand the TeX code, but it does
fix some of the problem.

Some URLs, like
http://sourceforge.net/bugs/?group_id=5470, are not
linked to correctly. That particular URL becomes

http://sourceforge.net/bugs/?groupunhbox%20voidb at x%20penalty%20 at M%20hskip%20z at skip%20unhbox%20voidb at x%20kern%20.06emvbox%20{hrule%20width.3em}discretionary%20{-}{}{}penalty%20 at M%20hskip%20z at skip%20id=5470

-- I guess that has something to do with the underscore.

The diff was generated relative to Python CVS head of 3
Sept 2005; the python.sty file had version 1.113.

The python executable used was 2.4.1, not CVS.

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-05-24 22:46

Message:
Logged In: YES 
user_id=3066

There should be a law against horizontal scrolling.  :-(

The fix is now applied to the trunk (revision 46205),
and the Python 2.4.x branch (revision 46206).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-05-24 22:09

Message:
Logged In: YES 
user_id=31435

Fred, there are links, but you'll probably have to use your
horizontal scrollbar to find them (way off on the right).

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-05-24 22:05

Message:
Logged In: YES 
user_id=3066

I can't seem to get the attachments; there are no links for
them!  Something appears to be wrong with SourceForge.

It would not surprise me it underscores break the PDF;
there's too much magic about them.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1281291&group_id=5470

From noreply at sourceforge.net  Thu May 25 04:57:03 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 24 May 2006 19:57:03 -0700
Subject: [ python-Bugs-1489648 ] time module missing from global mod index
Message-ID: <E1Fj623-00075b-Ax@sc8-sf-web4-b.sourceforge.net>

Bugs item #1489648, was opened at 2006-05-16 11:49
Message generated for change (Comment added) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1489648&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: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: time module missing from global mod index

Initial Comment:
The time module is not listed in the latest dev global
module index:

http://docs.python.org/dev/modindex.html

Skip


----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-05-24 22:57

Message:
Logged In: YES 
user_id=3066

Skip,

I don't know how to make the update.  When I build the docs
on my machine, the "time" module link is included in the
global module index.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2006-05-24 22:34

Message:
Logged In: YES 
user_id=44345

I'm not sure what's to reproduce.  I just observed that the dev version of the 
module index is missing the time module, at least when viewed from my Mac 
using Safari or Firefox.  Does updating the dev docs restore it?

Skip


----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-05-24 21:51

Message:
Logged In: YES 
user_id=3066

I can't reproduce this, even after doing a "make clobber" in
the Doc/ directory.  Was there anything weird about the
environment?  Windows/Cygwin?

----------------------------------------------------------------------

Comment By: George Yoshida (quiver)
Date: 2006-05-16 14:44

Message:
Logged In: YES 
user_id=671362

Same as bug #1109523

I can't reproduce this in my local environment but Fred
should know the reason.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1489648&group_id=5470

From noreply at sourceforge.net  Thu May 25 05:10:19 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 24 May 2006 20:10:19 -0700
Subject: [ python-Bugs-1489648 ] time module missing from global mod index
Message-ID: <E1Fj6Et-0004cM-4X@sc8-sf-web4-b.sourceforge.net>

Bugs item #1489648, was opened at 2006-05-16 10:49
Message generated for change (Comment added) made by montanaro
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1489648&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: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: time module missing from global mod index

Initial Comment:
The time module is not listed in the latest dev global
module index:

http://docs.python.org/dev/modindex.html

Skip


----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2006-05-24 22:10

Message:
Logged In: YES 
user_id=44345

Okay, I'll open a ticket for the website and refer to this ticket.

Skip


----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-05-24 21:57

Message:
Logged In: YES 
user_id=3066

Skip,

I don't know how to make the update.  When I build the docs
on my machine, the "time" module link is included in the
global module index.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2006-05-24 21:34

Message:
Logged In: YES 
user_id=44345

I'm not sure what's to reproduce.  I just observed that the dev version of the 
module index is missing the time module, at least when viewed from my Mac 
using Safari or Firefox.  Does updating the dev docs restore it?

Skip


----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-05-24 20:51

Message:
Logged In: YES 
user_id=3066

I can't reproduce this, even after doing a "make clobber" in
the Doc/ directory.  Was there anything weird about the
environment?  Windows/Cygwin?

----------------------------------------------------------------------

Comment By: George Yoshida (quiver)
Date: 2006-05-16 13:44

Message:
Logged In: YES 
user_id=671362

Same as bug #1109523

I can't reproduce this in my local environment but Fred
should know the reason.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1489648&group_id=5470

From noreply at sourceforge.net  Thu May 25 10:32:42 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 25 May 2006 01:32:42 -0700
Subject: [ python-Bugs-1494787 ] pyclbr add whitespace chars to base class name
Message-ID: <E1FjBGs-0004vD-P9@sc8-sf-web4-b.sourceforge.net>

Bugs item #1494787, was opened at 2006-05-25 12:32
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=1494787&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: Dmitry Vasiliev (hdima)
Assigned to: Nobody/Anonymous (nobody)
Summary: pyclbr add whitespace chars to base class name

Initial Comment:
While parsing base class names for a class pyclbr eats
also tokens with whitespace characters. The attached
patch adds check for token type.

Maybe we even should form base class names only from
name and dot tokens?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1494787&group_id=5470

From noreply at sourceforge.net  Thu May 25 12:58:06 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 25 May 2006 03:58:06 -0700
Subject: [ python-Feature Requests-1218333 ] Create a fat build on darwin
Message-ID: <E1FjDXa-0005Qe-2t@sc8-sf-web4-b.sourceforge.net>

Feature Requests item #1218333, was opened at 2005-06-10 18:34
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1218333&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: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Nobody/Anonymous (nobody)
Summary: Create a fat build on darwin

Initial Comment:
Apple recently announced that they will switch to intel CPU's for their 
systems. They request that vendors build fat binaries for software. 
IMHO the python build process should be changed to make this 
easily possible.

Areas that (might) need changing:
* autoconf checks for CPU features (endianness, sizes of basic 
types). That won't work with cross-builds. A possible solution: create 
a pycpufeatures.h that hardcodes the information.

* distutils might need to be taught about creating fat binaries.

* It might be necessary to link to a specific SDK, this in turn might 
require changes in the autoconf machinery.

NOTE: I intend to do some work on this in due time.

----------------------------------------------------------------------

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-05-25 12:58

Message:
Logged In: YES 
user_id=580910

The current HEAD fully supports this, closing this item.

----------------------------------------------------------------------

Comment By: Bob Ippolito (etrepum)
Date: 2005-06-15 03:42

Message:
Logged In: YES 
user_id=139309

There's a lot of things to consider here, including but not limited to:

If building universal binaries that maintain compatibility with Mac OS X 
10.3 (two SDK), you'll need to build i386 and ppc architectures 
separately and lipo them together (might as well do ppc64 too).

If building universal binaries that maintain compatibility with Mac OS X 
10.2 (two SDKs, and two compilers!),  you'll need to build with GCC 3.3 
on ppc and GCC 4.0 on i386 with entirely different CFLAGS/LDFLAGS/
MACOSX_DEPLOYMENT_TARGET than the i386 side of things (that's 
scary).

Some modules aren't available for every arch.  For example, psyco isn't 
really useful except on i386.  PyObjC, anything that links to Carbon, etc. 
isn't going to compile on ppc64, etc.  If the ".so" is there (i.e. universal 
binaries for plugins) then the PyImport machinery will see it, try and 
import it, and get a very nasty low-level dyld error.  Either the PyImport 
machinery should inherit code that checks for arch sanity, or there 
should be separate naming conventions (.i386.so) or locations (site-
packages-ppc) for each arch!

Because of the previous consideration, there will have to be ways to tell 
distutils which architectures you want to compile for.. perhaps just 
native by default, but allow (multiple-?)SDK multiple-arch builds if 
requested.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1218333&group_id=5470

From noreply at sourceforge.net  Thu May 25 13:24:33 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 25 May 2006 04:24:33 -0700
Subject: [ python-Bugs-1153016 ] Setting socket timeout crashes SSL
Message-ID: <E1FjDxB-0006VW-5t@sc8-sf-web4-b.sourceforge.net>

Bugs item #1153016, was opened at 2005-02-27 20:41
Message generated for change (Comment added) made by twouters
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153016&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: pristine777 (pristine777)
Assigned to: Nobody/Anonymous (nobody)
Summary: Setting socket timeout crashes SSL

Initial Comment:
This bug was fixed in Python 2.3 but has resurfaced in 
Python 2.4

The original bug report can be found at: 
https://sourceforge.net/tracker/?
func=detail&atid=105470&aid=673797&group_id=5470

The method urlopen both in urllib and in urllib2 crashes 
if socket.setdefaulttimeout has been called. Below is a 
cut and paste when using the function in urllib.


>>> import socket
>>> socket.setdefaulttimeout(30.0)
>>> import urllib
>>> urllib.urlopen('https://members.tufts-
health.com/memindex.html')
Traceback (most recent call last):
  File "<interactive input>", line 1, in ?
  File "C:\Python24\lib\urllib.py", line 77, in urlopen
    return opener.open(url)
  File "C:\Python24\lib\urllib.py", line 180, in open
    return getattr(self, name)(url)
  File "C:\Python24\lib\urllib.py", line 374, in open_https
    h.endheaders()
  File "C:\Python24\lib\httplib.py", line 794, in 
endheaders
    self._send_output()
  File "C:\Python24\lib\httplib.py", line 675, in 
_send_output
    self.send(msg)
  File "C:\Python24\lib\httplib.py", line 642, in send
    self.connect()
  File "C:\Python24\lib\httplib.py", line 1069, in connect
    ssl = socket.ssl(sock, self.key_file, self.cert_file)
  File "C:\Python24\lib\socket.py", line 74, in ssl
    return _realssl(sock, keyfile, certfile)
IOError: [Errno socket error] (2, 'The operation did not 
complete (read)')

Thanks a ton!

----------------------------------------------------------------------

>Comment By: Thomas Wouters (twouters)
Date: 2006-05-25 13:24

Message:
Logged In: YES 
user_id=34209

It seems this was specific to Windows (I was unable to
reproduce it on any version of Python on my UNIX machines),
but it also seems it's fixed in Python 2.5a2 (at least) -- I
can reproduce it with Python 2.4 on Windows XP, but not in
2.5a2. I was unable to identify an obvious fix from the
checkin messages, though (the only likely candidate is a
checkin from before 2.4.0 was released, which claims to fix
the same thing) so backporting to a possible new 2.4 release
is not likely.

Tentatively closing this as fixed. Please pipe up if it
isn't fixed for you, in 2.5a2 or later releases.

----------------------------------------------------------------------

Comment By: Malte Helmert (maltehelmert)
Date: 2005-06-20 17:12

Message:
Logged In: YES 
user_id=1131890

Same problem here with Python 2.4 (#1, Jan 13 2005,
20:34:41) on SuSE Linux 9.2 (i586) and imaplib. Here is a
minimal piece of code that fails (substitute a valid IMAP
server accepting SSL connections):

=== start code snippet ===
import imaplib, socket
socket.setdefaulttimeout(10.0)
imaplib.IMAP4_SSL("imap.whatever.invalid")
=== end code snippet ===

This fails with the following traceback:
=== start traceback ===
Traceback (most recent call last):
  File "./imap_bug.py", line 3, in ?
    imaplib.IMAP4_SSL("imap.whatever.invalid")
  File "/usr/local/lib/python2.4/imaplib.py", line 1101, in
__init__
    IMAP4.__init__(self, host, port)
  File "/usr/local/lib/python2.4/imaplib.py", line 181, in
__init__
    self.welcome = self._get_response()
  File "/usr/local/lib/python2.4/imaplib.py", line 876, in
_get_response
    resp = self._get_line()
  File "/usr/local/lib/python2.4/imaplib.py", line 969, in
_get_line
    line = self.readline()
  File "/usr/local/lib/python2.4/imaplib.py", line 1135, in
readline
    char = self.sslobj.read(1)
socket.sslerror: The read operation timed out
=== end traceback ===

Remove the socket.setdefaulttimeout call and it works properly.
The problem is not due to a slow network connection or
overloaded server -- the script fails for all kinds of
timeouts (1, 10, 100 seconds), but without a timeout the
response is near-instantaneous.

----------------------------------------------------------------------

Comment By: Tarek Ziad? (tarek-ziade)
Date: 2005-05-19 15:53

Message:
Logged In: YES 
user_id=1163510

having same issue here, using imaplib thru ssl :/

>>> import socket
>>> socket.setdefaulttimeout(10)
>>> i = imaplib.IMAP4_SSL('mail.xxxx.com')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.4/imaplib.py", line 1101, in __init__
    IMAP4.__init__(self, host, port)
  File "/usr/lib/python2.4/imaplib.py", line 181, in __init__
    self.welcome = self._get_response()
  File "/usr/lib/python2.4/imaplib.py", line 876, in
_get_response
    resp = self._get_line()
  File "/usr/lib/python2.4/imaplib.py", line 969, in _get_line
    line = self.readline()
  File "/usr/lib/python2.4/imaplib.py", line 1136, in readline
    char = self.sslobj.read(1)
socket.sslerror: The read operation timed out

so i can't get timeouts with ssl in imap :/

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153016&group_id=5470

From noreply at sourceforge.net  Thu May 25 13:31:30 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 25 May 2006 04:31:30 -0700
Subject: [ python-Bugs-1488915 ] Multiple dots in relative import statement
	raise SyntaxError
Message-ID: <E1FjE3u-0000N3-2L@sc8-sf-web4-b.sourceforge.net>

Bugs item #1488915, was opened at 2006-05-15 17:26
Message generated for change (Comment added) made by twouters
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1488915&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: ?iga Seilnacht (zseil)
Assigned to: Thomas Wouters (twouters)
Summary: Multiple dots in relative import statement raise SyntaxError

Initial Comment:
When a relative import statement contains more than
one period and no module name, SyntaxError is raised.
Example:

from  .  import  spam       # this works
from  ..spam  import  eggs  # this works
from  ..  import  eggs      # this raises SyntaxError

The problem is in the following line in Grammar/Grammar:

import_from: ('from' ('.'* dotted_name | '.')

According to Guido's mail:
http://mail.python.org/pipermail/python-dev/2003-December/041065.html
that line should be:

import_from: ('from' ('.'* dotted_name | '.'+)

----------------------------------------------------------------------

>Comment By: Thomas Wouters (twouters)
Date: 2006-05-25 13:31

Message:
Logged In: YES 
user_id=34209

Actually, it was as simple as adding the '+' to the grammar,
because all the code already expected multiple dots. (My
first few patches actually did this right, but Guido
suggested an alternative (simpler) spelling of the Grammar
rule, and we both forgot the '+' :)

Fixed and testcase added in 46209 and 46210. Thanks!


----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-05-16 09:25

Message:
Logged In: YES 
user_id=849994

Assigned to Thomas. It doesn't seem as simple as adding the
"+" in Grammar.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1488915&group_id=5470

From noreply at sourceforge.net  Thu May 25 14:44:08 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 25 May 2006 05:44:08 -0700
Subject: [ python-Bugs-1153016 ] Setting socket timeout crashes SSL
Message-ID: <E1FjFCC-0001HZ-Hl@sc8-sf-web1.sourceforge.net>

Bugs item #1153016, was opened at 2005-02-27 20:41
Message generated for change (Comment added) made by maltehelmert
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153016&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: pristine777 (pristine777)
Assigned to: Nobody/Anonymous (nobody)
Summary: Setting socket timeout crashes SSL

Initial Comment:
This bug was fixed in Python 2.3 but has resurfaced in 
Python 2.4

The original bug report can be found at: 
https://sourceforge.net/tracker/?
func=detail&atid=105470&aid=673797&group_id=5470

The method urlopen both in urllib and in urllib2 crashes 
if socket.setdefaulttimeout has been called. Below is a 
cut and paste when using the function in urllib.


>>> import socket
>>> socket.setdefaulttimeout(30.0)
>>> import urllib
>>> urllib.urlopen('https://members.tufts-
health.com/memindex.html')
Traceback (most recent call last):
  File "<interactive input>", line 1, in ?
  File "C:\Python24\lib\urllib.py", line 77, in urlopen
    return opener.open(url)
  File "C:\Python24\lib\urllib.py", line 180, in open
    return getattr(self, name)(url)
  File "C:\Python24\lib\urllib.py", line 374, in open_https
    h.endheaders()
  File "C:\Python24\lib\httplib.py", line 794, in 
endheaders
    self._send_output()
  File "C:\Python24\lib\httplib.py", line 675, in 
_send_output
    self.send(msg)
  File "C:\Python24\lib\httplib.py", line 642, in send
    self.connect()
  File "C:\Python24\lib\httplib.py", line 1069, in connect
    ssl = socket.ssl(sock, self.key_file, self.cert_file)
  File "C:\Python24\lib\socket.py", line 74, in ssl
    return _realssl(sock, keyfile, certfile)
IOError: [Errno socket error] (2, 'The operation did not 
complete (read)')

Thanks a ton!

----------------------------------------------------------------------

Comment By: Malte Helmert (maltehelmert)
Date: 2006-05-25 14:43

Message:
Logged In: YES 
user_id=1131890

As I noted in my comment, the problem occurred on Linux, too.
However, it has disappeared in 2.5a2, thanks!


----------------------------------------------------------------------

Comment By: Thomas Wouters (twouters)
Date: 2006-05-25 13:24

Message:
Logged In: YES 
user_id=34209

It seems this was specific to Windows (I was unable to
reproduce it on any version of Python on my UNIX machines),
but it also seems it's fixed in Python 2.5a2 (at least) -- I
can reproduce it with Python 2.4 on Windows XP, but not in
2.5a2. I was unable to identify an obvious fix from the
checkin messages, though (the only likely candidate is a
checkin from before 2.4.0 was released, which claims to fix
the same thing) so backporting to a possible new 2.4 release
is not likely.

Tentatively closing this as fixed. Please pipe up if it
isn't fixed for you, in 2.5a2 or later releases.

----------------------------------------------------------------------

Comment By: Malte Helmert (maltehelmert)
Date: 2005-06-20 17:12

Message:
Logged In: YES 
user_id=1131890

Same problem here with Python 2.4 (#1, Jan 13 2005,
20:34:41) on SuSE Linux 9.2 (i586) and imaplib. Here is a
minimal piece of code that fails (substitute a valid IMAP
server accepting SSL connections):

=== start code snippet ===
import imaplib, socket
socket.setdefaulttimeout(10.0)
imaplib.IMAP4_SSL("imap.whatever.invalid")
=== end code snippet ===

This fails with the following traceback:
=== start traceback ===
Traceback (most recent call last):
  File "./imap_bug.py", line 3, in ?
    imaplib.IMAP4_SSL("imap.whatever.invalid")
  File "/usr/local/lib/python2.4/imaplib.py", line 1101, in
__init__
    IMAP4.__init__(self, host, port)
  File "/usr/local/lib/python2.4/imaplib.py", line 181, in
__init__
    self.welcome = self._get_response()
  File "/usr/local/lib/python2.4/imaplib.py", line 876, in
_get_response
    resp = self._get_line()
  File "/usr/local/lib/python2.4/imaplib.py", line 969, in
_get_line
    line = self.readline()
  File "/usr/local/lib/python2.4/imaplib.py", line 1135, in
readline
    char = self.sslobj.read(1)
socket.sslerror: The read operation timed out
=== end traceback ===

Remove the socket.setdefaulttimeout call and it works properly.
The problem is not due to a slow network connection or
overloaded server -- the script fails for all kinds of
timeouts (1, 10, 100 seconds), but without a timeout the
response is near-instantaneous.

----------------------------------------------------------------------

Comment By: Tarek Ziad? (tarek-ziade)
Date: 2005-05-19 15:53

Message:
Logged In: YES 
user_id=1163510

having same issue here, using imaplib thru ssl :/

>>> import socket
>>> socket.setdefaulttimeout(10)
>>> i = imaplib.IMAP4_SSL('mail.xxxx.com')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.4/imaplib.py", line 1101, in __init__
    IMAP4.__init__(self, host, port)
  File "/usr/lib/python2.4/imaplib.py", line 181, in __init__
    self.welcome = self._get_response()
  File "/usr/lib/python2.4/imaplib.py", line 876, in
_get_response
    resp = self._get_line()
  File "/usr/lib/python2.4/imaplib.py", line 969, in _get_line
    line = self.readline()
  File "/usr/lib/python2.4/imaplib.py", line 1136, in readline
    char = self.sslobj.read(1)
socket.sslerror: The read operation timed out

so i can't get timeouts with ssl in imap :/

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153016&group_id=5470

From noreply at sourceforge.net  Thu May 25 17:51:32 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 25 May 2006 08:51:32 -0700
Subject: [ python-Bugs-1495033 ] int/long assume that the buffer ends in \0 =>
	CRASH
Message-ID: <E1FjI7Y-00009x-Ef@sc8-sf-web3.sourceforge.net>

Bugs item #1495033, was opened at 2006-05-25 11:51
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=1495033&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: James Y Knight (foom)
Assigned to: Nobody/Anonymous (nobody)
Summary: int/long assume that the buffer ends in \0 => CRASH

Initial Comment:
But it doesn't, always.

>>> int(buffer('123a', 0, 3))
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ValueError: invalid literal for int(): 123a

Hmmmmmm...well if that works, how about this one:

>>> import array; int(buffer(array.array('c', [])))
***SEGFAULT***

Ah, there we go, a nice crasher.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1495033&group_id=5470

From noreply at sourceforge.net  Thu May 25 20:12:44 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 25 May 2006 11:12:44 -0700
Subject: [ python-Bugs-1495089 ] sys.getfilesystemencoding
Message-ID: <E1FjKKC-00045H-Ix@sc8-sf-web3.sourceforge.net>

Bugs item #1495089, was opened at 2006-05-25 20:12
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=1495089&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: Felix Wiemann (fwiemann)
Assigned to: Nobody/Anonymous (nobody)
Summary: sys.getfilesystemencoding

Initial Comment:
There seems to be a mistake in the documentation of
sys.getfilesystemdocumentation in module-sys.html:

"On Unix, the encoding is the user's preference
according to the result of nl_langinfo(CODESET), or
None if the nl_langinfo(CODESET) failed."

This does not seem to be the case on my system:

>>> import sys
>>> sys.getfilesystemencoding()
'UTF-8'
>>> import locale
>>> locale.nl_langinfo(locale.CODESET)
'ANSI_X3.4-1968'

FYI my locale environment:

$ locale
LANG=en_US.utf8
LC_CTYPE="en_US.utf8"
LC_NUMERIC="en_US.utf8"
LC_TIME="en_US.utf8"
LC_COLLATE=POSIX
LC_MONETARY="en_US.utf8"
LC_MESSAGES="en_US.utf8"
LC_PAPER="en_US.utf8"
LC_NAME="en_US.utf8"
LC_ADDRESS="en_US.utf8"
LC_TELEPHONE="en_US.utf8"
LC_MEASUREMENT="en_US.utf8"
LC_IDENTIFICATION="en_US.utf8"
LC_ALL=

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1495089&group_id=5470

From noreply at sourceforge.net  Thu May 25 20:21:34 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 25 May 2006 11:21:34 -0700
Subject: [ python-Bugs-1495089 ] sys.getfilesystemencoding
Message-ID: <E1FjKSk-0007Vg-EJ@sc8-sf-web3.sourceforge.net>

Bugs item #1495089, was opened at 2006-05-25 18:12
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1495089&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: Works For Me
Priority: 5
Submitted By: Felix Wiemann (fwiemann)
Assigned to: Nobody/Anonymous (nobody)
Summary: sys.getfilesystemencoding

Initial Comment:
There seems to be a mistake in the documentation of
sys.getfilesystemdocumentation in module-sys.html:

"On Unix, the encoding is the user's preference
according to the result of nl_langinfo(CODESET), or
None if the nl_langinfo(CODESET) failed."

This does not seem to be the case on my system:

>>> import sys
>>> sys.getfilesystemencoding()
'UTF-8'
>>> import locale
>>> locale.nl_langinfo(locale.CODESET)
'ANSI_X3.4-1968'

FYI my locale environment:

$ locale
LANG=en_US.utf8
LC_CTYPE="en_US.utf8"
LC_NUMERIC="en_US.utf8"
LC_TIME="en_US.utf8"
LC_COLLATE=POSIX
LC_MONETARY="en_US.utf8"
LC_MESSAGES="en_US.utf8"
LC_PAPER="en_US.utf8"
LC_NAME="en_US.utf8"
LC_ADDRESS="en_US.utf8"
LC_TELEPHONE="en_US.utf8"
LC_MEASUREMENT="en_US.utf8"
LC_IDENTIFICATION="en_US.utf8"
LC_ALL=

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-05-25 18:21

Message:
Logged In: YES 
user_id=849994

You must first set your current locale to the system default
locale; on start, Python's locale defaults to C.

After 'locale.setlocale(locale.LC_ALL, "")' the nl_langinfo
call should yield "UTF-8".

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1495089&group_id=5470

From noreply at sourceforge.net  Thu May 25 21:28:37 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 25 May 2006 12:28:37 -0700
Subject: [ python-Bugs-1494387 ] SVN longobject.c compiler warnings
Message-ID: <E1FjLVd-0006h8-Kl@sc8-sf-web3.sourceforge.net>

Bugs item #1494387, was opened at 2006-05-24 15:31
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1494387&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: Joel Konkle-Parker (joeljkp)
>Assigned to: Tim Peters (tim_one)
Summary: SVN longobject.c compiler warnings

Initial Comment:
>From SVN, longobject.c gives the following compiler
warnings (Sun Studio 11):

cc -xtarget=native64 -v -Xc -xc99=none -c  -DNDEBUG -O
 -I. -I./Include  -DPy_BUILD_CORE -o
Objects/longobject.o Objects/longobject.c
"Objects/longobject.c", line 1255: warning: statement
not reached
"Objects/longobject.c", line 1591: warning: statement
not reached
"Objects/longobject.c", line 1908: warning: statement
not reached
"Objects/longobject.c", line 1946: warning: statement
not reached

The attached patch fixes the problem.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1494387&group_id=5470

From noreply at sourceforge.net  Thu May 25 22:25:00 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 25 May 2006 13:25:00 -0700
Subject: [ python-Bugs-1494671 ] PyOS_ascii_strtod() uses malloc() directly
Message-ID: <E1FjMOC-0005Mv-58@sc8-sf-web4-b.sourceforge.net>

Bugs item #1494671, was opened at 2006-05-24 17:51
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1494671&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: Brett Cannon (bcannon)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyOS_ascii_strtod() uses malloc() directly

Initial Comment:
Line 103 shows a use of a bare malloc() instead of the
proper memory-related macro.

----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2006-05-25 13:24

Message:
Logged In: YES 
user_id=357491

OK.  Well, considered it is free within the function and all
memory use is done through C API functions (memcpy() and
strtod() specifically, I don't see any reason not to move
over to PyMem_Malloc() since I can do that quickly.

Oh, and the file is Python/pystrtod.c and it's line 104 for
those who don't know where the function is.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-05-24 18:18

Message:
Logged In: YES 
user_id=31435

Well, it's not really a bug.  If a module wants to use
malloc/free internally, that's fine.  I can't think of a
reason for _why_ this code wants to do that, but it doesn't
really hurt.

Somtimes there is a good reason.  For example, the code
providing a portable notion of thread-local storage in
thread.c uses malloc deliberately, because those functions
can be called when the GIL isn't held (i.e., multiple
threads can call them simultaneously).  The Python memory
families, like almost all parts of the Python C API, are
free to assume that the GIL is held; in particular, obmalloc
does assume that, so it would be disastrous if thread.c used
that memory family instead.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1494671&group_id=5470

From noreply at sourceforge.net  Thu May 25 22:45:03 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 25 May 2006 13:45:03 -0700
Subject: [ python-Bugs-1494671 ] PyOS_ascii_strtod() uses malloc() directly
Message-ID: <E1FjMhb-0002h5-Sm@sc8-sf-web2.sourceforge.net>

Bugs item #1494671, was opened at 2006-05-24 17:51
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1494671&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: Brett Cannon (bcannon)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyOS_ascii_strtod() uses malloc() directly

Initial Comment:
Line 103 shows a use of a bare malloc() instead of the
proper memory-related macro.

----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2006-05-25 13:45

Message:
Logged In: YES 
user_id=357491

Changed in rev. 46253 to use PyMem_MALLOC/PyMem_FREE .

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2006-05-25 13:24

Message:
Logged In: YES 
user_id=357491

OK.  Well, considered it is free within the function and all
memory use is done through C API functions (memcpy() and
strtod() specifically, I don't see any reason not to move
over to PyMem_Malloc() since I can do that quickly.

Oh, and the file is Python/pystrtod.c and it's line 104 for
those who don't know where the function is.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-05-24 18:18

Message:
Logged In: YES 
user_id=31435

Well, it's not really a bug.  If a module wants to use
malloc/free internally, that's fine.  I can't think of a
reason for _why_ this code wants to do that, but it doesn't
really hurt.

Somtimes there is a good reason.  For example, the code
providing a portable notion of thread-local storage in
thread.c uses malloc deliberately, because those functions
can be called when the GIL isn't held (i.e., multiple
threads can call them simultaneously).  The Python memory
families, like almost all parts of the Python C API, are
free to assume that the GIL is held; in particular, obmalloc
does assume that, so it would be disastrous if thread.c used
that memory family instead.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1494671&group_id=5470

From noreply at sourceforge.net  Thu May 25 23:03:43 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 25 May 2006 14:03:43 -0700
Subject: [ python-Bugs-1495175 ] OverflowWarning still in 2.5 despite docstring
Message-ID: <E1FjMzf-00062f-4S@sc8-sf-web5.sourceforge.net>

Bugs item #1495175, was opened at 2006-05-25 17:03
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=1495175&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: Extension Modules
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Jim Jewett (jimjjewett)
Assigned to: Nobody/Anonymous (nobody)
Summary: OverflowWarning still in 2.5 despite docstring

Initial Comment:
>>> OverflowWarning.__doc__
"Base class for warnings about numeric overflow.  Won'
t exist in Python 2.5."

>>> sys.version
'2.5a2 (r25a2:45740, Apr 27 2006, 06:31:19) [MSC v.
1310 32 bit (Intel)]'



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1495175&group_id=5470

From noreply at sourceforge.net  Thu May 25 23:45:49 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 25 May 2006 14:45:49 -0700
Subject: [ python-Bugs-1494671 ] PyOS_ascii_strtod() uses malloc() directly
Message-ID: <E1FjNeP-00058y-F1@sc8-sf-web1.sourceforge.net>

Bugs item #1494671, was opened at 2006-05-25 00:51
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1494671&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: Fixed
Priority: 5
Submitted By: Brett Cannon (bcannon)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyOS_ascii_strtod() uses malloc() directly

Initial Comment:
Line 103 shows a use of a bare malloc() instead of the
proper memory-related macro.

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-05-25 21:45

Message:
Logged In: YES 
user_id=849994

Reopening as there is no check for the return value of
malloc, as Tim noticed on python-cvs.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2006-05-25 20:45

Message:
Logged In: YES 
user_id=357491

Changed in rev. 46253 to use PyMem_MALLOC/PyMem_FREE .

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2006-05-25 20:24

Message:
Logged In: YES 
user_id=357491

OK.  Well, considered it is free within the function and all
memory use is done through C API functions (memcpy() and
strtod() specifically, I don't see any reason not to move
over to PyMem_Malloc() since I can do that quickly.

Oh, and the file is Python/pystrtod.c and it's line 104 for
those who don't know where the function is.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-05-25 01:18

Message:
Logged In: YES 
user_id=31435

Well, it's not really a bug.  If a module wants to use
malloc/free internally, that's fine.  I can't think of a
reason for _why_ this code wants to do that, but it doesn't
really hurt.

Somtimes there is a good reason.  For example, the code
providing a portable notion of thread-local storage in
thread.c uses malloc deliberately, because those functions
can be called when the GIL isn't held (i.e., multiple
threads can call them simultaneously).  The Python memory
families, like almost all parts of the Python C API, are
free to assume that the GIL is held; in particular, obmalloc
does assume that, so it would be disastrous if thread.c used
that memory family instead.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1494671&group_id=5470

From noreply at sourceforge.net  Fri May 26 00:30:47 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 25 May 2006 15:30:47 -0700
Subject: [ python-Bugs-1494387 ] SVN longobject.c compiler warnings
Message-ID: <E1FjOLv-0002I9-Gk@sc8-sf-web2.sourceforge.net>

Bugs item #1494387, was opened at 2006-05-24 11:31
Message generated for change (Settings changed) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1494387&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: Accepted
Priority: 5
Submitted By: Joel Konkle-Parker (joeljkp)
>Assigned to: Nobody/Anonymous (nobody)
Summary: SVN longobject.c compiler warnings

Initial Comment:
>From SVN, longobject.c gives the following compiler
warnings (Sun Studio 11):

cc -xtarget=native64 -v -Xc -xc99=none -c  -DNDEBUG -O
 -I. -I./Include  -DPy_BUILD_CORE -o
Objects/longobject.o Objects/longobject.c
"Objects/longobject.c", line 1255: warning: statement
not reached
"Objects/longobject.c", line 1591: warning: statement
not reached
"Objects/longobject.c", line 1908: warning: statement
not reached
"Objects/longobject.c", line 1946: warning: statement
not reached

The attached patch fixes the problem.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2006-05-25 18:30

Message:
Logged In: YES 
user_id=31435

Thanks for the patch!  I don't see an actual problem with
the code as it was, and expect the compiler warnings are
bogus.  But your patch shouldn't hurt either, and makes the
intent of the macro clearer to my eyes, so I applied it to
the trunk (for Python 2.5).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1494387&group_id=5470

From noreply at sourceforge.net  Fri May 26 00:39:50 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 25 May 2006 15:39:50 -0700
Subject: [ python-Bugs-1495210 ] Install under osx 10.4.6 breaks shell.
Message-ID: <E1FjOUg-0002t0-QL@sc8-sf-web1.sourceforge.net>

Bugs item #1495210, was opened at 2006-05-25 14:39
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=1495210&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Macintosh
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: ephantom (ephantom)
Assigned to: Jack Jansen (jackjansen)
Summary: Install under osx 10.4.6 breaks shell.

Initial Comment:
Build.txt:
# BUILD INFO
# Date: Fri Apr  7 11:07:14 2006
# By: Ronald Oussoren

The Universal-MacPython-2.4.3-2006-04-07.dmg seems to kludge 
terminal's shell.  We installed it on two systems running 10.4.6, both 
systems had a previous version of python on them (2.3.5). On one system 
the shell broke to where it would not run UNIX commands, even after a 
re-boot. Under both systems the following shell errors occurred right 
after install.  The error appears when you first initiate the shell, or change 
shells.

glacier-wl:~ support$ csh
csh: Badly placed ()'s.

sh-2.05b$ tcsh
tcsh: Badly placed ()'s.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1495210&group_id=5470

From noreply at sourceforge.net  Fri May 26 00:43:30 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 25 May 2006 15:43:30 -0700
Subject: [ python-Bugs-1495210 ] Install under osx 10.4.6 breaks shell.
Message-ID: <E1FjOYE-0005q5-FR@sc8-sf-web3.sourceforge.net>

Bugs item #1495210, was opened at 2006-05-25 14:39
Message generated for change (Comment added) made by ephantom
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1495210&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Macintosh
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: ephantom (ephantom)
Assigned to: Jack Jansen (jackjansen)
Summary: Install under osx 10.4.6 breaks shell.

Initial Comment:
Build.txt:
# BUILD INFO
# Date: Fri Apr  7 11:07:14 2006
# By: Ronald Oussoren

The Universal-MacPython-2.4.3-2006-04-07.dmg seems to kludge 
terminal's shell.  We installed it on two systems running 10.4.6, both 
systems had a previous version of python on them (2.3.5). On one system 
the shell broke to where it would not run UNIX commands, even after a 
re-boot. Under both systems the following shell errors occurred right 
after install.  The error appears when you first initiate the shell, or change 
shells.

glacier-wl:~ support$ csh
csh: Badly placed ()'s.

sh-2.05b$ tcsh
tcsh: Badly placed ()'s.



----------------------------------------------------------------------

>Comment By: ephantom (ephantom)
Date: 2006-05-25 14:43

Message:
Logged In: YES 
user_id=1528840

Addendum: Both systems where PPC G4 systems, and not Intel chipsets.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1495210&group_id=5470

From noreply at sourceforge.net  Fri May 26 01:33:28 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 25 May 2006 16:33:28 -0700
Subject: [ python-Bugs-1495229 ] W3C <-> Python DOM type mapping docs need
	updating
Message-ID: <E1FjPKa-0005Ad-Ma@sc8-sf-web2.sourceforge.net>

Bugs item #1495229, was opened at 2006-05-25 16:33
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=1495229&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: Mike Brown (mike_j_brown)
Assigned to: Nobody/Anonymous (nobody)
Summary: W3C <-> Python DOM type mapping docs need updating

Initial Comment:
I believe the information at
http://docs.python.org/lib/dom-type-mapping.html is
outdated; most if not all boolean return values, at
least in minidom, are handled as BooleanType, not
IntegerType. This should be standard.

Sorry, I don't have a patch to submit for this. Should
be an easy fix though.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1495229&group_id=5470

From noreply at sourceforge.net  Fri May 26 09:02:46 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 26 May 2006 00:02:46 -0700
Subject: [ python-Bugs-1495033 ] int/long assume that the buffer ends in \0 =>
	CRASH
Message-ID: <E1FjWLO-0008IP-5i@sc8-sf-web4-b.sourceforge.net>

Bugs item #1495033, was opened at 2006-05-25 08:51
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1495033&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: 7
Submitted By: James Y Knight (foom)
>Assigned to: Brett Cannon (bcannon)
Summary: int/long assume that the buffer ends in \0 => CRASH

Initial Comment:
But it doesn't, always.

>>> int(buffer('123a', 0, 3))
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ValueError: invalid literal for int(): 123a

Hmmmmmm...well if that works, how about this one:

>>> import array; int(buffer(array.array('c', [])))
***SEGFAULT***

Ah, there we go, a nice crasher.

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-05-26 00:02

Message:
Logged In: YES 
user_id=33168

Brett, here's an easy one for ya to get started. :-)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1495033&group_id=5470

From noreply at sourceforge.net  Fri May 26 12:41:24 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 26 May 2006 03:41:24 -0700
Subject: [ python-Bugs-1495210 ] Install under osx 10.4.6 breaks shell.
Message-ID: <E1FjZky-0008BS-2Z@sc8-sf-web5.sourceforge.net>

Bugs item #1495210, was opened at 2006-05-26 00:39
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1495210&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Macintosh
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: ephantom (ephantom)
>Assigned to: Ronald Oussoren (ronaldoussoren)
Summary: Install under osx 10.4.6 breaks shell.

Initial Comment:
Build.txt:
# BUILD INFO
# Date: Fri Apr  7 11:07:14 2006
# By: Ronald Oussoren

The Universal-MacPython-2.4.3-2006-04-07.dmg seems to kludge 
terminal's shell.  We installed it on two systems running 10.4.6, both 
systems had a previous version of python on them (2.3.5). On one system 
the shell broke to where it would not run UNIX commands, even after a 
re-boot. Under both systems the following shell errors occurred right 
after install.  The error appears when you first initiate the shell, or change 
shells.

glacier-wl:~ support$ csh
csh: Badly placed ()'s.

sh-2.05b$ tcsh
tcsh: Badly placed ()'s.



----------------------------------------------------------------------

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-05-26 12:41

Message:
Logged In: YES 
user_id=580910

Assigned to me because I'm at fault here.

This seems to be a bug in one of the postinstall scripts, I'll have a look. Sorry 
about the inconvenience.

----------------------------------------------------------------------

Comment By: ephantom (ephantom)
Date: 2006-05-26 00:43

Message:
Logged In: YES 
user_id=1528840

Addendum: Both systems where PPC G4 systems, and not Intel chipsets.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1495210&group_id=5470

From noreply at sourceforge.net  Fri May 26 13:18:27 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 26 May 2006 04:18:27 -0700
Subject: [ python-Bugs-1495210 ] Install under osx 10.4.6 breaks shell.
Message-ID: <E1FjaKp-0001kg-ID@sc8-sf-web1.sourceforge.net>

Bugs item #1495210, was opened at 2006-05-26 00:39
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1495210&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Macintosh
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: ephantom (ephantom)
Assigned to: Ronald Oussoren (ronaldoussoren)
Summary: Install under osx 10.4.6 breaks shell.

Initial Comment:
Build.txt:
# BUILD INFO
# Date: Fri Apr  7 11:07:14 2006
# By: Ronald Oussoren

The Universal-MacPython-2.4.3-2006-04-07.dmg seems to kludge 
terminal's shell.  We installed it on two systems running 10.4.6, both 
systems had a previous version of python on them (2.3.5). On one system 
the shell broke to where it would not run UNIX commands, even after a 
re-boot. Under both systems the following shell errors occurred right 
after install.  The error appears when you first initiate the shell, or change 
shells.

glacier-wl:~ support$ csh
csh: Badly placed ()'s.

sh-2.05b$ tcsh
tcsh: Badly placed ()'s.



----------------------------------------------------------------------

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-05-26 13:18

Message:
Logged In: YES 
user_id=580910

This is now fixed in the trunk, and will be fixed in the next release of the 
universal build as well.

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-05-26 12:41

Message:
Logged In: YES 
user_id=580910

Assigned to me because I'm at fault here.

This seems to be a bug in one of the postinstall scripts, I'll have a look. Sorry 
about the inconvenience.

----------------------------------------------------------------------

Comment By: ephantom (ephantom)
Date: 2006-05-26 00:43

Message:
Logged In: YES 
user_id=1528840

Addendum: Both systems where PPC G4 systems, and not Intel chipsets.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1495210&group_id=5470

From noreply at sourceforge.net  Fri May 26 13:19:02 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 26 May 2006 04:19:02 -0700
Subject: [ python-Bugs-1495210 ] Install under osx 10.4.6 breaks shell.
Message-ID: <E1FjaLO-0001vD-R7@sc8-sf-web1.sourceforge.net>

Bugs item #1495210, was opened at 2006-05-26 00:39
Message generated for change (Settings changed) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1495210&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Macintosh
Group: Python 2.4
>Status: Pending
>Resolution: Fixed
Priority: 5
Submitted By: ephantom (ephantom)
Assigned to: Ronald Oussoren (ronaldoussoren)
Summary: Install under osx 10.4.6 breaks shell.

Initial Comment:
Build.txt:
# BUILD INFO
# Date: Fri Apr  7 11:07:14 2006
# By: Ronald Oussoren

The Universal-MacPython-2.4.3-2006-04-07.dmg seems to kludge 
terminal's shell.  We installed it on two systems running 10.4.6, both 
systems had a previous version of python on them (2.3.5). On one system 
the shell broke to where it would not run UNIX commands, even after a 
re-boot. Under both systems the following shell errors occurred right 
after install.  The error appears when you first initiate the shell, or change 
shells.

glacier-wl:~ support$ csh
csh: Badly placed ()'s.

sh-2.05b$ tcsh
tcsh: Badly placed ()'s.



----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-05-26 13:18

Message:
Logged In: YES 
user_id=580910

This is now fixed in the trunk, and will be fixed in the next release of the 
universal build as well.

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-05-26 12:41

Message:
Logged In: YES 
user_id=580910

Assigned to me because I'm at fault here.

This seems to be a bug in one of the postinstall scripts, I'll have a look. Sorry 
about the inconvenience.

----------------------------------------------------------------------

Comment By: ephantom (ephantom)
Date: 2006-05-26 00:43

Message:
Logged In: YES 
user_id=1528840

Addendum: Both systems where PPC G4 systems, and not Intel chipsets.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1495210&group_id=5470

From noreply at sourceforge.net  Fri May 26 14:19:22 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 26 May 2006 05:19:22 -0700
Subject: [ python-Bugs-1495488 ] make altinstall installs pydoc
Message-ID: <E1FjbHm-0005UO-3T@sc8-sf-web5.sourceforge.net>

Bugs item #1495488, was opened at 2006-05-26 12:19
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=1495488&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: Tim Heaney (theaney)
Assigned to: Nobody/Anonymous (nobody)
Summary: make altinstall installs pydoc

Initial Comment:

I did the "make altinstall" rather than the "make
install" as suggested on

  http://www.python.org/download/releases/2.5/

This worked great, creating a 

  /usr/local/bin/python2.5

which doesn't clash with my /usr/bin/python. However,
it also created a

  /usr/local/bin/pydoc

which did clash with my /usr/bin/pydoc. I just removed
it and all is well. Should altinstall not create pydoc?
It could create pydoc2.5 rather than pydoc, but then
the shebang line would have to be changed to python2.5.
What about smtpd.py, idle, and python-config, which
were also created by altinstall? They don't currently
conflict with anything I have for Python 2.4, but the
potential is there for the same problem.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1495488&group_id=5470

From noreply at sourceforge.net  Fri May 26 15:16:46 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 26 May 2006 06:16:46 -0700
Subject: [ python-Bugs-1229380 ] No struct.pack exception for some out of
	range integers
Message-ID: <E1FjcBK-0002Vm-H2@sc8-sf-web2.sourceforge.net>

Bugs item #1229380, was opened at 2005-06-28 19:30
Message generated for change (Comment added) made by etrepum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1229380&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: Adal Chiriliuc (adalx)
Assigned to: Bob Ippolito (etrepum)
Summary: No struct.pack exception for some out of range integers

Initial Comment:
struct.pack("B", -1) generates an OverflowError
exception since the B format corresponds to the
"unsigned char" type which can have values between 0
and 255.

But struct.pack("I", -1) and struct.pack("L", -1) do
not generate these errors, even if struct.pack("I",
-1L) and struct.pack("L", -1L) do (notice the final L).


----------------------------------------------------------------------

>Comment By: Bob Ippolito (etrepum)
Date: 2006-05-26 09:16

Message:
Logged In: YES 
user_id=139309

The test suite now covers this issue and it's fixed in revision 46320.

Note that this is definitely a backwards incompatible change and we might have 
to change it to a warning or something stupid like that.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-05-24 06:25

Message:
Logged In: YES 
user_id=849994

Assigning to Bob since he rewrote/extended the struct module
for 2.5.

----------------------------------------------------------------------

Comment By: Ilya Sandler (isandler)
Date: 2006-04-27 10:46

Message:
Logged In: YES 
user_id=971153


Also it appears that there is some kind of interference
between range checking and byte-order chars:

  import struct; struct.pack("H", 70000)  #Exception

  import struct; struct.pack(">H", 70000) # no exception

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-02-20 15:52

Message:
Logged In: YES 
user_id=849994

Attaching patch, raises struct.error. Neal, please look over it.

Note that I find struct's error handling confusing: it's not
clear from the docs in which cases OverflowError is raised,
and in which struct.error.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1229380&group_id=5470

From noreply at sourceforge.net  Fri May 26 15:20:18 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 26 May 2006 06:20:18 -0700
Subject: [ python-Bugs-1486897 ] OS X framework build for python 2.5 fails,
	configure is odd
Message-ID: <E1FjcEk-0001oE-2s@sc8-sf-web5.sourceforge.net>

Bugs item #1486897, was opened at 2006-05-11 23:44
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1486897&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: 5
Submitted By: Christopher Knox (vizowl)
Assigned to: Ronald Oussoren (ronaldoussoren)
Summary: OS X framework build for python 2.5 fails, configure is odd

Initial Comment:
The OS X framework build for python 2.5 does not install a dynamic 
library at /Library/Frameworks/Python.framework/Versions/2.5/Python 
where it should. The python2.5 executible does not run because it is 
trying to load this dynamic library.

This is on an intel mac with darwin-8.6.1 and gcc4 and python2.5a2.

Also all of the extra modules (_CG extension, IDLE extra) fail to link 
because their link command is -lpython2.5 which is not what it should be 
for a framework build and even if it was correct for linking agianst a 
framework it would fil because the framework doesn't have its library 
anyway.

Finally, the configure script behaves oddly in that it works fine, but if you 
change the parameters and rerun it it will fail unless you run 'make 
distclean'

This is where it fails.

checking whether mmap with MAP_ANON(YMOUS) works... yes
configure: error: "libffi has not been ported to i686-apple-darwin8.6.1."
Failed to configure _ctypes module

----------------------------------------------------------------------

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-05-26 15:20

Message:
Logged In: YES 
user_id=580910

I've checked in a patch that makes it possible to use 'make install' to install a 
framework. 

--enable-profiling still doesn't work and I won't look into this anytime soon ;-(

----------------------------------------------------------------------

Comment By: Christopher Knox (vizowl)
Date: 2006-05-23 20:11

Message:
Logged In: YES 
user_id=1346203

Yeah - it works fine without --enable-profiling - I forgot that you said not to 
use it. I fear I am being less than helpful today.



----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-05-23 19:44

Message:
Logged In: YES 
user_id=580910

Why do you try to use --enable-profiling with a framework install? Whenever I 
need such a special build I generally install a normal unix build in a 
temporary location.

I know --enable-framework doesn't clean up after itself. It does work 
correctly in a seperate build directory though, that way you can just dump the 
build directory to clean up.

BTW. Integrating 'make frameworkinstall' into 'make install' seems to be 
pretty easy, I might check in a patch later this week.

--enable-profiling crashes for me too, I don't have time to look into this at 
the moment.

----------------------------------------------------------------------

Comment By: Christopher Knox (vizowl)
Date: 2006-05-23 18:54

Message:
Logged In: YES 
user_id=1346203

Sorry - it was too early in the morning here and I forgot about the 
frameworkinstall....

The frameworkinstall does not quite work.

It looks like it installs everything critical and then fails on the MacPython 
stuff. Specifically, it fails here:

/usr/bin/install -c -s ../../python.exe "/Library/Frameworks/
Python.framework/Versions/2.5/Resources/Python.app/Contents/MacOS/
Python"
../../python.exe ./../scripts/BuildApplet.py \
--destroot "" \
        --python /Library/Frameworks/Python.framework/Versions/2.5/
Resources/Python.app/Contents/MacOS/Python \
        --output "/Applications/MacPython 2.5/Build Applet.app" \
        ./../scripts/BuildApplet.py
make[1]: *** [install_BuildApplet] Bus error
make: *** [frameworkinstallapps] Error 2

However, I can still run the python interpeter - although when I exit the 
interpretor it says "mcount: gmon.out: Permission denied"

frameworkinstall does overwrite the Current symlink - but I just fixed it 
manually.

Also I noticed that make clean does not remove the actual dynamic library 
called 'Python' from the Python.framework directory in the build directory

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-05-23 18:26

Message:
Logged In: YES 
user_id=580910

You shouldn't use make install, but make frameworkinstall.  This is documented 
in Mac/OSX/README.

I wouldn't mind seeing a patch that makes it possible to install a framework 
using 'make install', but that's very low on my todo-list.

----------------------------------------------------------------------

Comment By: Christopher Knox (vizowl)
Date: 2006-05-23 17:41

Message:
Logged In: YES 
user_id=1346203

I checked out rev 46110 and it is almost fixed.

It builds correctly now - however the make install (or altinstall) does not copy 
the dynamic library into the framework. It is built into BUILD_ROOT/
Python.Framework/Versions/2.5/Python and after installation it should land 
up in /Library/Frameworks/Python.framework/Versions/2.5/Python - but 
nothing is there. If I copy it over manually then the python2.5 interpeter will 
run.

The 2.4 framework has a symlink from /Library/Frameworks/
Python.framework/Python to /Library/Frameworks/Python.framework/
Versions/2.4/Python

The rest of my comment is more of an aside than a bug...

The equivalent symlink exists in the built version of the 2.5 framework and it 
chould not (and does not currently) get transferred into /Library/
Frameworks/Python.framework. However, if someone wanted to upgrade 
from python2.4 to 2.5 then the symlink should also be updated - otherwise 
when people add the linker flag -framework Python to their builds it will keep 
linking against the 2.4 dynamic lib.

Also I am not sure what happened with the build log - it is fine when I 
download it - but it doesn't matter now

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-05-23 14:13

Message:
Logged In: YES 
user_id=580910

I've checked in a fix in revision 46103. Could you please test if this solves the 
problems for you?

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-05-23 13:27

Message:
Logged In: YES 
user_id=580910

I'm currently building the trunk and I'm seeing the same issue as you. The 
problem is caused by the checkin at revision 45232 by Martin van Loewis. This 
forces '-lpython2.5' onto the commandline for the linker when building 
extensions.

I'm working on a patch that disables this feature for framework builds.


----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-05-23 13:07

Message:
Logged In: YES 
user_id=580910

The configure failure in the orginal message is not a problem, that's libffi failing. 
Libffi is used by ctypes and not supported on darwin/x86. I have a patch and I 
know of another one, but neither have been merged into the copy that's used by 
ctypes. The only effect of this is that you won't get ctypes.

Could you test  again without --enable-profiling? That's one flag I've never used 
and didn't test yet. BTW. the attached build log contains lots of NUL bytes, 
should it or has it been corrupted along the way?

----------------------------------------------------------------------

Comment By: Christopher Knox (vizowl)
Date: 2006-05-15 19:13

Message:
Logged In: YES 
user_id=1346203

Hi Neal,

I checked out rev 46003 (the HEAD at the time) in a clean directory and used: 

./configure --enable-profiling --enable-shared --enable-framework --
enable-universalsdk

Unfortunately it failed in the same way it has the same problems in that it is 
linking with the flag -lpython2.5 when it should be a framework linking. I 
have attached the build log from after having built it once so you only see the 
linking.

However, it does appear that the issue raised in bug # 1487105 is solved. It 
compiled fine on an intel mac it just has linking problems.

Also I get exactly the same problem on a G5

Chris

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-05-15 08:25

Message:
Logged In: YES 
user_id=33168

Christopher can you try with a current checkout?  Ronald
checked in lots of changes which I think include x86 support
at svn rev 45997.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1486897&group_id=5470

From noreply at sourceforge.net  Fri May 26 16:42:39 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 26 May 2006 07:42:39 -0700
Subject: [ python-Bugs-1483133 ] gen_iternext: Assertion `f->f_back != ((void
	*)0)' failed
Message-ID: <E1FjdWR-0003Wk-TZ@sc8-sf-web5.sourceforge.net>

Bugs item #1483133, was opened at 2006-05-07 00:09
Message generated for change (Comment added) made by svensoho
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1483133&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: 8
Submitted By: svensoho (svensoho)
Assigned to: Phillip J. Eby (pje)
Summary: gen_iternext: Assertion `f->f_back != ((void *)0)' failed

Initial Comment:
Seems to be similar bug as http://sourceforge.net/
tracker/index.php?
func=detail&aid=1257960&group_id=5470&atid=105470 
(fixed)

Couldn't trigger with same script but with C 
application. Same source modification helps (at 
Objects/genobject.c:53)

----------------------------------------------------------------------

>Comment By: svensoho (svensoho)
Date: 2006-05-26 17:42

Message:
Logged In: YES 
user_id=1518209

This bug is blocking development of PostgreSQL Python based 
stored procedure language -- PL/Python.
See http://archives.postgresql.org/pgsql-patches/2006-04/msg
00265.php


----------------------------------------------------------------------

Comment By: svensoho (svensoho)
Date: 2006-05-15 11:26

Message:
Logged In: YES 
user_id=1518209




----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1483133&group_id=5470

From noreply at sourceforge.net  Fri May 26 23:28:17 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 26 May 2006 14:28:17 -0700
Subject: [ python-Bugs-1495754 ] os.listdir(): inconsistent behavior with
	trailing spaces
Message-ID: <E1Fjjqz-0005dK-Dk@sc8-sf-web1.sourceforge.net>

Bugs item #1495754, was opened at 2006-05-26 16:28
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=1495754&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: Windows
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Kenneth J. Pronovici (pronovic)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.listdir(): inconsistent behavior with trailing spaces

Initial Comment:
I've noticed some inconsistent behavior around 
os.listdir() and paths that contain trailing spaces on 
the Windows platform.

Take this example code:

   import os
   import tempfile
   tmpdir = tempfile.mkdtemp()
   newdir = os.path.join(tmpdir, " collect dir ")
   os.mkdir(newdir)
   print os.path.exists(newdir)
   print os.listdir(newdir)

If I run this code on Windows 2000 Pro using Python 
2.4.2, I get this:

True
[Errno 3] The system cannot find the path 
specified: 'c:\\docume~1\\a0clu0~1.bcb\\locals~1
\\temp\\tmpfd7j3t\\ collect dir /*.*'

It seems to me that if os.path.exists() tells me that 
a file or directory exists, that os.listdir() should 
be able to operate on it.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1495754&group_id=5470

From noreply at sourceforge.net  Sat May 27 01:30:15 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 26 May 2006 16:30:15 -0700
Subject: [ python-Bugs-1495802 ] Still a problem
Message-ID: <E1Fjll1-0003Cd-VM@sc8-sf-web1.sourceforge.net>

Bugs item #1495802, was opened at 2006-05-26 16:30
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=1495802&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: jpsc986_hj (jpsc986_hj)
Assigned to: Nobody/Anonymous (nobody)
Summary: Still a problem

Initial Comment:
Look like I have similar problem with cygwin


I do the followings

   si,so,se = os.popen3('make all')
   dresult = so.readlines()
   eresult = so.readlines()

where make all does a build - and with tons of error 
on stderror.  After x minutes, I can see the program 
to lock up.  




----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1495802&group_id=5470

From noreply at sourceforge.net  Sat May 27 05:51:03 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 26 May 2006 20:51:03 -0700
Subject: [ python-Bugs-1495802 ] cygwin: popen3 lock up
Message-ID: <E1FjppP-00005Z-9p@sc8-sf-web2.sourceforge.net>

Bugs item #1495802, was opened at 2006-05-26 16:30
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1495802&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: jpsc986_hj (jpsc986_hj)
Assigned to: Nobody/Anonymous (nobody)
>Summary: cygwin: popen3 lock up

Initial Comment:
Look like I have similar problem with cygwin


I do the followings

   si,so,se = os.popen3('make all')
   dresult = so.readlines()
   eresult = so.readlines()

where make all does a build - and with tons of error 
on stderror.  After x minutes, I can see the program 
to lock up.  




----------------------------------------------------------------------

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

Message:
Logged In: YES 
user_id=33168

A similar problem to what?

Can you provide any more info or help debug this problem?  I
don't have a windows box, so I can't begin to help with this.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1495802&group_id=5470

From noreply at sourceforge.net  Sat May 27 07:47:24 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 26 May 2006 22:47:24 -0700
Subject: [ python-Bugs-1495802 ] cygwin: popen3 lock up
Message-ID: <E1Fjre0-00070O-IB@sc8-sf-web3.sourceforge.net>

Bugs item #1495802, was opened at 2006-05-26 16:30
Message generated for change (Comment added) made by jpsc986_hj
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1495802&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: jpsc986_hj (jpsc986_hj)
Assigned to: Nobody/Anonymous (nobody)
Summary: cygwin: popen3 lock up

Initial Comment:
Look like I have similar problem with cygwin


I do the followings

   si,so,se = os.popen3('make all')
   dresult = so.readlines()
   eresult = so.readlines()

where make all does a build - and with tons of error 
on stderror.  After x minutes, I can see the program 
to lock up.  




----------------------------------------------------------------------

>Comment By: jpsc986_hj (jpsc986_hj)
Date: 2006-05-26 22:47

Message:
Logged In: YES 
user_id=1356401

Ooops - I make a typo

it should be 

   eresult = se.readlines()
not 
    ersult = so.readlines()



----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-05-26 20:51

Message:
Logged In: YES 
user_id=33168

A similar problem to what?

Can you provide any more info or help debug this problem?  I
don't have a windows box, so I can't begin to help with this.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1495802&group_id=5470

From noreply at sourceforge.net  Sat May 27 17:21:37 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 27 May 2006 08:21:37 -0700
Subject: [ python-Bugs-1496032 ] test_float segfaults with SIGFPE on FreeBSD
	6.0 / Alpha
Message-ID: <E1Fk0bh-00017B-KJ@sc8-sf-web4-b.sourceforge.net>

Bugs item #1496032, was opened at 2006-05-27 11:21
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=1496032&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: Bob Ippolito (etrepum)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_float segfaults with SIGFPE on FreeBSD 6.0 / Alpha

Initial Comment:
Program received signal SIGFPE, Arithmetic exception.
0x0000000160418568 in bu_double (p=0x12049d29c "", f=0x0) at /
house/etrepum/src/python-46462/Modules/_struct.c:219

(this is actually due to _PyFloat_Unpack8)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1496032&group_id=5470

From noreply at sourceforge.net  Sat May 27 18:12:58 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 27 May 2006 09:12:58 -0700
Subject: [ python-Bugs-1496032 ] test_float segfaults with SIGFPE on FreeBSD
	6.0 / Alpha
Message-ID: <E1Fk1PO-0006CK-Di@sc8-sf-web4-b.sourceforge.net>

Bugs item #1496032, was opened at 2006-05-27 11:21
Message generated for change (Comment added) made by etrepum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1496032&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: Bob Ippolito (etrepum)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_float segfaults with SIGFPE on FreeBSD 6.0 / Alpha

Initial Comment:
Program received signal SIGFPE, Arithmetic exception.
0x0000000160418568 in bu_double (p=0x12049d29c "", f=0x0) at /
house/etrepum/src/python-46462/Modules/_struct.c:219

(this is actually due to _PyFloat_Unpack8)

----------------------------------------------------------------------

>Comment By: Bob Ippolito (etrepum)
Date: 2006-05-27 12:12

Message:
Logged In: YES 
user_id=139309

More fun in test_long

Program received signal SIGFPE, Arithmetic exception.
0x000000012003972c in float_richcompare (v=0x120397080, 
w=0x1203e7a00, op=2) at ../Objects/floatobject.c:387
387             else if (!Py_IS_FINITE(i)) {

----------------------------------------------------------------------

Comment By: Bob Ippolito (etrepum)
Date: 2006-05-27 12:12

Message:
Logged In: YES 
user_id=139309

More fun in test_long

Program received signal SIGFPE, Arithmetic exception.
0x000000012003972c in float_richcompare (v=0x120397080, 
w=0x1203e7a00, op=2) at ../Objects/floatobject.c:387
387             else if (!Py_IS_FINITE(i)) {

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1496032&group_id=5470

From noreply at sourceforge.net  Sat May 27 18:12:59 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 27 May 2006 09:12:59 -0700
Subject: [ python-Bugs-1496032 ] test_float segfaults with SIGFPE on FreeBSD
	6.0 / Alpha
Message-ID: <E1Fk1PP-0005Di-8E@sc8-sf-web1.sourceforge.net>

Bugs item #1496032, was opened at 2006-05-27 11:21
Message generated for change (Comment added) made by etrepum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1496032&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: Bob Ippolito (etrepum)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_float segfaults with SIGFPE on FreeBSD 6.0 / Alpha

Initial Comment:
Program received signal SIGFPE, Arithmetic exception.
0x0000000160418568 in bu_double (p=0x12049d29c "", f=0x0) at /
house/etrepum/src/python-46462/Modules/_struct.c:219

(this is actually due to _PyFloat_Unpack8)

----------------------------------------------------------------------

>Comment By: Bob Ippolito (etrepum)
Date: 2006-05-27 12:12

Message:
Logged In: YES 
user_id=139309

More fun in test_long

Program received signal SIGFPE, Arithmetic exception.
0x000000012003972c in float_richcompare (v=0x120397080, 
w=0x1203e7a00, op=2) at ../Objects/floatobject.c:387
387             else if (!Py_IS_FINITE(i)) {

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1496032&group_id=5470

From noreply at sourceforge.net  Sat May 27 18:15:38 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 27 May 2006 09:15:38 -0700
Subject: [ python-Bugs-698374 ] urllib2 Request.get_host and proxies
Message-ID: <E1Fk1Ry-0006Pb-T0@sc8-sf-web1.sourceforge.net>

Bugs item #698374, was opened at 2003-03-05 23:46
Message generated for change (Comment added) made by jjlee
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=698374&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
Resolution: None
Priority: 5
Submitted By: John J Lee (jjlee)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2 Request.get_host and proxies

Initial Comment:
I think the Request.get_host method should not return  
the host of the proxy in the case where a proxy has  
been set.  There should be a separate method for  
returning the proxy's hostname.  I'm baffled as to why  
someone thought a request's host is its proxy's host!  
Am I missing something?  
  
Note that this bug is related to 413135 -- should both  
be fixed simultaneously.  
  
I'll upload a patch eventually.  
 

----------------------------------------------------------------------

>Comment By: John J Lee (jjlee)
Date: 2006-05-27 17:15

Message:
Logged In: YES 
user_id=261020

It would probably cause too much breakage to fix this, so
I'm closing it.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=698374&group_id=5470

From noreply at sourceforge.net  Sat May 27 20:34:06 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 27 May 2006 11:34:06 -0700
Subject: [ python-Bugs-1481296 ] long(float('nan'))!=0L
Message-ID: <E1Fk3by-0007Nb-7i@sc8-sf-web1.sourceforge.net>

Bugs item #1481296, was opened at 2006-05-03 20:39
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1481296&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.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Erik Dahl (edahl)
Assigned to: Nobody/Anonymous (nobody)
Summary: long(float('nan'))!=0L

Initial Comment:
on all platforms I can test long(float('nan'))=0L

But on maxos X intel long(float('nan'))!=0L

it returns:

000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000L

This is a problem because:

>>> 344 - long(float('nan'))    
Objects/longobject.c:1645: failed assertion `borrow == 0'
Abort trap




----------------------------------------------------------------------

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-05-27 20:34

Message:
Logged In: YES 
user_id=580910

This could quite easily be fixed by testing for NaN in PyLong_FromDouble, such 
as the attached patch. This works correctly on OSX, but I have no idea if this will 
work on other platforms, that depends on how portable the already existing 
Py_IS_NAN macro is.  C99 also introduces an fpclassify and isnan functions that 
could be used (Py_IS_NAN uses neither because Python is written in C89 instead 
of C99).

----------------------------------------------------------------------

Comment By: Erik Dahl (edahl)
Date: 2006-05-10 14:36

Message:
Logged In: YES 
user_id=1482543

Just to be clear this does cause a crash in the interpreter.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2006-05-09 20:47

Message:
Logged In: YES 
user_id=6656

Nevertheless, assuming that a compiler implements the relavent standards (i.e. 
Appendix F of C99) it's pretty clear that what PyLong_FromDouble does with a 
nan is pretty random.  frexp(dval, &expo); for dval nan stores an unspecified 
value in expo which is then used to compute the length of the resulting long.  If 
the unspecified value is large-ish and positive, hilarity ensues.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-05-03 21:09

Message:
Logged In: YES 
user_id=31435

Try it on Windows and you'll get:

>>> long(float('nan'))
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ValueError: invalid literal for float(): nan

Nothing about the behavior of NaNs, infinities, or signed
zeroes is defined or guaranteed by Python.  You use them at
your own risk, and their behavior does vary wildly in
practice (according to the HW, OS, C compiler, C library,
and even the C compiler flags specified when compiling Python).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1481296&group_id=5470

From noreply at sourceforge.net  Sun May 28 02:15:42 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 27 May 2006 17:15:42 -0700
Subject: [ python-Bugs-1160328 ] urllib2 post error when using httpproxy
Message-ID: <E1Fk8wY-0007dO-SX@sc8-sf-web1.sourceforge.net>

Bugs item #1160328, was opened at 2005-03-10 01:37
Message generated for change (Comment added) made by jjlee
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1160328&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: small tiger (xhchen111)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2 post error when using httpproxy

Initial Comment:
==============
program
==============
# -*- coding: gbk -*-
import httplib, urllib, urllib2#, cookielib

proxy = urllib2.ProxyHandler
({'http':'http://pic:iLusalt at proxy.pconline.com.cn:8080'})
opener = urllib2.build_opener(proxy)
urllib2.install_opener(opener)

f = urllib2.urlopen
("http://192.168.10.177:8080/price/login.do?
method=list")
print f.read()

postdata = urllib.urlencode
({'userId':'admin', 'password':'admin'})
request = urllib2.Request
('http://192.168.10.177:8080/price/login.do?
method=login')
response = urllib2.urlopen(request, postdata)
print response.read()

====================
out put
====================
E:\jt>c:\python24\python t.py
Traceback (most recent call last):
  File "t.py", line 13, in ?
    response = urllib2.urlopen(request, postdata)
  File "c:\python24\lib\urllib2.py", line 130, in urlopen
    return _opener.open(url, data)
  File "c:\python24\lib\urllib2.py", line 358, in open
    response = self._open(req, data)
  File "c:\python24\lib\urllib2.py", line 376, in _open
    '_open', req)
  File "c:\python24\lib\urllib2.py", line 337, in _call_chain
    result = func(*args)
  File "c:\python24\lib\urllib2.py", line 1021, in http_open
    return self.do_open(httplib.HTTPConnection, req)
  File "c:\python24\lib\urllib2.py", line 996, in do_open
    raise URLError(err)
urllib2.URLError: <urlopen error (10053, 'Software 
caused connection abort')>

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2006-05-28 01:15

Message:
Logged In: YES 
user_id=261020

The first URL hangs for me, using Firefox.  Especially if
this depends on using a proxy which I do not have permission
to use, I have no idea how to reproduce this.  xhchen111,
are you still around?


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1160328&group_id=5470

From noreply at sourceforge.net  Sun May 28 08:36:23 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 27 May 2006 23:36:23 -0700
Subject: [ python-Bugs-1496278 ] Incorrect error message related to **kwargs
Message-ID: <E1FkEsx-0006P6-NF@sc8-sf-web5.sourceforge.net>

Bugs item #1496278, was opened at 2006-05-28 02:36
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=1496278&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: Collin Winter (collinwinter)
Assigned to: Nobody/Anonymous (nobody)
Summary: Incorrect error message related to **kwargs

Initial Comment:
"""
>>> def foo(**kwargs):
...     pass
...
>>> foo(5, 6)
TypeError: foo() takes exactly 0 arguments (2 given)
"""

It clearly does take arguments, just not positional
arguments.

The attached patch changes the message above to "foo()
takes exactly 0 non-keyword arguments", as well as
changing the message in several other, similar cases.

The patch also updates Lib/test/output/test_extcall
appropriately.

The patch is against r46495.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1496278&group_id=5470

From noreply at sourceforge.net  Sun May 28 11:26:14 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 28 May 2006 02:26:14 -0700
Subject: [ python-Bugs-1496315 ] strptime: wrong default values used to fill
	in missing data
Message-ID: <E1FkHXK-0000lZ-6V@sc8-sf-web3.sourceforge.net>

Bugs item #1496315, was opened at 2006-05-28 11:26
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=1496315&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: Markus Gritsch (markus_gritsch)
Assigned to: Nobody/Anonymous (nobody)
Summary: strptime: wrong default values used to fill in missing data

Initial Comment:
The documentation of strptime() says: """The default
values used to fill in any missing data are (1900, 1,
1, 0, 0, 0, 0, 1, -1)""".  As the example below shows,
this is not the case.

Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310
32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for
more information.
>>> import time
>>> time.strptime('', '')
(1900, 1, 1, 0, 0, 0, 0, 1, -1)
>>> time.strptime('2006', '%Y')
(2006, 1, 1, 0, 0, 0, 6, 1, -1)
>>> time.strptime('2006-05', '%Y-%m')
(2006, 5, 1, 0, 0, 0, 0, 121, -1)
>>> time.strptime('2006-05-26', '%Y-%m-%d')
(2006, 5, 26, 0, 0, 0, 4, 146, -1)
>>> time.strptime('2006-05-26 21', '%Y-%m-%d %H')
(2006, 5, 26, 21, 0, 0, 4, 146, -1)
>>> time.strptime('2006-05-26 21:06', '%Y-%m-%d %H:%M')
(2006, 5, 26, 21, 6, 0, 4, 146, -1)
>>> time.strptime('2006-05-26 21:06:11', '%Y-%m-%d
%H:%M:%S')
(2006, 5, 26, 21, 6, 11, 4, 146, -1)


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1496315&group_id=5470

From noreply at sourceforge.net  Sun May 28 19:14:04 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 28 May 2006 10:14:04 -0700
Subject: [ python-Feature Requests-1080727 ] Add encoding to DocFileSuite
Message-ID: <E1FkOq4-0004HG-0Y@sc8-sf-web4-b.sourceforge.net>

Feature Requests item #1080727, was opened at 2004-12-08 01:47
Message generated for change (Comment added) made by quiver
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1080727&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: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Bjorn Tillenius (bjoti)
Assigned to: Jim Fulton (dcjim)
Summary: Add encoding to DocFileSuite

Initial Comment:
If one writes doctests within documentation strings of classes and 
functions, it's possible to use non-ASCII characters since one can 
specify the encoding used in the source file.

But if one wants to combine the documentation and testing, by 
writing a text file, and thus use DocFileSuite, it's not possible to use 
non-ASCII characters in the tests. This is because there's no way 
of specifying which encoding the text file uses. Instead one has to 
\-quote all non-ASCII characters, and that makes the tests harder 
to read IMHO.

----------------------------------------------------------------------

>Comment By: George Yoshida (quiver)
Date: 2006-05-29 02:14

Message:
Logged In: YES 
user_id=671362

Thanks Bjorn.
Commited in revision: 46502.

----------------------------------------------------------------------

Comment By: George Yoshida (quiver)
Date: 2006-05-15 02:42

Message:
Logged In: YES 
user_id=671362

Updated the patch for the trunk.
Documentation is also included.

If there is no objection, I'll commit it before 2.5 a3 
rolled out.

----------------------------------------------------------------------

Comment By: Jim Fulton (dcjim)
Date: 2005-11-15 07:50

Message:
Logged In: YES 
user_id=73023

The patch looks good to me.  I haven't looked at the tests,
but I assume that they are good too.  I will look at them. :)

I'm also going to add PEP 263-style encoding specification.

Thanks!

----------------------------------------------------------------------

Comment By: Bjorn Tillenius (bjoti)
Date: 2005-09-14 05:12

Message:
Logged In: YES 
user_id=1032069

Attaching new version of the patch that will apply cleanly against latest CVS

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2005-09-14 03:59

Message:
Logged In: YES 
user_id=31435

Ed, can you make time to review this patch?  If not, please 
unassign it again.

----------------------------------------------------------------------

Comment By: Bjorn Tillenius (bjoti)
Date: 2004-12-19 03:05

Message:
Logged In: YES 
user_id=1032069

Uploaded new patch, which adds the possibility to specify an encoding to 
testfile as well, since I assume this is desirable.

----------------------------------------------------------------------

Comment By: Bjorn Tillenius (bjoti)
Date: 2004-12-18 23:08

Message:
Logged In: YES 
user_id=1032069

Added patch for Tim to review.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-12-15 12:09

Message:
Logged In: YES 
user_id=31435

Unassigned myself -- can't make time to work on it.  I'll be 
happy to review a patch (code/tests/docs) if one appears.  I 
approve of the idea <wink>.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1080727&group_id=5470

From noreply at sourceforge.net  Sun May 28 20:29:25 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 28 May 2006 11:29:25 -0700
Subject: [ python-Bugs-1496315 ] strptime: wrong default values used to fill
	in missing data
Message-ID: <E1FkQ0z-0003SE-Cd@sc8-sf-web4-b.sourceforge.net>

Bugs item #1496315, was opened at 2006-05-28 02:26
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1496315&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: Markus Gritsch (markus_gritsch)
>Assigned to: Brett Cannon (bcannon)
Summary: strptime: wrong default values used to fill in missing data

Initial Comment:
The documentation of strptime() says: """The default
values used to fill in any missing data are (1900, 1,
1, 0, 0, 0, 0, 1, -1)""".  As the example below shows,
this is not the case.

Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310
32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for
more information.
>>> import time
>>> time.strptime('', '')
(1900, 1, 1, 0, 0, 0, 0, 1, -1)
>>> time.strptime('2006', '%Y')
(2006, 1, 1, 0, 0, 0, 6, 1, -1)
>>> time.strptime('2006-05', '%Y-%m')
(2006, 5, 1, 0, 0, 0, 0, 121, -1)
>>> time.strptime('2006-05-26', '%Y-%m-%d')
(2006, 5, 26, 0, 0, 0, 4, 146, -1)
>>> time.strptime('2006-05-26 21', '%Y-%m-%d %H')
(2006, 5, 26, 21, 0, 0, 4, 146, -1)
>>> time.strptime('2006-05-26 21:06', '%Y-%m-%d %H:%M')
(2006, 5, 26, 21, 6, 0, 4, 146, -1)
>>> time.strptime('2006-05-26 21:06:11', '%Y-%m-%d
%H:%M:%S')
(2006, 5, 26, 21, 6, 11, 4, 146, -1)


----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2006-05-28 11:29

Message:
Logged In: YES 
user_id=357491

The docs need to be fixed to say those are the default
values except when strptime() can infer better ones.  There
is a lot of smarts in the algorithm that do calculations to
fill in missing data as best as possible, and that is what
is happening here.

Thanks for the bug report.  I will try to fix this some time
this week.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1496315&group_id=5470

From noreply at sourceforge.net  Sun May 28 20:42:52 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 28 May 2006 11:42:52 -0700
Subject: [ python-Bugs-1496501 ] tarfile.py: dict order dependency
Message-ID: <E1FkQE0-0000rF-QK@sc8-sf-web4-b.sourceforge.net>

Bugs item #1496501, was opened at 2006-05-28 18:42
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=1496501&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: Armin Rigo (arigo)
Assigned to: Nobody/Anonymous (nobody)
Summary: tarfile.py: dict order dependency

Initial Comment:
When guessing the type of a file, tarfile.py tries to
open it in .tar, .tar.gz and .tar.bz2 modes
successfully.  The problem is that in conjunction with a
fileobj argument, failed attempts can advance the
current position of the fileobj, and cause the following
attempts to fail as well.

This didn't show up so far because, by chance, the order
in which the OPEN_METH dictionary is enumerated is
somehow the "correct" one.  The problem can be seen by
changing this order and re-running test_tarfile.py; for
example, reverse the order (tarfile.py line 1013):

    for comptype in reversed(cls.OPEN_METH):


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1496501&group_id=5470

From noreply at sourceforge.net  Sun May 28 21:57:35 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 28 May 2006 12:57:35 -0700
Subject: [ python-Bugs-1496539 ] Modules in cwd can't be imported in
	interactive mode
Message-ID: <E1FkROJ-0003Zz-IH@sc8-sf-web3.sourceforge.net>

Bugs item #1496539, was opened at 2006-05-28 21:57
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=1496539&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: ?iga Seilnacht (zseil)
Assigned to: Nobody/Anonymous (nobody)
Summary: Modules in cwd can't be imported in interactive mode

Initial Comment:
Python puts an empty string as the first
element of sys.path when the script directory is
not available. Starting with revision 46372
this entry isn't interpreted as a marker for
the current working directory any more.
Windows doesn't have this problem, since
current directory is explicitly inserted
into sys.path.

How to reproduce:

Python 2.5a2 (trunk:46372M, May 28 2006, 21:29:19)
[GCC 4.1.0 (SUSE Linux)] on linux2
Type "help", "copyright", "credits" or "license"
for more information.

>>> import os
>>> import sys
>>> os.listdir(os.getcwd())
['mymodule.pyc', 'mymodule.py']
>>> import mymodule
Traceback (most recent call last):
  ...
ImportError: No module named mymodule
>>> sys.path_importer_cache[''] = True
>>> import mymodule
>>>

I tested with revisions 46371, 46372 and
46504. The problem is not present in
revision 46371, but is still present
in 46504.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1496539&group_id=5470

From noreply at sourceforge.net  Sun May 28 22:11:54 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 28 May 2006 13:11:54 -0700
Subject: [ python-Bugs-1496539 ] Modules in cwd can't be imported in
	interactive mode
Message-ID: <E1FkRcA-0007cX-1m@sc8-sf-web4-b.sourceforge.net>

Bugs item #1496539, was opened at 2006-05-28 19:57
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1496539&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: ?iga Seilnacht (zseil)
Assigned to: Nobody/Anonymous (nobody)
Summary: Modules in cwd can't be imported in interactive mode

Initial Comment:
Python puts an empty string as the first
element of sys.path when the script directory is
not available. Starting with revision 46372
this entry isn't interpreted as a marker for
the current working directory any more.
Windows doesn't have this problem, since
current directory is explicitly inserted
into sys.path.

How to reproduce:

Python 2.5a2 (trunk:46372M, May 28 2006, 21:29:19)
[GCC 4.1.0 (SUSE Linux)] on linux2
Type "help", "copyright", "credits" or "license"
for more information.

>>> import os
>>> import sys
>>> os.listdir(os.getcwd())
['mymodule.pyc', 'mymodule.py']
>>> import mymodule
Traceback (most recent call last):
  ...
ImportError: No module named mymodule
>>> sys.path_importer_cache[''] = True
>>> import mymodule
>>>

I tested with revisions 46371, 46372 and
46504. The problem is not present in
revision 46371, but is still present
in 46504.

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-05-28 20:11

Message:
Logged In: YES 
user_id=849994

This was actually sitting around in my local trunk, having
fixed it on the plane :)
Thanks for reminding me, checked in the fix in rev. 46508.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1496539&group_id=5470

From noreply at sourceforge.net  Sun May 28 22:35:09 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 28 May 2006 13:35:09 -0700
Subject: [ python-Bugs-1496561 ] Building Python 2.4.3 on Solaris 9/10 with
	Sun Studio 11
Message-ID: <E1FkRyf-00072n-Mj@sc8-sf-web5.sourceforge.net>

Bugs item #1496561, was opened at 2006-05-28 22:35
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=1496561&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Andreas (andyfloe)
Assigned to: Nobody/Anonymous (nobody)
Summary: Building Python 2.4.3 on Solaris 9/10 with Sun Studio 11

Initial Comment:
If Python 2.4.3 is build on Solaris 9 or 10 with Sun
Studio 11 [cc: Sun C 5.8 2005/10/13], some of the tests
of roundup fail with a core dump of Python. If build
with gcc [gcc (GCC) 3.4.3
(csl-sol210-3_4-branch+sol_rpath)] all runs as expected.

I have compiled Python and bsd 4.3 on Solaris with Sun
Studio as follows:

##-- rebuild Berkeley DB version 4.3.29 

URL='http://www.sleepycat.com'
BUILDDIR=/builddir
SRCDIR=/mnt/a
VERSION=4.3.29
PKG=db
STAR="${PKG}"-"${VERSION}".tar.gz

cd "$BUILDDIR"
gunzip -d -c "${SRCDIR}"/"${STAR}" | tar xvf -

cd "${PKG}-${VERSION}"

PREFIX=/opt/db4
CC=cc; export CC
CXX=CC; export CXX
PATH=/opt/SUNWspro/bin:/usr/ccs/bin:/usr/sbin:/usr/bin;
export PATH
unset LD_LIBRARY_PATH
TIMESTAMP=`date +%Y%m%d%H%M%S`

cd build_unix
../dist/configure --prefix="${PREFIX}" \
    --enable-compat185 --disable-dump185 \
    --enable-shared --enable-static --enable-cxx 2>&1 | \
    tee /var/tmp/"${PKG}-${VERSION}"_configure_${TIMESTAMP}
make 2>&1 | tee
/var/tmp/"${PKG}-${VERSION}"_make_${TIMESTAMP}
##- install
## done as user 'root'

#- source the above environment variables
cd "$BUILDDIR"/"${PKG}"-"${VERSION}"/build_unix
make install 2>&1 | \
	tee /var/tmp/"${PKG}-${VERSION}"_make_install_`date
'+%Y%m%d%H%M%S'` 
cd ..

LIBS='
/opt/db4/lib/libdb-4.3.so
/opt/db4/lib/libdb-4.3.la
/opt/db4/lib/libdb_cxx-4.3.so
/opt/db4/lib/libdb_cxx-4.3.la
/opt/db4/lib/libdb-4.3.a
/opt/db4/lib/libdb.a
/opt/db4/lib/libdb_cxx-4.3.a
/opt/db4/lib/libdb_cxx.a
/opt/db4/lib/libdb_cxx.so
'
ls -l $LIBS
chown root:root $LIBS
chmod 755 $LIBS
cd /usr/include
## the setup.py script in the Python source only looks
for specific
## locations for the header file for the bsddb
ln -s /opt/db4/include /usr/include/db4
# chmod 755 /usr/lib/libdb*.so


##- installing Python 2.4.3
BUILDDIR=/builddir
SRCDIR=/mnt/a
VERSION=2.4.3
STAR=Python-2.4.3.tar.bz2
PKG=`echo $STAR | sed -e 's@\.tar\.gz@@' -e 's@\.tgz@@'
-e 's@\.tar\.bz2@@' `

CC=cc; export CC
CXX=CC; export CXX

PATH=/opt/SUNWspro/bin:/usr/ccs/bin:/usr/bin/:/opt/db4/bin:/sbin/bin;
export PATH
LDFLAGS='-R/opt/db4/lib -L/opt/db4/lib'; export LDFLAGS
CPPFLAGS='-I/opt/db4/include'; export CPPFLAGS

cd $BUILDDIR
bunzip2 -c $SRCDIR/$STAR | /usr/sfw/bin/gtar -xvf - 

cd "$PKG"

patch -p0 < /mnt/a/python_curses_1471938.patch

./configure --prefix=/usr --without-gcc \
            | tee
/var/tmp/"${PKG}"-"$VERSION"_configure_`date
'+%Y%m%d%H%M%S'`

make | tee /var/tmp/"${PKG}"-"$VERSION"_make_`date
'+%Y%m%d%H%M%S'`
make test | tee
/var/tmp/"${PKG}"-"$VERSION"_make_test_`date
'+%Y%m%d%H%M%S'`

# done as user 'root'
cd $BUILDDIR/"$PKG"
make install | tee
/var/tmp/"${PKG}"-"$VERSION"_make_install_`date
'+%Y%m%d%H%M%S'`

All Python 2.4.3 test run OK, see 
256 tests OK.
CAUTION:  stdout isn't compared in verbose mode:
a test that passes in verbose mode may fail without it.
1 test failed:
    test_nis
34 tests skipped:
    test_aepack test_al test_applesingle test_bsddb185
test_bsddb3
    test_cd test_cl test_codecmaps_cn test_codecmaps_hk
    test_codecmaps_jp test_codecmaps_kr
test_codecmaps_tw test_curses
    test_gdbm test_gl test_imgfile test_linuxaudiodev
test_locale
    test_macfs test_macostools test_normalization
test_ossaudiodev
    test_pep277 test_plistlib test_scriptpackages
test_socket_ssl
    test_socketserver test_tcl test_timeout
test_unicode_file
    test_urllib2net test_urllibnet test_winreg
test_winsound
2 skips unexpected on sunos5:
    test_tcl test_locale


If running the tests of the software package roundup
1.1.2 if reveive a core dump from the Python interpreter.

-bash-3.00$ python ./run_tests.py
Running unit tests at level 1
Running unit tests from
/export/home/builddir/roundup-1.1.2/.
Including anydbm tests
Skipping metakit tests
Skipping mysql tests
Skipping postgresql tests
Including sqlite tests
Skipping tsearch2 tests
testDontRetireAdminOrAnonymous
(test.test_actions.RetireActionTestCase) ... ok
testNoPermission
(test.test_actions.RetireActionTestCase) ... ok
testRetireAction
(test.test_actions.RetireActionTestCase) ... ok
testNoPermission
(test.test_actions.StandardSearchActionTestCase) ... ok
testQueryName
(test.test_actions.StandardSearchActionTestCase) ... ok
testEmptyKey (test.test_actions.FakeFilterVarsTestCase)
... ok
testEmptyMultilink
(test.test_actions.FakeFilterVarsTestCase) ... ok
testNonEmptyMultilink
(test.test_actions.FakeFilterVarsTestCase) ... ok
testStandardKey
(test.test_actions.FakeFilterVarsTestCase) ... ok
testStringKey
(test.test_actions.FakeFilterVarsTestCase) ... ok
testTokenizedStringKey
(test.test_actions.FakeFilterVarsTestCase) ... ok
testShowAction (test.test_actions.ShowActionTestCase)
... ok
testShowActionNoType
(test.test_actions.ShowActionTestCase) ... ok
testCollision
(test.test_actions.CollisionDetectionTestCase) ... ok
testLastNodeActivity
(test.test_actions.CollisionDetectionTestCase) ... ok
testLastUserActivity
(test.test_actions.CollisionDetectionTestCase) ... ok
testCorrectLogin (test.test_actions.LoginTestCase) ... ok
testInvalidPassword (test.test_actions.LoginTestCase)
... ok
testInvalidUsername (test.test_actions.LoginTestCase)
... ok
testNoUsername (test.test_actions.LoginTestCase) ... ok
testNoWebAccess (test.test_actions.LoginTestCase) ... ok
testActorProperty (test.test_anydbm.anydbmDBTest) ...
Segmentation Fault (core 
dumped)

The Solaris 10 installation has been updated recently
with smpatch. 

Richard Jones suggested, that this could be a Python
build problem. Below you find the anydbm information. 

-bash-3.00$ uname -a
SunOS sunny 5.10 Generic_118855-02 i86pc i386 i86pc
-bash-3.00$ python
Python 2.4.3 (#1, May 21 2006, 02:39:16) [C] on sunos5
Type "help", "copyright", "credits" or "license" for
more information.
>>> import anydbm
>>> anydbm._defaultmod
<module 'dbhash' from '/usr/lib/python2.4/dbhash.pyc'>

All roundup tests fail with a core dump which are
excluded by the following statement.

-bash-3.00$ ./run_tests.py -vv test
'!(testActorProperty|testAddProperty|testAddRemoveProperty|testCacheCreateSet|testCreatorProperty|testDateChange|testDateUnset|testDestroyJournalling|testEmptySet|testExceptions|testFileClassContentChange|testFileClassIndexingNoNoNo|testFileClassReindexing|testFilteringDateSort|testFilteringID|testFilteringIntervalSort|testFilteringLink|testFilteringMany|testFilteringMultilink|testFilteringNumber|testFilteringRange|testFilteringRetired|testFilteringString|testForcedReindexing|testIDGeneration|testIDSetting|testImportExport|testIndexerSearching|testIntervalChange|testIntervalUnset|testJournals|testLinkChange|testLinkUnset|testMultilinkChange|testPack|testReindexingChange|testReindexingClear|testRemoveProperty|testRetire|testSerialisation|testStringChange|testStringFind|testStringUnset|testTransactions|testEmptyStringSet|testSetString|test_basics|test_change|test_clear|testAlternateAddress|testCommandDelimiters|testContentDisposition|testEmailQuoting|testEmptyMessage|testEnc01|testFollowup|testInvalidClassLoose|testInvalidCommandPassthrough|testMultipartEnc01|testNewIssue|testNewUserAuthor|testNosyRemove|testResentFrom|testSimpleFollowup|testFindLink|testFindMultiMultilink|testFindMultilink|testFindMultipleLink|testFindRetired)'
Running unit tests at level 1
Running unit tests from
/export/home/builddir/roundup-1.1.2/.
Including anydbm tests
Skipping metakit tests
Skipping mysql tests
Skipping postgresql tests
Including sqlite tests
Skipping tsearch2 tests
...
----------------------------------------------------------------------
Ran 202 tests in 76.999s

OK


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1496561&group_id=5470

From noreply at sourceforge.net  Mon May 29 15:03:55 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 29 May 2006 06:03:55 -0700
Subject: [ python-Feature Requests-1453341 ] sys.setatomicexecution - for
	critical sections
Message-ID: <E1FkhPX-0003IQ-SU@sc8-sf-web1.sourceforge.net>

Feature Requests item #1453341, was opened at 2006-03-18 20:52
Message generated for change (Comment added) made by gfe
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1453341&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: Closed
Resolution: Rejected
Priority: 5
Submitted By: kxroberto (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: sys.setatomicexecution -  for critical sections

Initial Comment:
In order to maintain threaded code uncomplicated (VHL)
and in order to avoid massive use of locks, when
introducing few critical non-atomic sections, it should
be possible to put out that practical hammer ..

    try:
        last_ci=sys.setcheckinterval(sys.maxint)
        critical_function()  # now runs atomically
    finally:
        sys.setcheckinterval(last_ci)
    #(sys.setcheckinterval assumed to return the last
value)


..by an official function/class (in sys or thread):


Maybe:
======

atomic = sys.setatomicexecution(mode)
try:
    print "Executing critical section"
finally:
    sys.setatomicexecution(atomic)

there should be different modes/levels for blocking :

* 0=None
* 1=block only python execution in other threads
* 2=block signals
* 4/5/7/15=block threads at OS level (if OS supports)
* 8=(reserved: block future sub-/stackless switching
inside current thread..)

see:
http://groups.google.de/group/comp.lang.python/browse_frm/thread/bf5461507803975e/3bd7dfa9422a1200

compare:
http://www.stackless.com/wiki/Tasklets#critical-sections

---

Also Python could define officially its time atoms
beyond CPU atoms in the docs (That also defines the VHL
usability of the language).

Thus thinks like single-element changes ...

obj.var=x  , d[key]=x , l.append(x) .pop()

should be guaranteed to work atomic/correct FOR EVER. 

l[slice],  d.keys() .items(), .. questionable? 
If not guaranteed for the future, offer duplicates for
speed critical key building blocks like: 
l.slice_atomic(slice), d.keys_atomic() ,...  in order
to make code compatible for the future. 

---

Extra fun for blowing up python libs for poeple who
don't want to learn that try..finally all the time:

copy/deepcopy/dump maybe could be enriched by
copy_atomic , deepcopy_atomic, dump_atomic - or just
RuntimeError tolerant versions,   deepcopy_save  (no
use of .iterxxx)



----------------------------------------------------------------------

Comment By: Martin Gfeller (gfe)
Date: 2006-05-29 15:03

Message:
Logged In: YES 
user_id=884167

Nick Coghlan wrote:
> Python level access to the Global Interpreter Lock is 
neither necessary nor desirable.

I agree. But what I think would be very useful (as I 
already mentioned below) is C level API access that tells 
Python not to relinquish the GIL during a callback. 

I don't know of any other way to achieve this, apart from 
introducing a separate C-level locking mechanism. 

I think Tim Peters thinks thought this is feasible when he 
wrote the following (private conversation, June 2005):

> It would be more feasible to patch Python, introducing 
> a way to tell the interpreter not to allow other 
> _Python_ threads to run. It has such a mechanism 
> already (the GIL -- the global interpreter lock), but 
> as soon as C code calls back into Python, the interpreter
> may release the GIL and give ownership of it to a 
> different thread. I think it would be pretty easy to 
> introduce a Python C API to say "don't allow other Python
> threads to run until I tell you otherwise". 

Best regards, Martin Gfeller

----------------------------------------------------------------------

Comment By: Nick Coghlan (ncoghlan)
Date: 2006-04-08 20:34

Message:
Logged In: YES 
user_id=1038590

On the other changes you suggest (which Raymond didn't bring
up on python-dev):

Python can't formally define as atomic any operations that
may execute arbitrary Python code, as the interpreter cannot
control what that code may do. All of the examples you give
are in that category.

Slowing down the common cases (unthreaded code and
Queue-based threaded code) by adding internal locking to
every data structure is also considered highly undesirable.

----------------------------------------------------------------------

Comment By: Nick Coghlan (ncoghlan)
Date: 2006-04-08 20:17

Message:
Logged In: YES 
user_id=1038590

Raymond brought this idea up on python-dev at the time of
the c.l.p discussion - it was rejected on the basis that
thread synchronisation tools (Queues and Locks) are provided
for a reason. Python level access to the Global Interpreter
Lock is neither necessary nor desirable.

Avoiding the tools provided to permit threading to work
correctly and then finding that threaded code doesn't work
as desired really shouldn't be surprising.

FWIW, Python 2.5 aims to make normal locking easier to use
by permitting:

from __future__ import with_statement
from threading import Lock

sync_lock = Lock()

def my_func(*args, **kwds):
    with sync_lock:
        # Only one thread at a time can enter this section
        # regardless of IO or anything else
    # This section, on the other hand, is a free-for-all

If you genuinely have to avoid normal thread synchronisation
primitives, you can abuse (and I really do mean abuse) the
interpreter's import lock for this purpose:

imp.acquire_lock()
try: 
    print 'critical section'
finally:
    imp.release_lock()

Or even:

@contextlib.contextmanager
def CriticalSection()
    imp.acquire_lock()
    try:
        yield
    finally:
        imp.release_lock()

with CriticalSection():
    print 'critical section'


----------------------------------------------------------------------

Comment By: kxroberto (kxroberto)
Date: 2006-03-20 16:28

Message:
Logged In: YES 
user_id=972995

... only PyEval_RestoreThread with the harder execution
level in its tstate

----------------------------------------------------------------------

Comment By: kxroberto (kxroberto)
Date: 2006-03-20 16:24

Message:
Logged In: YES 
user_id=972995

thus the GIL could simply have a harder state 2 : "locked
hard for PyEval_AcquireThread/PyEval_AcquireLock/.." ?

Only PyEval_RestoreThread gets the lock again after
PyEval_SaveThread.

Robert




----------------------------------------------------------------------

Comment By: Martin Gfeller (gfe)
Date: 2006-03-20 13:17

Message:
Logged In: YES 
user_id=884167

- sys.setcheckinterval(sys.maxint) does not prevent 
  thread switching when doing IO, does it? There is
  no way that I know of to prevent thread switching
  in this situation.

- When calling back into Python from C Code, there is
  no way to tell Python not to relinquish the GIL; such
  an option could be useful for some C code, because
  the GIL provides a "global critical section". 

Martin


----------------------------------------------------------------------

Comment By: kxroberto (kxroberto)
Date: 2006-03-18 22:54

Message:
Logged In: YES 
user_id=972995

or:

>>> atomic = sys.acquireatomicexecution(mode)
>>> try: 
... 	print 'critical section'
... finally:
... 	atomic.release()

>>> with sys.acquireatomicexecution(mode):
...     print 'critical section'



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1453341&group_id=5470

From noreply at sourceforge.net  Mon May 29 15:06:59 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 29 May 2006 06:06:59 -0700
Subject: [ python-Feature Requests-1453341 ] sys.setatomicexecution - for
	critical sections
Message-ID: <E1FkhSV-0004Sj-8X@sc8-sf-web1.sourceforge.net>

Feature Requests item #1453341, was opened at 2006-03-18 20:52
Message generated for change (Comment added) made by gfe
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1453341&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: Closed
Resolution: Rejected
Priority: 5
Submitted By: kxroberto (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: sys.setatomicexecution -  for critical sections

Initial Comment:
In order to maintain threaded code uncomplicated (VHL)
and in order to avoid massive use of locks, when
introducing few critical non-atomic sections, it should
be possible to put out that practical hammer ..

    try:
        last_ci=sys.setcheckinterval(sys.maxint)
        critical_function()  # now runs atomically
    finally:
        sys.setcheckinterval(last_ci)
    #(sys.setcheckinterval assumed to return the last
value)


..by an official function/class (in sys or thread):


Maybe:
======

atomic = sys.setatomicexecution(mode)
try:
    print "Executing critical section"
finally:
    sys.setatomicexecution(atomic)

there should be different modes/levels for blocking :

* 0=None
* 1=block only python execution in other threads
* 2=block signals
* 4/5/7/15=block threads at OS level (if OS supports)
* 8=(reserved: block future sub-/stackless switching
inside current thread..)

see:
http://groups.google.de/group/comp.lang.python/browse_frm/thread/bf5461507803975e/3bd7dfa9422a1200

compare:
http://www.stackless.com/wiki/Tasklets#critical-sections

---

Also Python could define officially its time atoms
beyond CPU atoms in the docs (That also defines the VHL
usability of the language).

Thus thinks like single-element changes ...

obj.var=x  , d[key]=x , l.append(x) .pop()

should be guaranteed to work atomic/correct FOR EVER. 

l[slice],  d.keys() .items(), .. questionable? 
If not guaranteed for the future, offer duplicates for
speed critical key building blocks like: 
l.slice_atomic(slice), d.keys_atomic() ,...  in order
to make code compatible for the future. 

---

Extra fun for blowing up python libs for poeple who
don't want to learn that try..finally all the time:

copy/deepcopy/dump maybe could be enriched by
copy_atomic , deepcopy_atomic, dump_atomic - or just
RuntimeError tolerant versions,   deepcopy_save  (no
use of .iterxxx)



----------------------------------------------------------------------

Comment By: Martin Gfeller (gfe)
Date: 2006-05-29 15:06

Message:
Logged In: YES 
user_id=884167

Should I enter a separate feature request for this, 
separating it from this closed item?

Martin

----------------------------------------------------------------------

Comment By: Martin Gfeller (gfe)
Date: 2006-05-29 15:03

Message:
Logged In: YES 
user_id=884167

Nick Coghlan wrote:
> Python level access to the Global Interpreter Lock is 
neither necessary nor desirable.

I agree. But what I think would be very useful (as I 
already mentioned below) is C level API access that tells 
Python not to relinquish the GIL during a callback. 

I don't know of any other way to achieve this, apart from 
introducing a separate C-level locking mechanism. 

I think Tim Peters thinks thought this is feasible when he 
wrote the following (private conversation, June 2005):

> It would be more feasible to patch Python, introducing 
> a way to tell the interpreter not to allow other 
> _Python_ threads to run. It has such a mechanism 
> already (the GIL -- the global interpreter lock), but 
> as soon as C code calls back into Python, the interpreter
> may release the GIL and give ownership of it to a 
> different thread. I think it would be pretty easy to 
> introduce a Python C API to say "don't allow other Python
> threads to run until I tell you otherwise". 

Best regards, Martin Gfeller

----------------------------------------------------------------------

Comment By: Nick Coghlan (ncoghlan)
Date: 2006-04-08 20:34

Message:
Logged In: YES 
user_id=1038590

On the other changes you suggest (which Raymond didn't bring
up on python-dev):

Python can't formally define as atomic any operations that
may execute arbitrary Python code, as the interpreter cannot
control what that code may do. All of the examples you give
are in that category.

Slowing down the common cases (unthreaded code and
Queue-based threaded code) by adding internal locking to
every data structure is also considered highly undesirable.

----------------------------------------------------------------------

Comment By: Nick Coghlan (ncoghlan)
Date: 2006-04-08 20:17

Message:
Logged In: YES 
user_id=1038590

Raymond brought this idea up on python-dev at the time of
the c.l.p discussion - it was rejected on the basis that
thread synchronisation tools (Queues and Locks) are provided
for a reason. Python level access to the Global Interpreter
Lock is neither necessary nor desirable.

Avoiding the tools provided to permit threading to work
correctly and then finding that threaded code doesn't work
as desired really shouldn't be surprising.

FWIW, Python 2.5 aims to make normal locking easier to use
by permitting:

from __future__ import with_statement
from threading import Lock

sync_lock = Lock()

def my_func(*args, **kwds):
    with sync_lock:
        # Only one thread at a time can enter this section
        # regardless of IO or anything else
    # This section, on the other hand, is a free-for-all

If you genuinely have to avoid normal thread synchronisation
primitives, you can abuse (and I really do mean abuse) the
interpreter's import lock for this purpose:

imp.acquire_lock()
try: 
    print 'critical section'
finally:
    imp.release_lock()

Or even:

@contextlib.contextmanager
def CriticalSection()
    imp.acquire_lock()
    try:
        yield
    finally:
        imp.release_lock()

with CriticalSection():
    print 'critical section'


----------------------------------------------------------------------

Comment By: kxroberto (kxroberto)
Date: 2006-03-20 16:28

Message:
Logged In: YES 
user_id=972995

... only PyEval_RestoreThread with the harder execution
level in its tstate

----------------------------------------------------------------------

Comment By: kxroberto (kxroberto)
Date: 2006-03-20 16:24

Message:
Logged In: YES 
user_id=972995

thus the GIL could simply have a harder state 2 : "locked
hard for PyEval_AcquireThread/PyEval_AcquireLock/.." ?

Only PyEval_RestoreThread gets the lock again after
PyEval_SaveThread.

Robert




----------------------------------------------------------------------

Comment By: Martin Gfeller (gfe)
Date: 2006-03-20 13:17

Message:
Logged In: YES 
user_id=884167

- sys.setcheckinterval(sys.maxint) does not prevent 
  thread switching when doing IO, does it? There is
  no way that I know of to prevent thread switching
  in this situation.

- When calling back into Python from C Code, there is
  no way to tell Python not to relinquish the GIL; such
  an option could be useful for some C code, because
  the GIL provides a "global critical section". 

Martin


----------------------------------------------------------------------

Comment By: kxroberto (kxroberto)
Date: 2006-03-18 22:54

Message:
Logged In: YES 
user_id=972995

or:

>>> atomic = sys.acquireatomicexecution(mode)
>>> try: 
... 	print 'critical section'
... finally:
... 	atomic.release()

>>> with sys.acquireatomicexecution(mode):
...     print 'critical section'



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1453341&group_id=5470

From noreply at sourceforge.net  Mon May 29 15:57:12 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 29 May 2006 06:57:12 -0700
Subject: [ python-Bugs-1494314 ] Cannot use high-numbered sockets in 2.4.3
Message-ID: <E1FkiF6-0001qO-UR@sc8-sf-web2.sourceforge.net>

Bugs item #1494314, was opened at 2006-05-24 15:51
Message generated for change (Comment added) made by gabrielwicke
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1494314&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: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Smith (mlrsmith)
Assigned to: Nobody/Anonymous (nobody)
Summary: Cannot use high-numbered sockets in 2.4.3

Initial Comment:
Python 2.4.3 introduced (in Modules/socketmodule.c) the
IS_SELECTABLE() macro, to check whether calling
select() on a given file descriptor is permissible.

However, it executes this check even when it won't
actually call select(). Specifically, select() is
called ONLY when s->sock_timeout > 0 (in
internal_select mostly, but also internal_connect).

I have a twisted application which uses many FDs
(several thousand), and upgrading python to 2.4.3 makes
it hit this limit (at 1024 file descriptors),
regardless of ulimit settings. Twisted itself always
uses non-blocking I/O on sockets, so with older
versions of python this worked fine.

A simple solution relies on the fact that select is
only ever actually called, and changes the
IS_SELECTABLE macro as in the attached fairly trivial
patch. This is sufficient to restore my application to
its previous state (where it works fine).

This doesn't solve the more general problem in
socketmodule - that we simply can't do all operations
properly with the current reliance on select(), though,
and it seems like a bit of a hack...  If I wrote up a
patch to use poll() on systems where it's available,
throughout socketmodule.c, in preference to select(),
would this be accepted?

Mike



----------------------------------------------------------------------

Comment By: Gabriel Wicke (gabrielwicke)
Date: 2006-05-29 15:57

Message:
Logged In: YES 
user_id=956757

Try "ulimit -n 8096" (only permitted in a root shell) to set
your max socket usage to something larger. Opening more than
1024 sockets works for me in python 2.4.3 after changing the
limit for the terminal in question and restarting the
interpreter. Just ulimit -n will show you your current
limit. Ulimits are enforced by the Linux kernel and can
likely be configured system-wide in /etc/sysctl.cfg.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1494314&group_id=5470

From noreply at sourceforge.net  Mon May 29 16:00:11 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 29 May 2006 07:00:11 -0700
Subject: [ python-Bugs-1494314 ] Cannot use high-numbered sockets in 2.4.3
Message-ID: <E1FkiHz-0002qT-5I@sc8-sf-web2.sourceforge.net>

Bugs item #1494314, was opened at 2006-05-24 15:51
Message generated for change (Comment added) made by gabrielwicke
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1494314&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: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Smith (mlrsmith)
Assigned to: Nobody/Anonymous (nobody)
Summary: Cannot use high-numbered sockets in 2.4.3

Initial Comment:
Python 2.4.3 introduced (in Modules/socketmodule.c) the
IS_SELECTABLE() macro, to check whether calling
select() on a given file descriptor is permissible.

However, it executes this check even when it won't
actually call select(). Specifically, select() is
called ONLY when s->sock_timeout > 0 (in
internal_select mostly, but also internal_connect).

I have a twisted application which uses many FDs
(several thousand), and upgrading python to 2.4.3 makes
it hit this limit (at 1024 file descriptors),
regardless of ulimit settings. Twisted itself always
uses non-blocking I/O on sockets, so with older
versions of python this worked fine.

A simple solution relies on the fact that select is
only ever actually called, and changes the
IS_SELECTABLE macro as in the attached fairly trivial
patch. This is sufficient to restore my application to
its previous state (where it works fine).

This doesn't solve the more general problem in
socketmodule - that we simply can't do all operations
properly with the current reliance on select(), though,
and it seems like a bit of a hack...  If I wrote up a
patch to use poll() on systems where it's available,
throughout socketmodule.c, in preference to select(),
would this be accepted?

Mike



----------------------------------------------------------------------

Comment By: Gabriel Wicke (gabrielwicke)
Date: 2006-05-29 16:00

Message:
Logged In: YES 
user_id=956757

Never mind- you already tried ulimit. It still works for me
though, 2.4.3 from Ubuntu Dapper.

----------------------------------------------------------------------

Comment By: Gabriel Wicke (gabrielwicke)
Date: 2006-05-29 15:57

Message:
Logged In: YES 
user_id=956757

Try "ulimit -n 8096" (only permitted in a root shell) to set
your max socket usage to something larger. Opening more than
1024 sockets works for me in python 2.4.3 after changing the
limit for the terminal in question and restarting the
interpreter. Just ulimit -n will show you your current
limit. Ulimits are enforced by the Linux kernel and can
likely be configured system-wide in /etc/sysctl.cfg.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1494314&group_id=5470

From noreply at sourceforge.net  Mon May 29 16:11:59 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 29 May 2006 07:11:59 -0700
Subject: [ python-Bugs-1494314 ] Cannot use high-numbered sockets in 2.4.3
Message-ID: <E1FkiTP-0005o9-SA@sc8-sf-web3.sourceforge.net>

Bugs item #1494314, was opened at 2006-05-24 15:51
Message generated for change (Comment added) made by gabrielwicke
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1494314&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: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Smith (mlrsmith)
Assigned to: Nobody/Anonymous (nobody)
Summary: Cannot use high-numbered sockets in 2.4.3

Initial Comment:
Python 2.4.3 introduced (in Modules/socketmodule.c) the
IS_SELECTABLE() macro, to check whether calling
select() on a given file descriptor is permissible.

However, it executes this check even when it won't
actually call select(). Specifically, select() is
called ONLY when s->sock_timeout > 0 (in
internal_select mostly, but also internal_connect).

I have a twisted application which uses many FDs
(several thousand), and upgrading python to 2.4.3 makes
it hit this limit (at 1024 file descriptors),
regardless of ulimit settings. Twisted itself always
uses non-blocking I/O on sockets, so with older
versions of python this worked fine.

A simple solution relies on the fact that select is
only ever actually called, and changes the
IS_SELECTABLE macro as in the attached fairly trivial
patch. This is sufficient to restore my application to
its previous state (where it works fine).

This doesn't solve the more general problem in
socketmodule - that we simply can't do all operations
properly with the current reliance on select(), though,
and it seems like a bit of a hack...  If I wrote up a
patch to use poll() on systems where it's available,
throughout socketmodule.c, in preference to select(),
would this be accepted?

Mike



----------------------------------------------------------------------

Comment By: Gabriel Wicke (gabrielwicke)
Date: 2006-05-29 16:11

Message:
Logged In: YES 
user_id=956757

Please disregard my comments completely- just opening more
than 1024 files does not trigger this bug, but doing a
socket.send() on the 1025th socket does.

----------------------------------------------------------------------

Comment By: Gabriel Wicke (gabrielwicke)
Date: 2006-05-29 16:00

Message:
Logged In: YES 
user_id=956757

Never mind- you already tried ulimit. It still works for me
though, 2.4.3 from Ubuntu Dapper.

----------------------------------------------------------------------

Comment By: Gabriel Wicke (gabrielwicke)
Date: 2006-05-29 15:57

Message:
Logged In: YES 
user_id=956757

Try "ulimit -n 8096" (only permitted in a root shell) to set
your max socket usage to something larger. Opening more than
1024 sockets works for me in python 2.4.3 after changing the
limit for the terminal in question and restarting the
interpreter. Just ulimit -n will show you your current
limit. Ulimits are enforced by the Linux kernel and can
likely be configured system-wide in /etc/sysctl.cfg.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1494314&group_id=5470

From noreply at sourceforge.net  Mon May 29 16:13:33 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 29 May 2006 07:13:33 -0700
Subject: [ python-Bugs-1494605 ] unchecked PyObject_SetAttrString() in
	PyErr_SyntaxLocation()
Message-ID: <E1FkiUv-0001EI-M8@sc8-sf-web1.sourceforge.net>

Bugs item #1494605, was opened at 2006-05-24 21:25
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1494605&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: Brett Cannon (bcannon)
Assigned to: Nobody/Anonymous (nobody)
Summary: unchecked PyObject_SetAttrString() in PyErr_SyntaxLocation()

Initial Comment:
Line 733 of Python/errors.c has a
PyObject_SetAttrString() call where Py_Clear() is not
called if it failed.

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-05-29 14:13

Message:
Logged In: YES 
user_id=849994

Fixed in rev. 46523.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1494605&group_id=5470

From noreply at sourceforge.net  Mon May 29 16:13:45 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 29 May 2006 07:13:45 -0700
Subject: [ python-Bugs-1494314 ] Cannot use high-numbered sockets in 2.4.3
Message-ID: <E1FkiV7-0007qV-6g@sc8-sf-web4-b.sourceforge.net>

Bugs item #1494314, was opened at 2006-05-24 15:51
Message generated for change (Comment added) made by mlrsmith
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1494314&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: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Smith (mlrsmith)
Assigned to: Nobody/Anonymous (nobody)
Summary: Cannot use high-numbered sockets in 2.4.3

Initial Comment:
Python 2.4.3 introduced (in Modules/socketmodule.c) the
IS_SELECTABLE() macro, to check whether calling
select() on a given file descriptor is permissible.

However, it executes this check even when it won't
actually call select(). Specifically, select() is
called ONLY when s->sock_timeout > 0 (in
internal_select mostly, but also internal_connect).

I have a twisted application which uses many FDs
(several thousand), and upgrading python to 2.4.3 makes
it hit this limit (at 1024 file descriptors),
regardless of ulimit settings. Twisted itself always
uses non-blocking I/O on sockets, so with older
versions of python this worked fine.

A simple solution relies on the fact that select is
only ever actually called, and changes the
IS_SELECTABLE macro as in the attached fairly trivial
patch. This is sufficient to restore my application to
its previous state (where it works fine).

This doesn't solve the more general problem in
socketmodule - that we simply can't do all operations
properly with the current reliance on select(), though,
and it seems like a bit of a hack...  If I wrote up a
patch to use poll() on systems where it's available,
throughout socketmodule.c, in preference to select(),
would this be accepted?

Mike



----------------------------------------------------------------------

>Comment By: Michael Smith (mlrsmith)
Date: 2006-05-29 16:13

Message:
Logged In: YES 
user_id=1488997

Yes, I had my ulimit set appropriately.

There's no problem with _opening_ many sockets (at least, I
don't think there is) - the problem is with trying to do
something (like call socket.recv()) with them.

The code in socketmodule.c is pretty clear - and having
upgraded to 2.4.3 with ubuntu dapper, I _am_ running into this.

For now, we're having to keep all our production machines on
2.4.2.


----------------------------------------------------------------------

Comment By: Gabriel Wicke (gabrielwicke)
Date: 2006-05-29 16:11

Message:
Logged In: YES 
user_id=956757

Please disregard my comments completely- just opening more
than 1024 files does not trigger this bug, but doing a
socket.send() on the 1025th socket does.

----------------------------------------------------------------------

Comment By: Gabriel Wicke (gabrielwicke)
Date: 2006-05-29 16:00

Message:
Logged In: YES 
user_id=956757

Never mind- you already tried ulimit. It still works for me
though, 2.4.3 from Ubuntu Dapper.

----------------------------------------------------------------------

Comment By: Gabriel Wicke (gabrielwicke)
Date: 2006-05-29 15:57

Message:
Logged In: YES 
user_id=956757

Try "ulimit -n 8096" (only permitted in a root shell) to set
your max socket usage to something larger. Opening more than
1024 sockets works for me in python 2.4.3 after changing the
limit for the terminal in question and restarting the
interpreter. Just ulimit -n will show you your current
limit. Ulimits are enforced by the Linux kernel and can
likely be configured system-wide in /etc/sysctl.cfg.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1494314&group_id=5470

From noreply at sourceforge.net  Mon May 29 16:28:20 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 29 May 2006 07:28:20 -0700
Subject: [ python-Bugs-1494671 ] PyOS_ascii_strtod() uses malloc() directly
Message-ID: <E1FkijE-0006Nh-FZ@sc8-sf-web1.sourceforge.net>

Bugs item #1494671, was opened at 2006-05-25 00:51
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1494671&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: Brett Cannon (bcannon)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyOS_ascii_strtod() uses malloc() directly

Initial Comment:
Line 103 shows a use of a bare malloc() instead of the
proper memory-related macro.

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-05-29 14:28

Message:
Logged In: YES 
user_id=849994

Added a NULL handler in rev. 46524.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-05-25 21:45

Message:
Logged In: YES 
user_id=849994

Reopening as there is no check for the return value of
malloc, as Tim noticed on python-cvs.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2006-05-25 20:45

Message:
Logged In: YES 
user_id=357491

Changed in rev. 46253 to use PyMem_MALLOC/PyMem_FREE .

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2006-05-25 20:24

Message:
Logged In: YES 
user_id=357491

OK.  Well, considered it is free within the function and all
memory use is done through C API functions (memcpy() and
strtod() specifically, I don't see any reason not to move
over to PyMem_Malloc() since I can do that quickly.

Oh, and the file is Python/pystrtod.c and it's line 104 for
those who don't know where the function is.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-05-25 01:18

Message:
Logged In: YES 
user_id=31435

Well, it's not really a bug.  If a module wants to use
malloc/free internally, that's fine.  I can't think of a
reason for _why_ this code wants to do that, but it doesn't
really hurt.

Somtimes there is a good reason.  For example, the code
providing a portable notion of thread-local storage in
thread.c uses malloc deliberately, because those functions
can be called when the GIL isn't held (i.e., multiple
threads can call them simultaneously).  The Python memory
families, like almost all parts of the Python C API, are
free to assume that the GIL is held; in particular, obmalloc
does assume that, so it would be disastrous if thread.c used
that memory family instead.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1494671&group_id=5470

From noreply at sourceforge.net  Mon May 29 16:39:11 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 29 May 2006 07:39:11 -0700
Subject: [ python-Bugs-1494787 ] pyclbr add whitespace chars to base class name
Message-ID: <E1Fkitj-0007YR-Ev@sc8-sf-web4-b.sourceforge.net>

Bugs item #1494787, was opened at 2006-05-25 08:32
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1494787&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Dmitry Vasiliev (hdima)
Assigned to: Nobody/Anonymous (nobody)
Summary: pyclbr add whitespace chars to base class name

Initial Comment:
While parsing base class names for a class pyclbr eats
also tokens with whitespace characters. The attached
patch adds check for token type.

Maybe we even should form base class names only from
name and dot tokens?

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-05-29 14:39

Message:
Logged In: YES 
user_id=849994

Thanks for the report, fixed in rev. 46526.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1494787&group_id=5470

From noreply at sourceforge.net  Mon May 29 16:45:57 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 29 May 2006 07:45:57 -0700
Subject: [ python-Bugs-1487420 ] can't pickle slice objects
Message-ID: <E1Fkj0H-0001I3-KQ@sc8-sf-web4-b.sourceforge.net>

Bugs item #1487420, was opened at 2006-05-12 13:58
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1487420&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: Duplicate
Priority: 5
Submitted By: ganges master (gangesmaster)
Assigned to: Nobody/Anonymous (nobody)
Summary: can't pickle slice objects

Initial Comment:
for some reason, slices are not-picklable.
i guess someone just forgot to add support 
for those

>>> import pickle
>>> pickle.dumps(slice(1,2,3))
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "D:\Python24\Lib\pickle.py", line 1386, in dumps
    Pickler(file, protocol, bin).dump(obj)
  File "D:\Python24\Lib\pickle.py", line 231, in dump
    self.save(obj)
  File "D:\Python24\Lib\pickle.py", line 313, in save
    rv = reduce(self.proto)
  File "D:\Python24\Lib\copy_reg.py", line 69, in
_reduce_ex
    raise TypeError, "can't pickle %s objects" %
base.__name__
TypeError: can't pickle slice objects
>>>

-tomer

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-05-29 14:45

Message:
Logged In: YES 
user_id=849994

Duplicate of #1191699.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1487420&group_id=5470

From noreply at sourceforge.net  Mon May 29 16:46:50 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 29 May 2006 07:46:50 -0700
Subject: [ python-Bugs-1495175 ] OverflowWarning still in 2.5 despite docstring
Message-ID: <E1Fkj18-0001af-MF@sc8-sf-web4-b.sourceforge.net>

Bugs item #1495175, was opened at 2006-05-25 21:03
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1495175&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: Extension Modules
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Jim Jewett (jimjjewett)
Assigned to: Nobody/Anonymous (nobody)
Summary: OverflowWarning still in 2.5 despite docstring

Initial Comment:
>>> OverflowWarning.__doc__
"Base class for warnings about numeric overflow.  Won'
t exist in Python 2.5."

>>> sys.version
'2.5a2 (r25a2:45740, Apr 27 2006, 06:31:19) [MSC v.
1310 32 bit (Intel)]'



----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-05-29 14:46

Message:
Logged In: YES 
user_id=849994

OverflowWarning has vanished in the exception types rewrite.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1495175&group_id=5470

From noreply at sourceforge.net  Mon May 29 16:48:50 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 29 May 2006 07:48:50 -0700
Subject: [ python-Bugs-1496278 ] Incorrect error message related to **kwargs
Message-ID: <E1Fkj34-0002Dl-0P@sc8-sf-web4-b.sourceforge.net>

Bugs item #1496278, was opened at 2006-05-28 06:36
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1496278&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: Duplicate
Priority: 5
Submitted By: Collin Winter (collinwinter)
Assigned to: Nobody/Anonymous (nobody)
Summary: Incorrect error message related to **kwargs

Initial Comment:
"""
>>> def foo(**kwargs):
...     pass
...
>>> foo(5, 6)
TypeError: foo() takes exactly 0 arguments (2 given)
"""

It clearly does take arguments, just not positional
arguments.

The attached patch changes the message above to "foo()
takes exactly 0 non-keyword arguments", as well as
changing the message in several other, similar cases.

The patch also updates Lib/test/output/test_extcall
appropriately.

The patch is against r46495.

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-05-29 14:48

Message:
Logged In: YES 
user_id=849994

This is the same problem described in #1283289.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1496278&group_id=5470

From noreply at sourceforge.net  Mon May 29 18:55:55 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 29 May 2006 09:55:55 -0700
Subject: [ python-Bugs-1275608 ] dict key comparison swallows exceptions
Message-ID: <E1Fkl23-00054c-Ct@sc8-sf-web4-b.sourceforge.net>

Bugs item #1275608, was opened at 2005-08-29 10:30
Message generated for change (Comment added) made by arigo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1275608&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: Armin Rigo (arigo)
Assigned to: Michael Hudson (mwh)
Summary: dict key comparison swallows exceptions

Initial Comment:
This is an old one that has just biten again and cost a
lot of debugging time again: the dict lookup function
swallows all errors during key comparison.  This is bad
in itself, but if the current stack depth is just wrong
then *any* comparison will raise a RuntimeError and
lookup will pretend that the dictionary is essentially
empty.  The attached sample program shows this and
crashes with a KeyError instead of a RuntimeError.

While at the C level there is a basic compatibility
problem involved (PyDict_GetItem() not allowed to raise
any exception -- see
http://thread.gmane.org/gmane.comp.python.devel/62427),
I think it should be possible to improve the situation
on the Python interface.  Unless someone points me to
something I missed, I plan to come up with a patch that
changes the internal dict functions (including
lookdict()) to let exceptions pass through, and have
the exceptions swallowed only by the PyDict_*() API
functions that require it.

The possible (remote) incompatibility here is existing
code relying on the exceptions being swallowed --
either Python code, or C code using PyObject_GetItem()
or PyMapping_GetItemString().  Such code deserves to be
shot down in my opinion.

Assigned to mwh for his feedback (not because I want
him to write the patch!).

----------------------------------------------------------------------

>Comment By: Armin Rigo (arigo)
Date: 2006-05-29 16:55

Message:
Logged In: YES 
user_id=4771

Proposed patch #1497053.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1275608&group_id=5470

From noreply at sourceforge.net  Mon May 29 22:59:19 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 29 May 2006 13:59:19 -0700
Subject: [ python-Bugs-1495754 ] os.listdir(): inconsistent behavior with
	trailing spaces
Message-ID: <E1Fkopb-0001mv-GD@sc8-sf-web1.sourceforge.net>

Bugs item #1495754, was opened at 2006-05-26 21:28
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1495754&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: Windows
Group: Python 2.4
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Kenneth J. Pronovici (pronovic)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.listdir(): inconsistent behavior with trailing spaces

Initial Comment:
I've noticed some inconsistent behavior around 
os.listdir() and paths that contain trailing spaces on 
the Windows platform.

Take this example code:

   import os
   import tempfile
   tmpdir = tempfile.mkdtemp()
   newdir = os.path.join(tmpdir, " collect dir ")
   os.mkdir(newdir)
   print os.path.exists(newdir)
   print os.listdir(newdir)

If I run this code on Windows 2000 Pro using Python 
2.4.2, I get this:

True
[Errno 3] The system cannot find the path 
specified: 'c:\\docume~1\\a0clu0~1.bcb\\locals~1
\\temp\\tmpfd7j3t\\ collect dir /*.*'

It seems to me that if os.path.exists() tells me that 
a file or directory exists, that os.listdir() should 
be able to operate on it.

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-05-29 20:59

Message:
Logged In: YES 
user_id=849994

Since Python only calls the underlying Win32 function
FindFirstFile, I think there can nothing be done since that
function seems to be buggy in this respect.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1495754&group_id=5470

From noreply at sourceforge.net  Mon May 29 23:00:29 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 29 May 2006 14:00:29 -0700
Subject: [ python-Bugs-1489051 ] keyword and topic help broken in Pythonwin IDE
Message-ID: <E1Fkoqj-0002G6-UM@sc8-sf-web1.sourceforge.net>

Bugs item #1489051, was opened at 2006-05-15 18:46
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1489051&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: Wont Fix
Priority: 5
Submitted By: BartlebyScrivener (bscrivener)
Assigned to: Nobody/Anonymous (nobody)
Summary: keyword and topic help broken in Pythonwin IDE

Initial Comment:
Using ActivePython 2.4.3 on Windows XP

While in the Pythonwin IDE, if I seek keyword help by
issuing the following command:

>>>help ('while')

I get:

Sorry, topic and keyword documentation is not available
because the Python HTML documentation files could not
be found.  If you have installed them, please set the
environment variable PYTHONDOCS to
indicate their location.

My PYTHONDOCS variable is set to:

c:\python24\Doc\Python-Docs-2.4.2\ref

which appears to be correct (ie the help html files are
installed
there).

Searching this group, I found someone else complaining
about the same behavior with no clear resolution.

http://tinyurl.com/pblev

See also

http://tinyurl.com/mbokp

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-05-29 21:00

Message:
Logged In: YES 
user_id=849994

Closing as 3rd party.

----------------------------------------------------------------------

Comment By: BartlebyScrivener (bscrivener)
Date: 2006-05-21 00:51

Message:
Logged In: YES 
user_id=1523094

help('topic') or help('keyword') doesn't work in IDLE or
Pythonwin IDE



----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-05-20 07:00

Message:
Logged In: YES 
user_id=341410

Since you are using the Pythonwin IDE, which was written and
is supported by Mark Hammond via the pywin32 project,
perhaps you should be visiting his project page instead:
http://sf.net/projects/pywin32

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1489051&group_id=5470

From noreply at sourceforge.net  Tue May 30 00:19:44 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 29 May 2006 15:19:44 -0700
Subject: [ python-Bugs-1489051 ] keyword and topic help broken in Pythonwin IDE
Message-ID: <E1Fkq5Q-000059-0c@sc8-sf-web5.sourceforge.net>

Bugs item #1489051, was opened at 2006-05-15 18:46
Message generated for change (Comment added) made by bscrivener
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1489051&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: Wont Fix
Priority: 5
Submitted By: BartlebyScrivener (bscrivener)
Assigned to: Nobody/Anonymous (nobody)
Summary: keyword and topic help broken in Pythonwin IDE

Initial Comment:
Using ActivePython 2.4.3 on Windows XP

While in the Pythonwin IDE, if I seek keyword help by
issuing the following command:

>>>help ('while')

I get:

Sorry, topic and keyword documentation is not available
because the Python HTML documentation files could not
be found.  If you have installed them, please set the
environment variable PYTHONDOCS to
indicate their location.

My PYTHONDOCS variable is set to:

c:\python24\Doc\Python-Docs-2.4.2\ref

which appears to be correct (ie the help html files are
installed
there).

Searching this group, I found someone else complaining
about the same behavior with no clear resolution.

http://tinyurl.com/pblev

See also

http://tinyurl.com/mbokp

----------------------------------------------------------------------

>Comment By: BartlebyScrivener (bscrivener)
Date: 2006-05-29 22:19

Message:
Logged In: YES 
user_id=1523094

Sorry, if I was unclear. IDLE is not third party, is it?

So I'm saying that on Windows XP, using the install from
Python.org help() is BROKEN. Search in the Python Google
group and you'll find many other references to same. Pydoc
no longer  provides help on topic or keywords. It will do
modules. In short it's PYDOC that is broken, not Pythonwin IDE.

Thanks,

rick

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-05-29 21:00

Message:
Logged In: YES 
user_id=849994

Closing as 3rd party.

----------------------------------------------------------------------

Comment By: BartlebyScrivener (bscrivener)
Date: 2006-05-21 00:51

Message:
Logged In: YES 
user_id=1523094

help('topic') or help('keyword') doesn't work in IDLE or
Pythonwin IDE



----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-05-20 07:00

Message:
Logged In: YES 
user_id=341410

Since you are using the Pythonwin IDE, which was written and
is supported by Mark Hammond via the pywin32 project,
perhaps you should be visiting his project page instead:
http://sf.net/projects/pywin32

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1489051&group_id=5470

From noreply at sourceforge.net  Tue May 30 00:24:20 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 29 May 2006 15:24:20 -0700
Subject: [ python-Bugs-1489051 ] keyword and topic help broken in Pythonwin IDE
Message-ID: <E1Fkq9s-0004Zw-KK@sc8-sf-web1.sourceforge.net>

Bugs item #1489051, was opened at 2006-05-15 18:46
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1489051&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: Windows
Group: 3rd Party
>Status: Open
>Resolution: None
Priority: 5
Submitted By: BartlebyScrivener (bscrivener)
>Assigned to: Martin v. L??wis (loewis)
Summary: keyword and topic help broken in Pythonwin IDE

Initial Comment:
Using ActivePython 2.4.3 on Windows XP

While in the Pythonwin IDE, if I seek keyword help by
issuing the following command:

>>>help ('while')

I get:

Sorry, topic and keyword documentation is not available
because the Python HTML documentation files could not
be found.  If you have installed them, please set the
environment variable PYTHONDOCS to
indicate their location.

My PYTHONDOCS variable is set to:

c:\python24\Doc\Python-Docs-2.4.2\ref

which appears to be correct (ie the help html files are
installed
there).

Searching this group, I found someone else complaining
about the same behavior with no clear resolution.

http://tinyurl.com/pblev

See also

http://tinyurl.com/mbokp

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-05-29 22:24

Message:
Logged In: YES 
user_id=849994

Okay, reopening.

----------------------------------------------------------------------

Comment By: BartlebyScrivener (bscrivener)
Date: 2006-05-29 22:19

Message:
Logged In: YES 
user_id=1523094

Sorry, if I was unclear. IDLE is not third party, is it?

So I'm saying that on Windows XP, using the install from
Python.org help() is BROKEN. Search in the Python Google
group and you'll find many other references to same. Pydoc
no longer  provides help on topic or keywords. It will do
modules. In short it's PYDOC that is broken, not Pythonwin IDE.

Thanks,

rick

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-05-29 21:00

Message:
Logged In: YES 
user_id=849994

Closing as 3rd party.

----------------------------------------------------------------------

Comment By: BartlebyScrivener (bscrivener)
Date: 2006-05-21 00:51

Message:
Logged In: YES 
user_id=1523094

help('topic') or help('keyword') doesn't work in IDLE or
Pythonwin IDE



----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-05-20 07:00

Message:
Logged In: YES 
user_id=341410

Since you are using the Pythonwin IDE, which was written and
is supported by Mark Hammond via the pywin32 project,
perhaps you should be visiting his project page instead:
http://sf.net/projects/pywin32

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1489051&group_id=5470

From noreply at sourceforge.net  Tue May 30 00:30:07 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 29 May 2006 15:30:07 -0700
Subject: [ python-Bugs-1489051 ] keyword and topic help broken in Pythonwin IDE
Message-ID: <E1FkqFT-0001hC-0T@sc8-sf-web2.sourceforge.net>

Bugs item #1489051, was opened at 2006-05-15 11:46
Message generated for change (Comment added) made by josiahcarlson
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1489051&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: Windows
Group: 3rd Party
Status: Open
Resolution: None
Priority: 5
Submitted By: BartlebyScrivener (bscrivener)
Assigned to: Martin v. L??wis (loewis)
Summary: keyword and topic help broken in Pythonwin IDE

Initial Comment:
Using ActivePython 2.4.3 on Windows XP

While in the Pythonwin IDE, if I seek keyword help by
issuing the following command:

>>>help ('while')

I get:

Sorry, topic and keyword documentation is not available
because the Python HTML documentation files could not
be found.  If you have installed them, please set the
environment variable PYTHONDOCS to
indicate their location.

My PYTHONDOCS variable is set to:

c:\python24\Doc\Python-Docs-2.4.2\ref

which appears to be correct (ie the help html files are
installed
there).

Searching this group, I found someone else complaining
about the same behavior with no clear resolution.

http://tinyurl.com/pblev

See also

http://tinyurl.com/mbokp

----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-05-29 15:30

Message:
Logged In: YES 
user_id=341410

>From what I understand, HTML help hasn't shipped with Python
on Windows for a few releases (likely around the time that
.chm help files started shipping).

If you've got html help files installed, and it's still not
picking them up, could you dig deeper into why this is the case.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-05-29 15:24

Message:
Logged In: YES 
user_id=849994

Okay, reopening.

----------------------------------------------------------------------

Comment By: BartlebyScrivener (bscrivener)
Date: 2006-05-29 15:19

Message:
Logged In: YES 
user_id=1523094

Sorry, if I was unclear. IDLE is not third party, is it?

So I'm saying that on Windows XP, using the install from
Python.org help() is BROKEN. Search in the Python Google
group and you'll find many other references to same. Pydoc
no longer  provides help on topic or keywords. It will do
modules. In short it's PYDOC that is broken, not Pythonwin IDE.

Thanks,

rick

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-05-29 14:00

Message:
Logged In: YES 
user_id=849994

Closing as 3rd party.

----------------------------------------------------------------------

Comment By: BartlebyScrivener (bscrivener)
Date: 2006-05-20 17:51

Message:
Logged In: YES 
user_id=1523094

help('topic') or help('keyword') doesn't work in IDLE or
Pythonwin IDE



----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-05-20 00:00

Message:
Logged In: YES 
user_id=341410

Since you are using the Pythonwin IDE, which was written and
is supported by Mark Hammond via the pywin32 project,
perhaps you should be visiting his project page instead:
http://sf.net/projects/pywin32

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1489051&group_id=5470

From noreply at sourceforge.net  Tue May 30 02:42:11 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 29 May 2006 17:42:11 -0700
Subject: [ python-Bugs-1489051 ] keyword and topic help broken in Pythonwin IDE
Message-ID: <E1FksJG-00060N-UI@sc8-sf-web3.sourceforge.net>

Bugs item #1489051, was opened at 2006-05-15 20:46
Message generated for change (Comment added) made by zseil
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1489051&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: Windows
Group: 3rd Party
Status: Open
Resolution: None
Priority: 5
Submitted By: BartlebyScrivener (bscrivener)
Assigned to: Martin v. L??wis (loewis)
Summary: keyword and topic help broken in Pythonwin IDE

Initial Comment:
Using ActivePython 2.4.3 on Windows XP

While in the Pythonwin IDE, if I seek keyword help by
issuing the following command:

>>>help ('while')

I get:

Sorry, topic and keyword documentation is not available
because the Python HTML documentation files could not
be found.  If you have installed them, please set the
environment variable PYTHONDOCS to
indicate their location.

My PYTHONDOCS variable is set to:

c:\python24\Doc\Python-Docs-2.4.2\ref

which appears to be correct (ie the help html files are
installed
there).

Searching this group, I found someone else complaining
about the same behavior with no clear resolution.

http://tinyurl.com/pblev

See also

http://tinyurl.com/mbokp

----------------------------------------------------------------------

Comment By: ?iga Seilnacht (zseil)
Date: 2006-05-30 02:42

Message:
Logged In: YES 
user_id=1326842

The problem is on your side.
You should set the PYTHONDOCS environment variable
to the root directory of the html documentation, eg.:

PYTHONDOCS=c:\python24\Doc\Python-Docs-2.4.2

and not:

PYTHONDOCS=c:\python24\Doc\Python-Docs-2.4.2\ref


----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-05-30 00:30

Message:
Logged In: YES 
user_id=341410

>From what I understand, HTML help hasn't shipped with Python
on Windows for a few releases (likely around the time that
.chm help files started shipping).

If you've got html help files installed, and it's still not
picking them up, could you dig deeper into why this is the case.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-05-30 00:24

Message:
Logged In: YES 
user_id=849994

Okay, reopening.

----------------------------------------------------------------------

Comment By: BartlebyScrivener (bscrivener)
Date: 2006-05-30 00:19

Message:
Logged In: YES 
user_id=1523094

Sorry, if I was unclear. IDLE is not third party, is it?

So I'm saying that on Windows XP, using the install from
Python.org help() is BROKEN. Search in the Python Google
group and you'll find many other references to same. Pydoc
no longer  provides help on topic or keywords. It will do
modules. In short it's PYDOC that is broken, not Pythonwin IDE.

Thanks,

rick

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-05-29 23:00

Message:
Logged In: YES 
user_id=849994

Closing as 3rd party.

----------------------------------------------------------------------

Comment By: BartlebyScrivener (bscrivener)
Date: 2006-05-21 02:51

Message:
Logged In: YES 
user_id=1523094

help('topic') or help('keyword') doesn't work in IDLE or
Pythonwin IDE



----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-05-20 09:00

Message:
Logged In: YES 
user_id=341410

Since you are using the Pythonwin IDE, which was written and
is supported by Mark Hammond via the pywin32 project,
perhaps you should be visiting his project page instead:
http://sf.net/projects/pywin32

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1489051&group_id=5470

From noreply at sourceforge.net  Tue May 30 02:45:47 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 29 May 2006 17:45:47 -0700
Subject: [ python-Bugs-1489051 ] keyword and topic help broken in Pythonwin IDE
Message-ID: <E1FksMl-0000hD-6L@sc8-sf-web2.sourceforge.net>

Bugs item #1489051, was opened at 2006-05-15 18:46
Message generated for change (Comment added) made by bscrivener
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1489051&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: Windows
Group: 3rd Party
Status: Open
Resolution: None
Priority: 5
Submitted By: BartlebyScrivener (bscrivener)
Assigned to: Martin v. L??wis (loewis)
Summary: keyword and topic help broken in Pythonwin IDE

Initial Comment:
Using ActivePython 2.4.3 on Windows XP

While in the Pythonwin IDE, if I seek keyword help by
issuing the following command:

>>>help ('while')

I get:

Sorry, topic and keyword documentation is not available
because the Python HTML documentation files could not
be found.  If you have installed them, please set the
environment variable PYTHONDOCS to
indicate their location.

My PYTHONDOCS variable is set to:

c:\python24\Doc\Python-Docs-2.4.2\ref

which appears to be correct (ie the help html files are
installed
there).

Searching this group, I found someone else complaining
about the same behavior with no clear resolution.

http://tinyurl.com/pblev

See also

http://tinyurl.com/mbokp

----------------------------------------------------------------------

>Comment By: BartlebyScrivener (bscrivener)
Date: 2006-05-30 00:45

Message:
Logged In: YES 
user_id=1523094

>> From what I understand, HTML help hasn't shipped with
>> Python on Windows for a few releases (likely around the
>> time that .chm help files started shipping).

The two tiny urls, esp. the second one illuminate just where
the bug is in Pydoc, but the fix recommended by the poster
doesn't work. The problem happens even after downloading
html help and pointing pydoc to it in the Pythondocs
environment variable. I don't know enough to explore
further, which is why I need a nice working help function :)
I would think this would be an urgent fix for Python
evangelism.  rd

----------------------------------------------------------------------

Comment By: ?iga Seilnacht (zseil)
Date: 2006-05-30 00:42

Message:
Logged In: YES 
user_id=1326842

The problem is on your side.
You should set the PYTHONDOCS environment variable
to the root directory of the html documentation, eg.:

PYTHONDOCS=c:\python24\Doc\Python-Docs-2.4.2

and not:

PYTHONDOCS=c:\python24\Doc\Python-Docs-2.4.2\ref


----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-05-29 22:30

Message:
Logged In: YES 
user_id=341410

>From what I understand, HTML help hasn't shipped with Python
on Windows for a few releases (likely around the time that
.chm help files started shipping).

If you've got html help files installed, and it's still not
picking them up, could you dig deeper into why this is the case.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-05-29 22:24

Message:
Logged In: YES 
user_id=849994

Okay, reopening.

----------------------------------------------------------------------

Comment By: BartlebyScrivener (bscrivener)
Date: 2006-05-29 22:19

Message:
Logged In: YES 
user_id=1523094

Sorry, if I was unclear. IDLE is not third party, is it?

So I'm saying that on Windows XP, using the install from
Python.org help() is BROKEN. Search in the Python Google
group and you'll find many other references to same. Pydoc
no longer  provides help on topic or keywords. It will do
modules. In short it's PYDOC that is broken, not Pythonwin IDE.

Thanks,

rick

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-05-29 21:00

Message:
Logged In: YES 
user_id=849994

Closing as 3rd party.

----------------------------------------------------------------------

Comment By: BartlebyScrivener (bscrivener)
Date: 2006-05-21 00:51

Message:
Logged In: YES 
user_id=1523094

help('topic') or help('keyword') doesn't work in IDLE or
Pythonwin IDE



----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-05-20 07:00

Message:
Logged In: YES 
user_id=341410

Since you are using the Pythonwin IDE, which was written and
is supported by Mark Hammond via the pywin32 project,
perhaps you should be visiting his project page instead:
http://sf.net/projects/pywin32

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1489051&group_id=5470

From noreply at sourceforge.net  Tue May 30 07:29:12 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 29 May 2006 22:29:12 -0700
Subject: [ python-Bugs-1497319 ] Pickling exceptions crashes Python
Message-ID: <E1Fkwn2-000767-6I@sc8-sf-web5.sourceforge.net>

Bugs item #1497319, was opened at 2006-05-30 07:29
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=1497319&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: ?iga Seilnacht (zseil)
Assigned to: Nobody/Anonymous (nobody)
Summary: Pickling exceptions crashes Python

Initial Comment:
The crash happens if an Exception doesn't
have a dict, in BaseException_reduce.
Example:

Python 2.5a2 (trunk:46539M, May 30 2006, 05:02:24)
[MSC v.1310 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license"
for more information.
>>> import pickle
>>> e = BaseException()
>>> pickle.dumps(e) # crash

I'm attaching a module with this and some
other failing tests, mostly caused by
backward incompatibilities. All of the
tests pass on 2.5a2.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1497319&group_id=5470

From noreply at sourceforge.net  Tue May 30 09:13:55 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 30 May 2006 00:13:55 -0700
Subject: [ python-Bugs-1497319 ] Pickling exceptions crashes Python
Message-ID: <E1FkyQN-0001AU-CD@sc8-sf-web2.sourceforge.net>

Bugs item #1497319, was opened at 2006-05-30 05:29
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1497319&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: ?iga Seilnacht (zseil)
Assigned to: Nobody/Anonymous (nobody)
Summary: Pickling exceptions crashes Python

Initial Comment:
The crash happens if an Exception doesn't
have a dict, in BaseException_reduce.
Example:

Python 2.5a2 (trunk:46539M, May 30 2006, 05:02:24)
[MSC v.1310 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license"
for more information.
>>> import pickle
>>> e = BaseException()
>>> pickle.dumps(e) # crash

I'm attaching a module with this and some
other failing tests, mostly caused by
backward incompatibilities. All of the
tests pass on 2.5a2.

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-05-30 07:13

Message:
Logged In: YES 
user_id=849994

Thanks! Fixed in rev. 46551, added a test case.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1497319&group_id=5470

From noreply at sourceforge.net  Tue May 30 09:35:39 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 30 May 2006 00:35:39 -0700
Subject: [ python-Bugs-1497319 ] Pickling exceptions crashes Python
Message-ID: <E1FkylP-0000kt-O8@sc8-sf-web4-b.sourceforge.net>

Bugs item #1497319, was opened at 2006-05-30 05:29
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1497319&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: ?iga Seilnacht (zseil)
Assigned to: Nobody/Anonymous (nobody)
Summary: Pickling exceptions crashes Python

Initial Comment:
The crash happens if an Exception doesn't
have a dict, in BaseException_reduce.
Example:

Python 2.5a2 (trunk:46539M, May 30 2006, 05:02:24)
[MSC v.1310 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license"
for more information.
>>> import pickle
>>> e = BaseException()
>>> pickle.dumps(e) # crash

I'm attaching a module with this and some
other failing tests, mostly caused by
backward incompatibilities. All of the
tests pass on 2.5a2.

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-05-30 07:35

Message:
Logged In: YES 
user_id=849994

Added another test for kw args in rev. 46553.

That args can only be an iterable and will, once assigned,
always be a tuple, was a decision we made.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-05-30 07:13

Message:
Logged In: YES 
user_id=849994

Thanks! Fixed in rev. 46551, added a test case.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1497319&group_id=5470

From noreply at sourceforge.net  Tue May 30 10:20:28 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 30 May 2006 01:20:28 -0700
Subject: [ python-Bugs-1497319 ] Pickling exceptions crashes Python
Message-ID: <E1FkzSm-0001N5-N9@sc8-sf-web4-b.sourceforge.net>

Bugs item #1497319, was opened at 2006-05-30 07:29
Message generated for change (Comment added) made by zseil
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1497319&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: ?iga Seilnacht (zseil)
Assigned to: Nobody/Anonymous (nobody)
Summary: Pickling exceptions crashes Python

Initial Comment:
The crash happens if an Exception doesn't
have a dict, in BaseException_reduce.
Example:

Python 2.5a2 (trunk:46539M, May 30 2006, 05:02:24)
[MSC v.1310 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license"
for more information.
>>> import pickle
>>> e = BaseException()
>>> pickle.dumps(e) # crash

I'm attaching a module with this and some
other failing tests, mostly caused by
backward incompatibilities. All of the
tests pass on 2.5a2.

----------------------------------------------------------------------

>Comment By: ?iga Seilnacht (zseil)
Date: 2006-05-30 10:20

Message:
Logged In: YES 
user_id=1326842

The _PyArg_NoKeywords check should probably be in
BaseException_init, not in BaseException_new, so
that subclasses that want keyword arguments don't
have to override two methods.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-05-30 09:35

Message:
Logged In: YES 
user_id=849994

Added another test for kw args in rev. 46553.

That args can only be an iterable and will, once assigned,
always be a tuple, was a decision we made.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-05-30 09:13

Message:
Logged In: YES 
user_id=849994

Thanks! Fixed in rev. 46551, added a test case.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1497319&group_id=5470

From noreply at sourceforge.net  Tue May 30 10:35:24 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 30 May 2006 01:35:24 -0700
Subject: [ python-Bugs-1497319 ] Pickling exceptions crashes Python
Message-ID: <E1FkzhE-0006oI-8o@sc8-sf-web3.sourceforge.net>

Bugs item #1497319, was opened at 2006-05-30 07:29
Message generated for change (Comment added) made by zseil
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1497319&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: ?iga Seilnacht (zseil)
Assigned to: Nobody/Anonymous (nobody)
Summary: Pickling exceptions crashes Python

Initial Comment:
The crash happens if an Exception doesn't
have a dict, in BaseException_reduce.
Example:

Python 2.5a2 (trunk:46539M, May 30 2006, 05:02:24)
[MSC v.1310 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license"
for more information.
>>> import pickle
>>> e = BaseException()
>>> pickle.dumps(e) # crash

I'm attaching a module with this and some
other failing tests, mostly caused by
backward incompatibilities. All of the
tests pass on 2.5a2.

----------------------------------------------------------------------

>Comment By: ?iga Seilnacht (zseil)
Date: 2006-05-30 10:35

Message:
Logged In: YES 
user_id=1326842

Oh, and another thing, unpickling exceptions
that were pickled with an older version
of Python will have strange effects:

Python 2.4.3 (#69, Mar 29 2006, 17:35:34)
 ...
>>> import pickle
>>> f = open('jar', 'wb')
>>> e = Exception('cucumbers', 'cabbage')
>>> e.args
('cucumbers', 'cabbage')
>>> pickle.dump(e, f)
>>> f.close()
>>> f = open('jar', 'rb')
>>> e = pickle.load(f)
>>> f.close()
>>> e.args
('cucumbers', 'cabbage')

Python 2.5a2 (trunk:46539M, May 30 2006, 05:02:24)
  ...
>>> import pickle
>>> f = open('jar', 'rb')
>>> e = pickle.load(f)
>>> f.close()
>>> e.args
()
>>> e.__dict__['args']
('cucumbers', 'cabbage')


----------------------------------------------------------------------

Comment By: ?iga Seilnacht (zseil)
Date: 2006-05-30 10:20

Message:
Logged In: YES 
user_id=1326842

The _PyArg_NoKeywords check should probably be in
BaseException_init, not in BaseException_new, so
that subclasses that want keyword arguments don't
have to override two methods.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-05-30 09:35

Message:
Logged In: YES 
user_id=849994

Added another test for kw args in rev. 46553.

That args can only be an iterable and will, once assigned,
always be a tuple, was a decision we made.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-05-30 09:13

Message:
Logged In: YES 
user_id=849994

Thanks! Fixed in rev. 46551, added a test case.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1497319&group_id=5470

From noreply at sourceforge.net  Tue May 30 10:39:51 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 30 May 2006 01:39:51 -0700
Subject: [ python-Bugs-1491574 ] distutils adds (unwanted) -xcode=pic32 in the
	compile comman
Message-ID: <E1FkzlX-0008QK-BO@sc8-sf-web3.sourceforge.net>

Bugs item #1491574, was opened at 2006-05-19 15:04
Message generated for change (Comment added) made by tknapen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1491574&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: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Toon Knapen (tknapen)
Assigned to: Nobody/Anonymous (nobody)
Summary: distutils adds (unwanted) -xcode=pic32 in the compile comman

Initial Comment:
After configuring, making and make installing the
svn-trunk version with sunstudio11 on a Solaris 9 box,
an extra '-xcode=pic32' argument is added to the
compile-command when I try to install numarray using
the setup.py that comes with numarray.

To configure python I first executed:

export CC=cc
export CFLAGS="-xarch=v9" # to force 64bit compilation
export EXTRA_CFLAGS="-xarch=v9" # 
export CXX=CC
export CXXFLAGS="-xarch=v9"
export F77=f77
export FFLAGS="-xarch=v9"
export LDFLAGS="-xarch=v9"

Note that EXTRA_CFLAGS needs to be defined too,
otherwise python itself will not be compiled with the
-xarch=v9 option.

Afterwards I want to install numarray using the
setup.py (`python setup.py install` command). During
compilation of numarray I can however see that
distutils is adding -xcode=pic32 on the command-line.
Afterwards distutils is not able to link because there
now is a mix of 32bit and 64bit code.


----------------------------------------------------------------------

>Comment By: Toon Knapen (tknapen)
Date: 2006-05-30 10:39

Message:
Logged In: YES 
user_id=144552

Done.

AFAIAC you can close this issue or we wait for the outcome
of the discussion on python-dev

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-05-23 23:11

Message:
Logged In: YES 
user_id=21627

Yes, please move discussion to python-dev, although
discussion of the build process usually fails to attract
anybody.

----------------------------------------------------------------------

Comment By: Toon Knapen (tknapen)
Date: 2006-05-23 11:13

Message:
Logged In: YES 
user_id=144552

Looking through the code of distutils I finally found that
plenty of information is recoved from the _current_
environment in distutils/sysconfig.py.

Thus the LDFLAGS env.var. I had defined when configuring
python is not stored somewhere. So when e.g. installing
numarray, I need to set the LDFLAGS env.var. again.

Would'nt it be better if python would store the
flags/options that were used to compile python itself. This
guarantees that the extension modules will be
compiled/linked with the same flags and guarantees a maximal
compatibility?

If you prefer to move this discussion to the python-ml ....

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-05-23 00:27

Message:
Logged In: YES 
user_id=21627

Something like that, yes. It's quite involved, so it is not
easy to see what the right approach is.

If you can come up with a patch that works for you, I can
review the patch to find out what else it breaks.

----------------------------------------------------------------------

Comment By: Toon Knapen (tknapen)
Date: 2006-05-22 15:09

Message:
Logged In: YES 
user_id=144552

Indeed the -xcode=pic32 is not at fault here. The problem
though still is that distutils is not linking the shared
libraries using the link-option '-xarch=v9'. The linker
therefore complains about a mix of 32bit and 64bit code.

Should'nt distutils copy the content of LDFLAGS of when
python is being configured and add these options to the
link-line ?

----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-05-20 08:31

Message:
Logged In: YES 
user_id=21627

You must be misunderstanding something. -xcode=pic32 does
*not* mean that the code ought to be compiled for the 32-bit
processor mode. Instead, it means that the PIC (position
independent code) offsets are encoded using 32-bit numbers,
which works for both 32-bit and 64-bit code as long as the
size of the code does not exceed 4GiB.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1491574&group_id=5470

From noreply at sourceforge.net  Tue May 30 11:29:42 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 30 May 2006 02:29:42 -0700
Subject: [ python-Bugs-1497414 ] __self reserved WATCOM 10.6 word
Message-ID: <E1Fl0Xm-0007ks-Tn@sc8-sf-web2.sourceforge.net>

Bugs item #1497414, was opened at 2006-05-30 17:29
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=1497414&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: kbob_ru (kbob_ru)
Assigned to: Nobody/Anonymous (nobody)
Summary: __self reserved WATCOM 10.6 word

Initial Comment:
same as bug 1412837, but for Modules/_tkinter.c


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1497414&group_id=5470

From noreply at sourceforge.net  Tue May 30 14:58:01 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 30 May 2006 05:58:01 -0700
Subject: [ python-Feature Requests-1497532 ] C API to retain GIL during Python
	Callback
Message-ID: <E1Fl3nN-0003ag-LC@sc8-sf-web4-b.sourceforge.net>

Feature Requests item #1497532, was opened at 2006-05-30 14:58
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1497532&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: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin Gfeller (gfe)
Assigned to: Nobody/Anonymous (nobody)
Summary: C API to retain GIL during Python Callback

Initial Comment:
[Split off from closed 1453341, which desired a Python-
level API. This request is for a C API, to be used in 
C extensions that call back into Python.]

I think it would be very useful to have an API that 
would tell Python not to release the GIL during call 
backs to Python code, until it is told again (back in 
C code) that it is ok to do so.

I'd like to quote Tim Peters, who explains it better 
than me (private conversation, June 2005):
----------
It would be more feasible to patch Python, introducing 
a way to tell the interpreter not to allow other 
_Python_ threads to run. It has such a mechanism 
already (the GIL -- the global interpreter lock), but 
as soon as C code calls back into Python, the 
interpreter may release the GIL and give ownership of 
it to a different thread. I think it would be pretty 
easy to introduce a Python C API to say "don't allow
other Python threads to run until I tell you 
otherwise". 
----------

The Use Case arose with a multi-threading problem in 
ZODB's Connection, where the C code must ensure that 
no other thread runs Python code accessing an object 
BUT the own thread needs to call back into Python. 

Any other mechanism that came to my mind would either 
require to halt *all* others threads, or run into race 
conditions. 

Best regards, Martin Gfeller

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1497532&group_id=5470

From noreply at sourceforge.net  Tue May 30 14:58:57 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 30 May 2006 05:58:57 -0700
Subject: [ python-Feature Requests-1453341 ] sys.setatomicexecution - for
	critical sections
Message-ID: <E1Fl3oH-0003mn-6y@sc8-sf-web4-b.sourceforge.net>

Feature Requests item #1453341, was opened at 2006-03-18 20:52
Message generated for change (Comment added) made by gfe
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1453341&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: Closed
Resolution: Rejected
Priority: 5
Submitted By: kxroberto (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: sys.setatomicexecution -  for critical sections

Initial Comment:
In order to maintain threaded code uncomplicated (VHL)
and in order to avoid massive use of locks, when
introducing few critical non-atomic sections, it should
be possible to put out that practical hammer ..

    try:
        last_ci=sys.setcheckinterval(sys.maxint)
        critical_function()  # now runs atomically
    finally:
        sys.setcheckinterval(last_ci)
    #(sys.setcheckinterval assumed to return the last
value)


..by an official function/class (in sys or thread):


Maybe:
======

atomic = sys.setatomicexecution(mode)
try:
    print "Executing critical section"
finally:
    sys.setatomicexecution(atomic)

there should be different modes/levels for blocking :

* 0=None
* 1=block only python execution in other threads
* 2=block signals
* 4/5/7/15=block threads at OS level (if OS supports)
* 8=(reserved: block future sub-/stackless switching
inside current thread..)

see:
http://groups.google.de/group/comp.lang.python/browse_frm/thread/bf5461507803975e/3bd7dfa9422a1200

compare:
http://www.stackless.com/wiki/Tasklets#critical-sections

---

Also Python could define officially its time atoms
beyond CPU atoms in the docs (That also defines the VHL
usability of the language).

Thus thinks like single-element changes ...

obj.var=x  , d[key]=x , l.append(x) .pop()

should be guaranteed to work atomic/correct FOR EVER. 

l[slice],  d.keys() .items(), .. questionable? 
If not guaranteed for the future, offer duplicates for
speed critical key building blocks like: 
l.slice_atomic(slice), d.keys_atomic() ,...  in order
to make code compatible for the future. 

---

Extra fun for blowing up python libs for poeple who
don't want to learn that try..finally all the time:

copy/deepcopy/dump maybe could be enriched by
copy_atomic , deepcopy_atomic, dump_atomic - or just
RuntimeError tolerant versions,   deepcopy_save  (no
use of .iterxxx)



----------------------------------------------------------------------

Comment By: Martin Gfeller (gfe)
Date: 2006-05-30 14:58

Message:
Logged In: YES 
user_id=884167

[I split off a new item 1497532, asking for a C level API, 
so this item can remain closed.]

----------------------------------------------------------------------

Comment By: Martin Gfeller (gfe)
Date: 2006-05-29 15:06

Message:
Logged In: YES 
user_id=884167

Should I enter a separate feature request for this, 
separating it from this closed item?

Martin

----------------------------------------------------------------------

Comment By: Martin Gfeller (gfe)
Date: 2006-05-29 15:03

Message:
Logged In: YES 
user_id=884167

Nick Coghlan wrote:
> Python level access to the Global Interpreter Lock is 
neither necessary nor desirable.

I agree. But what I think would be very useful (as I 
already mentioned below) is C level API access that tells 
Python not to relinquish the GIL during a callback. 

I don't know of any other way to achieve this, apart from 
introducing a separate C-level locking mechanism. 

I think Tim Peters thinks thought this is feasible when he 
wrote the following (private conversation, June 2005):

> It would be more feasible to patch Python, introducing 
> a way to tell the interpreter not to allow other 
> _Python_ threads to run. It has such a mechanism 
> already (the GIL -- the global interpreter lock), but 
> as soon as C code calls back into Python, the interpreter
> may release the GIL and give ownership of it to a 
> different thread. I think it would be pretty easy to 
> introduce a Python C API to say "don't allow other Python
> threads to run until I tell you otherwise". 

Best regards, Martin Gfeller

----------------------------------------------------------------------

Comment By: Nick Coghlan (ncoghlan)
Date: 2006-04-08 20:34

Message:
Logged In: YES 
user_id=1038590

On the other changes you suggest (which Raymond didn't bring
up on python-dev):

Python can't formally define as atomic any operations that
may execute arbitrary Python code, as the interpreter cannot
control what that code may do. All of the examples you give
are in that category.

Slowing down the common cases (unthreaded code and
Queue-based threaded code) by adding internal locking to
every data structure is also considered highly undesirable.

----------------------------------------------------------------------

Comment By: Nick Coghlan (ncoghlan)
Date: 2006-04-08 20:17

Message:
Logged In: YES 
user_id=1038590

Raymond brought this idea up on python-dev at the time of
the c.l.p discussion - it was rejected on the basis that
thread synchronisation tools (Queues and Locks) are provided
for a reason. Python level access to the Global Interpreter
Lock is neither necessary nor desirable.

Avoiding the tools provided to permit threading to work
correctly and then finding that threaded code doesn't work
as desired really shouldn't be surprising.

FWIW, Python 2.5 aims to make normal locking easier to use
by permitting:

from __future__ import with_statement
from threading import Lock

sync_lock = Lock()

def my_func(*args, **kwds):
    with sync_lock:
        # Only one thread at a time can enter this section
        # regardless of IO or anything else
    # This section, on the other hand, is a free-for-all

If you genuinely have to avoid normal thread synchronisation
primitives, you can abuse (and I really do mean abuse) the
interpreter's import lock for this purpose:

imp.acquire_lock()
try: 
    print 'critical section'
finally:
    imp.release_lock()

Or even:

@contextlib.contextmanager
def CriticalSection()
    imp.acquire_lock()
    try:
        yield
    finally:
        imp.release_lock()

with CriticalSection():
    print 'critical section'


----------------------------------------------------------------------

Comment By: kxroberto (kxroberto)
Date: 2006-03-20 16:28

Message:
Logged In: YES 
user_id=972995

... only PyEval_RestoreThread with the harder execution
level in its tstate

----------------------------------------------------------------------

Comment By: kxroberto (kxroberto)
Date: 2006-03-20 16:24

Message:
Logged In: YES 
user_id=972995

thus the GIL could simply have a harder state 2 : "locked
hard for PyEval_AcquireThread/PyEval_AcquireLock/.." ?

Only PyEval_RestoreThread gets the lock again after
PyEval_SaveThread.

Robert




----------------------------------------------------------------------

Comment By: Martin Gfeller (gfe)
Date: 2006-03-20 13:17

Message:
Logged In: YES 
user_id=884167

- sys.setcheckinterval(sys.maxint) does not prevent 
  thread switching when doing IO, does it? There is
  no way that I know of to prevent thread switching
  in this situation.

- When calling back into Python from C Code, there is
  no way to tell Python not to relinquish the GIL; such
  an option could be useful for some C code, because
  the GIL provides a "global critical section". 

Martin


----------------------------------------------------------------------

Comment By: kxroberto (kxroberto)
Date: 2006-03-18 22:54

Message:
Logged In: YES 
user_id=972995

or:

>>> atomic = sys.acquireatomicexecution(mode)
>>> try: 
... 	print 'critical section'
... finally:
... 	atomic.release()

>>> with sys.acquireatomicexecution(mode):
...     print 'critical section'



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1453341&group_id=5470

From noreply at sourceforge.net  Wed May 31 02:54:17 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 30 May 2006 17:54:17 -0700
Subject: [ python-Bugs-1484172 ] hyper-threading locks up sleeping threads
Message-ID: <E1FlEyX-0005sr-2t@sc8-sf-web3.sourceforge.net>

Bugs item #1484172, was opened at 2006-05-08 17:45
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1484172&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: Threads
>Group: 3rd Party
>Status: Closed
>Resolution: Works For Me
Priority: 5
Submitted By: Olaf Meding (olafmeding)
Assigned to: Nobody/Anonymous (nobody)
Summary: hyper-threading locks up sleeping threads

Initial Comment:
Below are 2 files.  The first is a Python program that 
demonstrates the problem within less than 1 hour 
(often just a few minutes).  The second is a C++ 
program that shows that the Win32 Sleep() function 
works as expected (the program was started 3 days ago 
and is still running).

Note, I also attached the source code.

Note, the Python programs hangs (stops responding) 
with hyper-threading turned on (a BIOS setting), but 
works as expected with hyper-threading turned off.

This problem happens on Windows only (the below Python 
program ran for 24 hours on Linux without a problem).

Variations of the Python program also lock up:

Tried importing win32api instead of importing time and 
using the win32api.GetTickCount() and win32api.Sleep() 
methods.

Tried using lock = threading.Event() and lock.wait() 
instead of time.sleep().

Tried importing Queue and using q = Queue.Queue() and 
q.get(True, sleepTime).

Note, the Windows task manager shows 2 CPUs on the 
Performance tab with hyper-threading is turned on.

Both Python 2.3.5 and 2.4.3 (downloaded from 
python.org) have this problem.

The operating system is MS Windows XP Professional.

winmsd.exe (Start Menu > Run) shows:
2CPUs: x86 Family 15 Model 4 Stepping 1 GenuineIntel 
~3000 MHz
Version: 5.1.2600 Service Pack 2 Build 2600

Could someone with a hyper-threading (or dual-core or 
multi-processor) CPU please confirm this bug?

Many Thanks

Olaf


Here is the expected output of both programs (the 
progam has locked up if the numbers stop printing 
every 10 seconds or so):
python testsleep.py
thread 1 started, sleep time 0.010
thread 2 started, sleep time 0.003
1 1 1 2 1 1 1 2 1 1 1 2 1 1 1 1 2 1 1 1

# testsleep.py
import threading
import time

class Task(threading.Thread):
        def __init__(self, n, t):
                threading.Thread.__init__(self)
                self.n = n  # thread id
                self.t = t  # sleep time
        def run(self):
                print 'thread %d started, sleep time 
%.3f' % (self.n, self.t)
                count = 0
                printCount = int(10 / self.t)
                while True:
                        start = time.clock()
                        time.sleep(self.t)
                        stop = time.clock()
                        if stop - start > 1.0:
                                print 'thread', 
self.n, stop - start

                        count += 1
                        if count > printCount:
                                count = 0
                                print self.n,  # print 
sign of live

def test():
        thread1 = Task(1, 0.01)  # thread 1, sleep 10 
ms
        thread2 = Task(2, 0.003) # thread 2, sleep  3 
ms
        thread1.start()
        thread2.start()

test()

-------------------------------------------------------
---------------------------

// testsleep.cpp
// Compiled with Visual C++ version 6 (in debug mode) 
as a Win32 console application.

#include <windows.h>
#include <stdio.h>
#include <time.h>

typedef struct {
    int id;
    int ms;

} param_s;

DWORD WINAPI threadFunction(LPVOID param)
{
    param_s* p = (param_s*)param;
    long elapsedTime;
    long time1, time2;
    long printCount = long(10000 / p->ms);  // loop 
iterations in 10 seconds
    long count = 0;

    printf("thread %d started, sleep time: %d 
ms" "\n", p->id, p->ms);

    while(true) {
        time1 = GetTickCount();
        Sleep(p->ms);
        time2 = GetTickCount();

        elapsedTime = time2 - time1;
        if(elapsedTime > 1000)
            printf("thread %d slept for %d ms" "\n", p-
>id, elapsedTime);

        count++;
        if(count > printCount) {
            count = 0;
            printf("%d ", p->id);  // print sign of 
live
        }
    }

    return 0;
}

int main(int argc, char* argv[])
{
    param_s p1, p2;

    p1.id = 1;
    p1.ms = 10;

    p2.id = 2;
    p2.ms = 3;

    CreateThread(NULL, 0, threadFunction, (void*)&p1, 
0, NULL);
    CreateThread(NULL, 0, threadFunction, (void*)&p2, 
0, NULL);

    getchar();  // wait until the user presses the 
enter key.

    return 0; 
}

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2006-05-30 20:54

Message:
Logged In: YES 
user_id=31435

Closing as 3rd-party, Works For Me.  On c.l.py today the OP
reported that a BIOS upgrade repaired the problem:

"""
The problem turned out to be the BIOS of the PC we were
using.  The Python test program has been running fine for 5
days now (after we upgraded the system BIOS) and is still
running fine.

Sorry, I do not have any information as to what was fixed in
the BIOS.  Also, I do not know exactly who made the
motherboard or the BIOS.  I will post another update if this
information becomes available.


This was sure a strange bug!
"""

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-05-08 17:58

Message:
Logged In: YES 
user_id=31435

As noted (multiple times by now ;-)) on c.l.py, the Python
program does not hang on my similar HT box:

http://mail.python.org/pipermail/python-list/2006-May/340538.html


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1484172&group_id=5470

From noreply at sourceforge.net  Wed May 31 04:22:42 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 30 May 2006 19:22:42 -0700
Subject: [ python-Bugs-1496315 ] strptime: wrong default values used to fill
	in missing data
Message-ID: <E1FlGM6-0001s5-Ao@sc8-sf-web5.sourceforge.net>

Bugs item #1496315, was opened at 2006-05-28 02:26
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1496315&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: Markus Gritsch (markus_gritsch)
Assigned to: Brett Cannon (bcannon)
Summary: strptime: wrong default values used to fill in missing data

Initial Comment:
The documentation of strptime() says: """The default
values used to fill in any missing data are (1900, 1,
1, 0, 0, 0, 0, 1, -1)""".  As the example below shows,
this is not the case.

Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310
32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for
more information.
>>> import time
>>> time.strptime('', '')
(1900, 1, 1, 0, 0, 0, 0, 1, -1)
>>> time.strptime('2006', '%Y')
(2006, 1, 1, 0, 0, 0, 6, 1, -1)
>>> time.strptime('2006-05', '%Y-%m')
(2006, 5, 1, 0, 0, 0, 0, 121, -1)
>>> time.strptime('2006-05-26', '%Y-%m-%d')
(2006, 5, 26, 0, 0, 0, 4, 146, -1)
>>> time.strptime('2006-05-26 21', '%Y-%m-%d %H')
(2006, 5, 26, 21, 0, 0, 4, 146, -1)
>>> time.strptime('2006-05-26 21:06', '%Y-%m-%d %H:%M')
(2006, 5, 26, 21, 6, 0, 4, 146, -1)
>>> time.strptime('2006-05-26 21:06:11', '%Y-%m-%d
%H:%M:%S')
(2006, 5, 26, 21, 6, 11, 4, 146, -1)


----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2006-05-30 19:22

Message:
Logged In: YES 
user_id=357491

Rev. 46569 has more clear wording for HEAD and rev. 46570
has it for 2.4 .

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2006-05-28 11:29

Message:
Logged In: YES 
user_id=357491

The docs need to be fixed to say those are the default
values except when strptime() can infer better ones.  There
is a lot of smarts in the algorithm that do calculations to
fill in missing data as best as possible, and that is what
is happening here.

Thanks for the bug report.  I will try to fix this some time
this week.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1496315&group_id=5470

From noreply at sourceforge.net  Wed May 31 08:42:31 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 30 May 2006 23:42:31 -0700
Subject: [ python-Bugs-1497962 ] Leak in tarfile.py
Message-ID: <E1FlKPX-0000lM-70@sc8-sf-web5.sourceforge.net>

Bugs item #1497962, was opened at 2006-05-31 08:42
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=1497962&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jens J?rgen Mortensen (jensj)
Assigned to: Nobody/Anonymous (nobody)
Summary: Leak in tarfile.py

Initial Comment:
There is a leak when using the tarfile module and the
extractfile method.  Here is a simple example:
 
$ echo "grrr" > x.txt
$ tar cf x.tar x.txt
$ python
Python 2.4.2 (#2, Sep 30 2005, 21:19:01)
[GCC 4.0.2 20050808 (prerelease) (Ubuntu
4.0.1-4ubuntu8)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import gc
>>> import tarfile
>>> tar = tarfile.open('x.tar', 'r')
>>> f = tar.extractfile('x.txt')
>>> f.read()
'grrr\n'
>>> del f
>>> gc.set_debug(gc.DEBUG_LEAK)
>>> print gc.collect()
gc: collectable <ExFileObject 0xb73d4acc>
gc: collectable <dict 0xb73dcf0c>
gc: collectable <instancemethod 0xb7d2daf4>
3
>>> print gc.garbage
[<tarfile.ExFileObject object at 0xb73d4acc>, {'name':
'x.txt', 'read': <bound method ExFileObject._readnormal
of <tarfile.ExFileObject object at 0xb73d4acc>>, 'pos':
0L, 'fileobj': <open file 'x.tar', mode 'rb' at
0xb73e67b8>, 'mode': 'r', 'closed': False, 'offset':
512L, 'linebuffer': '', 'size': 5L}, <bound method
ExFileObject._readnormal of <tarfile.ExFileObject
object at 0xb73d4acc>>]
>>>


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1497962&group_id=5470

From noreply at sourceforge.net  Wed May 31 11:15:51 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 31 May 2006 02:15:51 -0700
Subject: [ python-Bugs-1498051 ] MSVC compiler problems with .NET v2.0
Message-ID: <E1FlMnv-0006QC-FN@sc8-sf-web1.sourceforge.net>

Bugs item #1498051, was opened at 2006-05-31 11:15
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=1498051&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: Retief Gerber (hrgerber)
Assigned to: Nobody/Anonymous (nobody)
Summary: MSVC compiler problems with .NET v2.0

Initial Comment:
There is a problem with msvccompiler.py that does not 
allow it to work with MS Visual Studio 2005 and .NET 
v2.0

msvccompiler.py
__revision__ = "$Id: msvccompiler.py,v 1.64.2.4 
2005/08/07 20:50:37 loewis Exp $"
from line 128 

            if version > 7.0:
                self.set_macro("FrameworkSDKDir", 
net, "sdkinstallrootv1.1")
            else:
                self.set_macro("FrameworkSDKDir", 
net, "sdkinstallroot")

should be replaced with 

            if version == 7.1:
                self.set_macro("FrameworkSDKDir", 
net, "sdkinstallrootv2.0")
            elif version > 7.0:
                self.set_macro("FrameworkSDKDir", 
net, "sdkinstallrootv1.1")
            else:
                self.set_macro("FrameworkSDKDir", 
net, "sdkinstallroot")

I dont have must dev experience on distutils, so this 
might not be the best solution


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1498051&group_id=5470

From noreply at sourceforge.net  Wed May 31 13:52:06 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 31 May 2006 04:52:06 -0700
Subject: [ python-Bugs-1498146 ] optparse does not hande unicode help strings
Message-ID: <E1FlPF8-0006k4-4p@sc8-sf-web3.sourceforge.net>

Bugs item #1498146, was opened at 2006-05-31 13:52
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=1498146&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: Tom Cato Amundsen (tomcato)
Assigned to: M.-A. Lemburg (lemburg)
Summary: optparse does not hande unicode help strings

Initial Comment:
Unicode strings with non-ascii chars in generate a
UnicodeEncodeError

  File "/usr/lib/python2.3/optparse.py", line 1370, in
print_help
    file.write(self.format_help())
UnicodeEncodeError: 'ascii' codec can't encode
characters in position 200-202:
+ordinal not in range(128)

I'm subclassing OptionParser and adds the following
method to get it to work. Should something like this be
done for python 2.5?

def print_help(self, file=None):
    if file is None:
        file = sys.stdout
    file.write(self.format_help().encode(file.encoding,
'replace'))


Tom Cato

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1498146&group_id=5470

From noreply at sourceforge.net  Wed May 31 13:52:52 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 31 May 2006 04:52:52 -0700
Subject: [ python-Bugs-1498146 ] optparse does not hande unicode help strings
Message-ID: <E1FlPFs-00076H-Mv@sc8-sf-web5.sourceforge.net>

Bugs item #1498146, was opened at 2006-05-31 13:52
Message generated for change (Settings changed) made by tomcato
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1498146&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: Tom Cato Amundsen (tomcato)
>Assigned to: Nobody/Anonymous (nobody)
Summary: optparse does not hande unicode help strings

Initial Comment:
Unicode strings with non-ascii chars in generate a
UnicodeEncodeError

  File "/usr/lib/python2.3/optparse.py", line 1370, in
print_help
    file.write(self.format_help())
UnicodeEncodeError: 'ascii' codec can't encode
characters in position 200-202:
+ordinal not in range(128)

I'm subclassing OptionParser and adds the following
method to get it to work. Should something like this be
done for python 2.5?

def print_help(self, file=None):
    if file is None:
        file = sys.stdout
    file.write(self.format_help().encode(file.encoding,
'replace'))


Tom Cato

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1498146&group_id=5470

From noreply at sourceforge.net  Wed May 31 16:13:27 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 31 May 2006 07:13:27 -0700
Subject: [ python-Bugs-1473048 ] SimpleXMLRPCServer responds to any path
Message-ID: <E1FlRRv-0003EJ-AR@sc8-sf-web1.sourceforge.net>

Bugs item #1473048, was opened at 2006-04-19 11:45
Message generated for change (Comment added) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1473048&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: Closed
>Resolution: Accepted
Priority: 5
Submitted By: A.M. Kuchling (akuchling)
>Assigned to: A.M. Kuchling (akuchling)
Summary: SimpleXMLRPCServer responds to any path

Initial Comment:
SimpleXMLRPCServer and DocXMLRPCServer don't look at
the path of the HTTP request at all; you can POST or
GET from / or /RPC2 or /blahblahblah with the same results.

One minor problem with this liberality is that a
security scanner that looks for vulnerable scripts such
as /cgi-bin/phf will report the server as vulnerable. 
Nessus, for example, reports dozens of security holes
on a SimpleXMLRPCServer for this reason.

Fix: add a check that only allows '/' or '/RPC2' (maybe
just /RPC2?).



----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2006-05-31 10:13

Message:
Logged In: YES 
user_id=11375

I've applied this patch in rev. 46578.

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2006-04-26 08:42

Message:
Logged In: YES 
user_id=11375

The attached patch adds a .rpc_paths attribute that's a
tuple of legal paths, and a .is_rpc_path_valid() method that
returns True if a path is OK.

A .report_404() method generates a 404 error message, and
SimpleXMLRPCServer and DocXMLRPCServer are modified to check
for legal paths.  (Perhaps it should be ._report_404?)


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1473048&group_id=5470

From noreply at sourceforge.net  Wed May 31 16:26:30 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 31 May 2006 07:26:30 -0700
Subject: [ python-Bugs-1484556 ] Output of KlocWork on Python2.4.3 sources
Message-ID: <E1FlReY-0004ip-WE@sc8-sf-web3.sourceforge.net>

Bugs item #1484556, was opened at 2006-05-09 06:14
Message generated for change (Comment added) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1484556&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Miki Tebeka (tebeka)
Assigned to: Nobody/Anonymous (nobody)
Summary: Output of KlocWork on Python2.4.3 sources

Initial Comment:
We're evaluating KlocWork (http://www.klocwork.com),
I've ran it on the source of Python 2.4.3 and the
output is attached (1562 warnings).

----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2006-05-31 10:26

Message:
Logged In: YES 
user_id=11375

The Coverity scans also probably report some of the same
bugs, so many of these problems may be fixed in the 2.5 trunk.  

If you're still evaluating, you could try running the tool
on the 2.5 trunk (snapshot available from
http://svn.python.org/snapshots/) and see if the results are
shorter.


----------------------------------------------------------------------

Comment By: Martin v. L??wis (loewis)
Date: 2006-05-10 00:45

Message:
Logged In: YES 
user_id=21627

Thanks for these results. Unfortunately, they seem to
contain many false positives, so it is unclear how one
should proceed with them.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1484556&group_id=5470

From noreply at sourceforge.net  Wed May 31 20:39:40 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 31 May 2006 11:39:40 -0700
Subject: [ python-Bugs-1494314 ] Cannot use high-numbered sockets in 2.4.3
Message-ID: <E1FlVbY-000679-2u@sc8-sf-web1.sourceforge.net>

Bugs item #1494314, was opened at 2006-05-24 09:51
Message generated for change (Comment added) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1494314&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: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Smith (mlrsmith)
Assigned to: Nobody/Anonymous (nobody)
Summary: Cannot use high-numbered sockets in 2.4.3

Initial Comment:
Python 2.4.3 introduced (in Modules/socketmodule.c) the
IS_SELECTABLE() macro, to check whether calling
select() on a given file descriptor is permissible.

However, it executes this check even when it won't
actually call select(). Specifically, select() is
called ONLY when s->sock_timeout > 0 (in
internal_select mostly, but also internal_connect).

I have a twisted application which uses many FDs
(several thousand), and upgrading python to 2.4.3 makes
it hit this limit (at 1024 file descriptors),
regardless of ulimit settings. Twisted itself always
uses non-blocking I/O on sockets, so with older
versions of python this worked fine.

A simple solution relies on the fact that select is
only ever actually called, and changes the
IS_SELECTABLE macro as in the attached fairly trivial
patch. This is sufficient to restore my application to
its previous state (where it works fine).

This doesn't solve the more general problem in
socketmodule - that we simply can't do all operations
properly with the current reliance on select(), though,
and it seems like a bit of a hack...  If I wrote up a
patch to use poll() on systems where it's available,
throughout socketmodule.c, in preference to select(),
would this be accepted?

Mike



----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2006-05-31 14:39

Message:
Logged In: YES 
user_id=11375

I expect such a patch would be acceptable.  The largest
issue is probably whether poll() is available everywhere, or
if we'd be stuck maintaining both select() and poll() based
versions of internal_select().  Does Windows support poll()
at all?

----------------------------------------------------------------------

Comment By: Michael Smith (mlrsmith)
Date: 2006-05-29 10:13

Message:
Logged In: YES 
user_id=1488997

Yes, I had my ulimit set appropriately.

There's no problem with _opening_ many sockets (at least, I
don't think there is) - the problem is with trying to do
something (like call socket.recv()) with them.

The code in socketmodule.c is pretty clear - and having
upgraded to 2.4.3 with ubuntu dapper, I _am_ running into this.

For now, we're having to keep all our production machines on
2.4.2.


----------------------------------------------------------------------

Comment By: Gabriel Wicke (gabrielwicke)
Date: 2006-05-29 10:11

Message:
Logged In: YES 
user_id=956757

Please disregard my comments completely- just opening more
than 1024 files does not trigger this bug, but doing a
socket.send() on the 1025th socket does.

----------------------------------------------------------------------

Comment By: Gabriel Wicke (gabrielwicke)
Date: 2006-05-29 10:00

Message:
Logged In: YES 
user_id=956757

Never mind- you already tried ulimit. It still works for me
though, 2.4.3 from Ubuntu Dapper.

----------------------------------------------------------------------

Comment By: Gabriel Wicke (gabrielwicke)
Date: 2006-05-29 09:57

Message:
Logged In: YES 
user_id=956757

Try "ulimit -n 8096" (only permitted in a root shell) to set
your max socket usage to something larger. Opening more than
1024 sockets works for me in python 2.4.3 after changing the
limit for the terminal in question and restarting the
interpreter. Just ulimit -n will show you your current
limit. Ulimits are enforced by the Linux kernel and can
likely be configured system-wide in /etc/sysctl.cfg.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1494314&group_id=5470

From noreply at sourceforge.net  Wed May 31 23:39:44 2006
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 31 May 2006 14:39:44 -0700
Subject: [ python-Bugs-1494314 ] Cannot use high-numbered sockets in 2.4.3
Message-ID: <E1FlYPo-0007v4-48@sc8-sf-web2.sourceforge.net>

Bugs item #1494314, was opened at 2006-05-24 15:51
Message generated for change (Comment added) made by mlrsmith
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1494314&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: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Smith (mlrsmith)
Assigned to: Nobody/Anonymous (nobody)
Summary: Cannot use high-numbered sockets in 2.4.3

Initial Comment:
Python 2.4.3 introduced (in Modules/socketmodule.c) the
IS_SELECTABLE() macro, to check whether calling
select() on a given file descriptor is permissible.

However, it executes this check even when it won't
actually call select(). Specifically, select() is
called ONLY when s->sock_timeout > 0 (in
internal_select mostly, but also internal_connect).

I have a twisted application which uses many FDs
(several thousand), and upgrading python to 2.4.3 makes
it hit this limit (at 1024 file descriptors),
regardless of ulimit settings. Twisted itself always
uses non-blocking I/O on sockets, so with older
versions of python this worked fine.

A simple solution relies on the fact that select is
only ever actually called, and changes the
IS_SELECTABLE macro as in the attached fairly trivial
patch. This is sufficient to restore my application to
its previous state (where it works fine).

This doesn't solve the more general problem in
socketmodule - that we simply can't do all operations
properly with the current reliance on select(), though,
and it seems like a bit of a hack...  If I wrote up a
patch to use poll() on systems where it's available,
throughout socketmodule.c, in preference to select(),
would this be accepted?

Mike



----------------------------------------------------------------------

>Comment By: Michael Smith (mlrsmith)
Date: 2006-05-31 23:39

Message:
Logged In: YES 
user_id=1488997

That, of course, is the problem - select() is available more
or less universally, but poll() is not. However, it's not
terribly difficult to write a poll() wrapper using select(),
though doing so in general would have serious performance
issues (the specific uses in socketmodule.c do not hit this
problem), and retains the limitations of select. 

It's not clear that the complexity of doing this is
worthwhile compared to just implementing the simple API
needed internally to socketmodule.c using both APIs (i.e.
just adding a poll() option).

Regardless, it'd be nice if at least the basic fix I wrote
up went in - it solves the immediate problem, at least.

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2006-05-31 20:39

Message:
Logged In: YES 
user_id=11375

I expect such a patch would be acceptable.  The largest
issue is probably whether poll() is available everywhere, or
if we'd be stuck maintaining both select() and poll() based
versions of internal_select().  Does Windows support poll()
at all?

----------------------------------------------------------------------

Comment By: Michael Smith (mlrsmith)
Date: 2006-05-29 16:13

Message:
Logged In: YES 
user_id=1488997

Yes, I had my ulimit set appropriately.

There's no problem with _opening_ many sockets (at least, I
don't think there is) - the problem is with trying to do
something (like call socket.recv()) with them.

The code in socketmodule.c is pretty clear - and having
upgraded to 2.4.3 with ubuntu dapper, I _am_ running into this.

For now, we're having to keep all our production machines on
2.4.2.


----------------------------------------------------------------------

Comment By: Gabriel Wicke (gabrielwicke)
Date: 2006-05-29 16:11

Message:
Logged In: YES 
user_id=956757

Please disregard my comments completely- just opening more
than 1024 files does not trigger this bug, but doing a
socket.send() on the 1025th socket does.

----------------------------------------------------------------------

Comment By: Gabriel Wicke (gabrielwicke)
Date: 2006-05-29 16:00

Message:
Logged In: YES 
user_id=956757

Never mind- you already tried ulimit. It still works for me
though, 2.4.3 from Ubuntu Dapper.

----------------------------------------------------------------------

Comment By: Gabriel Wicke (gabrielwicke)
Date: 2006-05-29 15:57

Message:
Logged In: YES 
user_id=956757

Try "ulimit -n 8096" (only permitted in a root shell) to set
your max socket usage to something larger. Opening more than
1024 sockets works for me in python 2.4.3 after changing the
limit for the terminal in question and restarting the
interpreter. Just ulimit -n will show you your current
limit. Ulimits are enforced by the Linux kernel and can
likely be configured system-wide in /etc/sysctl.cfg.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1494314&group_id=5470

From matthias.uhlig at seppmed.de  Fri May  5 14:50:16 2006
From: matthias.uhlig at seppmed.de (Matthias Uhlig)
Date: Fri, 05 May 2006 12:50:16 -0000
Subject: Exception during GarbageCollection in Py_Finalize()
Message-ID: <445B37C7.1030009@seppmed.de>

Hi,

I have two problems using the C/API to write a C dll, the first and serious:
1) The Scenario (pLocal, pGlobal are not changed by the dll during one 
"init-> fini" cycle)
- Py_Initialize()
- PyRun_String("/x=1/", Py_single_input, pGlobal, pLocal)
- PyRun_String("/x:=1/", Py_eval_input, pGlobal, pLocal)      
      -> returns -1; Hint: if the string contains a valid statement 
("x==1") there is no exception at finalize
- Py_Finalize() 
      ---> access violation

At the Py_Finalize an access violation appears. As I'm having trouble 
building python by myself I have no debug version available to see whats 
goin' on in the finalize().
Of course it is an invalid statement, but an access violation is still 
not nice.

the 2nd)
In Py_DECREF in the case the variable will be deleted, it would be 
helpful to set the variable to NULL. Otherwise I have to check it 
(ob_refcnt) in my code as well.

If the API is used in an invalid way, please tell how the right way is.

Kind Regards,
Matthias

-- 
Matthias Uhlig
sepp.med GmbH 	  	Gewerbering 9, D-91341 R?ttenbach, Germany
  	Tel: +49 (0) 9195 / 931 235
Fax: +49 (0) 9195 / 995 858
Email: matthias.uhlig at seppmed.de <mailto:matthias.uhlig at seppmed.de>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-bugs-list/attachments/20060505/0c206c15/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: seppmed_sig.gif
Type: image/gif
Size: 1829 bytes
Desc: not available
Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20060505/0c206c15/attachment-0001.gif